You often read about "fail early, fail often", which seems overly negative. Who wants to fail, right? That's why we prefer to say "try early, learn fast". But what does it really mean?
We are often in situations where our customers want to see most of their planned and intended functionality in the very first version of their product. They feel that the product should be launched with a version that is as mature as possible - only then will it have an impact on the market. But this is a big problem. Why is that? Because the more features that are developed up front, the more resources are used and potentially wasted on something that no one wants.
Planning, design and development all cost a lot of money and time - the more you do in the beginning, the higher the initial investment. And with higher investment comes higher risk: What if users' priorities are elsewhere and you discover this after launch? Similarly, the frustration of the team increases if, despite their best efforts, the product fails to achieve the desired success at launch.
Of course, you can reduce this risk by conducting user research. And you should do it - we advocate it all the time! However, it will not make your launch 100% risk-free, because user research is usually conducted on a concept or prototype basis, which, depending on the feature, may not reflect real usage.
Get the MVP on the road quickly
Shorten the initial development phase by focusing on the minimum viable product (MVP). And by minimum, we mean minimal: The features you develop at the beginning are reduced to the bare essentials - while still delivering the core value to the user. All those other cool features you had in mind are put in the backlog for the time being. This not only saves time and money, but also reduces the technical challenges, at least at the beginning.
It also allows you to get users involved at an early stage, and to develop the product in a user-centric way (we all know the feature request lists for our favorite tools). This ensures that with each new version of the product, only the features that users really need are added. It also allows us to plan and deploy resources in a more targeted way.
If this approach is maintained throughout the product development cycle, user acceptance and focus can be tested again and again - in the spirit of "try early, learn fast".
Overcome your shyness
Nothing is born perfect - especially the first version of your product. But "minimal" does not mean that you should go live with unfinished functionality. In fact, this should be avoided, as users are likely to be put off and, in the worst case, never use the product again. Instead, requirements need to be broken down to their core functionality. In a first step, the scope should only include enough to leave a basic value for the user. Everything else is cut out and put in the backlog.
It is also important to mention that MVP does not mean having the same standard functionality as your competitors out there. Quite the opposite. It means having the core functionality that makes you different. What makes your product special. For example, if you decide to build a new to-do app, your very first version needs to be more than just a standard list of checkboxes. You need to have something unique that sets you apart from your competitors.
Let's take the checkbox as an example again. The (Not Boring) Habits app from Andy Works started out as just that: a checkbox to tick if you did your habit that day. But they knew that the market was crowded and many other habit trackers were already building sophisticated tracking, stats and dashboards. How do you compete with that? They approached it by focusing on the core: The joy of ticking off an item. So they created the best checkbox the world has ever seen! They put a lot of effort into the styling, the behaviour and the gamification of how you tick it - they made it crazy to tick that checkbox! Only later did they add more and more functionality.
An approach for everyone?
We'd argue that this approach is great for all products. But it would also ignore the specific context of your business. What do we mean by that?
If your product is in the context of a well-known company that is identified with high quality user experiences within its products, you can be sure that your users' expectations are high. You need to meet those expectations and ensure that your users have a good experience with your product. You need to protect your image - your brand.
In this case, it may make sense not to release your first version of a product to the public. You can start by making it available only to certain groups through closed beta testing or internal roll-outs. This allows you to gather real user feedback early on - without putting your reputation at risk.
On the other hand, if you are in a startup context, it is often about shipping your product often and early. This may be due to financial or investor pressure, or simply to be one of the first to market. Startups are usually built around a core idea, and to get their piece of the pie, they need to get to market quickly. So they have to find the right balance between going live with a product and letting it mature.
How to prioritize features?
So far we have avoided a big question: How do you know what to focus on?
A proven method we like to use to prioritize and plan development is the User Story Mapping method developed by Jeff Patton. It is used to think through all possible and desired user steps. In a workshop with product owners, developers and designers, we tell the story of how a product is used by collecting the most important user activities on post-its and listing them from left to right. In the second step, we look at these user activities again and add details. The result is a map that looks something like this:
We can then move the user activities back and forth - or eliminate them altogether and focus on the essentials. For example, in the map above: What does the MVP of "get to work" look like? What can we leave out? Can we skip the shower or breakfast? Actions that are not central to achieving the user goal are simply moved to a separate line. Each of these lines can be a separate release that we tackle after the MVP is released. In the spirit of "try early, learn fast" we have the opportunity to evaluate the success of each release and make any necessary adjustments to the direction of the next release. In this way, we give each release a chance to learn from it and ultimately create a product that fully meets the needs of its users.
