Startup hurdles: Making a mobile app with value

Startup hurdles: Making a mobile app with value

STARTUP HURDLES: MAKING A MOBILE APP WITH VALUE

Posted on Jun 18, 2014 11:30:00 AM

Assuming you know what you want your app developer to build, the next hurdle is to put it in writing. Although this might sound fairly easy, it's harder than it seems. During the writing process you'll be tempted to think of new features and add them in the list of requirements. What you have to keep in mind is that each feature will cost time, money, or both. Making a mobile app is all about focus, as apps are single-purpose tools. This makes it very important that you invest in features that offer business value.

So the obvious question is how. How do you write down what you want? Any software engineer would say that you use requirements and, although it's true, this isn't a very clear answer. Software requirements, as the name suggests, simply identify any element which is required for a software project to be completed. These can be features, but also lower-level technical elements. How you define your requirements is a point of much debate, but what we can agree on is that we need an approach that helps us ensure the value in each requirement we write. After all, we only want to invest resources in features that offer value.

USE-CASES: REQUIREMENTS WITH CONTEXT

One of the most popular approaches when writing requirements is the use of use-cases. A use-case simply describes a situation in which a user would use your product to achieve a goal. Use-cases always adhere to the same format;

Given <situation>, as a <user role> I want <feature>

Having this simple guideline is a big step forward for your requirements. The fixed format makes it easy to quickly define and read large amounts of requirements and by forcing your requirements to be user-oriented all features are automatically developed with the user in mind. This ensures that you'll be spending time on making features that have a sensible impact on your user's experience.
Another big benefit of use-cases is that the given situation adds context. This will allow developers and designers to better understand the problem at hand and the user's expectations. As a result, the features will feel more intuitive to the user. This means your users will enjoy using your app, which is crucial if you want them to keep using it.
Unfortunately, some requirements will slip in that don't really generate business value. Even with the use-case format, it can be hard to differentiate between a common and niche features. What we need is an even better way of ensuring our requirements add business value.

FEATURE INJECTION: PUTTING VALUE FIRST

A seemingly small modification to the use-case approach gives us feature injection. In this approach, the user has been put into the back seat. The goal: to make sure value is added with each requirement. As a result, feature injection uses the following format;

In order to <have benefit> as a <user role>, I want <feature>.

As the sharp observers will have noticed, the situation has been replaced with the benefit. The advantage of this is two-fold. First, we take away a level of assumption by forcing the requirement to contain the benefit we're aiming to deliver. When reading the requirement you should ask yourself why this user would want this benefit. If you don't know or there are multiple possible answers, you should dig deeper. Secondly, by stressing on the benefit, not the feature, we gain insight into the real value of the requirement to the end user. Not only do we know whether or not a feature has value, we also have a feeling for how much value a feature has to the user.

DON'T KNOW, DON'T CARE

The requirements we've been talking about have all been focused on the user. After all, the user is the reason we're making a mobile app in the first place! However, your app wouldn't be much good without technical requirements, but they should always be coupled to user-oriented requirements. As a result, you will never have to define them as long as you define user-driven requirements. You can then leave it up to you app developer to take it from there and to define the technical elements needed. To put it very blunt; as the product owner your responsibility isn't in the how, but in thewhat; as long as you define what benefits your user should get, your developers will figure out how the user gets them.

As the product owner your responsibility isn't in the how,
but in the what

  

Don't get me wrong, though. Showing interest in the technical aspect of your app and the mobile app development world is a must, as the benefits you define must be realistic. But you don't need to fully understand all of the technical details or be a developer yourself (preferably not, actually). Your key focus should be to create value for the user, nothing more, nothing less. You're welcome to discuss technical details with your engineers (they'll love it), but it shouldn't be your day-to-day work.

CONCLUSION

By defining user requirements using feature injection we can ensure that each requirement adds value. It also gives us a quantitative sense of value that we can use to compare two different requirements. The advantage of this is obvious; we can increase the amount of value generated by implementing the easy, high-value requirements first. This is especially useful for startups, where time is the biggest enemy and mobile app developers are scarce, and enterprises developing in-house apps, where the lack of benefit can nullify the ROI on a mobile app.
The most important question to answer with each requirement should be "does this add value for the user?" Adding benefits for the end-user is the best way of generating business value for your app. As a product owner it is your task to make sure this focus is maintained. As long as you do this, the technical implementation will be handled by the developers.
I'd like to close this post with an example of requirements done right. Whatsapp is a very simple app with only a few features. However, each feature is backed by a requirement that offers a benefit to the end-user. It shows what happens if you invest heavily in high-value requirements. Each feature is selected based on the value of the benefit, allowing them to spend a lot of time on implementing each single feature in this very small, but extremely valuable feature set. The proof is in the pudding; with over 400 million active users there's no denying the app is loved. Facebook bought Whatsapp for 19 billion USD, showing that the focus on end-user benefit is a viable means of generating business value, but the staggering active user count alone shows the inherent value of getting your requirements right.