Don’t just ship features – validate what you assume

Validate what you assume in mobile apps

Now you can build your applications much faster and cheaper than ever before thanks to technology. Although it can tell how to build stunning apps, it will certainly not explain why to do it. It is you who has to find the right answer. However, you should bear in mind that the opportunity to ship fast and plenty will not make you more successful. Sometimes it works the opposite way. Shipping faster makes you just fail faster.


Best product

Many believe that the essence of the product is expressed by the set of features it implements. This approach leads us to a concept of feature-driven software development. As it focuses primary on the functionality, the criteria for the success are based on the measures related to the features’ implementation. For example, checking against functional requirements specification and the quality of implementation. In this case “the best product” = “list of properly implemented features”. What seems to be missing in this equation is an answer to the fundamental question of product development: why should we actually implement these particular features?

Think in product, not in features

The missing part of the equation is the user – it is a real person who actually defines what is “best” and what is junk. We should never omit the question “for who do we build the product?”.  No marketing, nor brand engagement can change this. The product has to be made according to the user’s criteria and not the criteria you assume or it will perish.

The feature driven development presupposes that product quality will drive product desirability. In fact, it is often the opposite. Users tend to accept the quality issues of products which they find desirable. Slack – a business messaging app – might be a good example here. One year after the launch it was used already by a half a million of people. It became the fastest business growing app of all time. Slack was a long awaited game changer. It was a greatly desired relief from e-mail inbox deluge and associated formalities.  A New York Times reporter stated: “I have a feeling of intimacy with coworkers on the other side of the country that is almost fun. That’s a big deal, for a job”.

Slack is not perfect though. Constantly incoming notifications cause distraction with its beeps and buzzes. Slack provides a multi-channel informal communication environment. Users love its search option and tagging feature, but still it lacks many basic built-in tools e.g. calendar, knowledge sharing base, etc. That make you dependent on third-party providers to have these capabilities. The best products have actually many issues, but when people like them they stop being issues anymore. It’s a case when the quality is perceived through desirability. Love is blind, as they say…

Define motivations, don’t define implementation

The success of Slack is not an accident though. The secret lies in the fact that it simply responds to the core user needs. People hire products not for their features but for the problems they solve. A successful product simply responds to what people want. And they want to succeed and change their lives for better. They will choose the best product for them, despite its possible flaws, shortcomings or minimalist design. Some times too many features can be very confusing.

 

However, to uncover people’s motivations we cannot simply ask them what they want. As Henry Ford stated:

 

“If I had to ask my people what they wanted, they would have said faster horses”

 

Paradoxically there is a big difference between what people want and what people actually need. Asking about problems they are facing is not enough. To understand users we have to interview them and observe how they cope with their problems in everyday life. They often verbalize their concerns in the language of the available tools. Usually what they need is not an improvement of the existing solution but a radical change. Innovation is about creating new qualities and new vocabulary – going beyond the actual. A first step towards the innovation is to uncover the real motivations. Eric Portelance summarizes in the following way::

“[Most successful products are created by] people who understand the importance of creating products that solve real customer problems, and have a set of tools and frameworks like jobs-to-be-done that they use to identify and validate the real human problems they’re trying to solve in the market”

Validating assumptions

This conclusion should effectively shift our focus from the feature perspective to the job perspective. Features should actually be the very last thing to think about. Instead, the very first thing to start with is to know the user. At Nomtek we consider validation a crucial test of our knowledge about a person. We don’t trust even the most appealing or revolutionary ideas unless we test them against the real data. Validation of the assumptions became an inherent part of our product development process. We apply an iterative approach by working in short Design Sprints. Every sprint starts with the domain problem understanding and solution proposal. It ends with a working prototype that is subsequently validated it in the real environment. This is our way keep a constant focus on the things that really matter in successful software development – the question “why we build this app”.