If you build digital products — websites, mobile apps, software — long enough, you learn a few key lessons that change the way you think about those products. Today we’re going to talk about perhaps the most fundamental thing you can do to focus the development of your product and drive it to be as good as it can be — identifying its purpose.
One of the absolute best things you can do as a new developer, manager, product owner or designer, when starting or joining a project, is ask the most fundamental question related to building almost anything: What is it for? This also makes for a great interview question for vetting new team members. Any digital products professional worth their salt will have developed an answer within a few months of joining any organization. If a candidate can’t tell you concisely and with confidence what the product they work on is for, that’s a bad sign. And knowing the answer to this question gives you a surprisingly unique advantage: viewing a product through a focused lens of purpose colors the addition of every new feature with the additional question: how does this serve the ultimate goal of the app. Product developers that don’t continually ask and re-ask this question tend to wind up with products that are meandering, confusing and hard to use.
Function is not a Feature
Digital Products often do lots of different things — especially as they mature — so distilling down what the product is actually for to just one thing can be trickier than it seems. Often times you might think that multiple basic operations of the app are roughly equivalent in importance, and that you couldn’t possibly choose one over the other. The problem here is that you’re thinking about Features. The myriad of things a user can do with your app are never its ultimate purpose. The underlying, fundamental reason the app exists is much broader than that.
Determination of Purpose
Ok, so we’ve established that Features aren’t Function, so what is Function, then? The function of your application generally depends on the type of business you’re in, but in general, for applications that you’re building for a for-profit organization or business, your app’s job is usually to make or save your company some money. For instance, if you work on an account management app, the features of your app might include allowing customers to access and monitor their account, change their password and pay their bill, but the function of the application might actually be something more like: “to alleviate the need for customers to call customer support, thereby saving the company money.” Application functions almost always come down to dollars and sense. (HA)
Ok, Now What?
So you’ve figured out, for the first time maybe, what your app is actually supposed to do, and at a high level. So, why do you care, and what do you do with that knowledge? Well, not every feature necessarily needs to serve the main goal of your application, and not every line of code needs to be written with the main goal of the app in mind. However, no features of your app should undermine or endanger the overall purpose of the product. It’s incredibly easy to lose sight of a product’s actual function, especially given the fact that most of the people in your organization may not even have the same idea about what that function is. The first step in preserving your app’s effectiveness is agreeing with the other stakeholders on what it is you’re actually there to do. If you can’t agree on the end goal, you certainly aren’t going to agree on how to get there.
So now that everyone is on board with the underlying goal of the product, how do you know if you’re achieving it or not? Collecting data that can be analyzed to this end should be an absolute priority of your development efforts. This is a prime example of a feature that does not serve the goal of the application directly, but rather provides a mechanism for evaluating the app’s effectiveness. If no one in your organization is pestering you about installing or getting access to analytics, you’ve got a big problem on your hands. The people who are designing, viewing and recommending the devotion of development cycles to analytics work are the people who care the most about whether the product is actually doing the things you all agree that it’s supposed to do. If you don’t have any of those people, you need to become those people. Development analytics are the most, and maybe only, reliable tool for determining if your app is being used in the ways you expected, and whether the way it’s being used is supporting your goals.
Overall, determining and agreeing on the purpose of something you’re building is a too-often neglected endeavor and one that should pursued vigorously and continuously, and kept closely in mind as a product matures. People that care about making effective digital products will always raise this question when new features come along, and that will lead to products that do their job with increasing efficiency. It’s easy to lose sight of overall product goals with the daily deluge of bugs, new feature requests and business rules, but professionals that make concerted efforts to support a product’s fundamental purpose will be the most valuable assets to your organization in the long term.