MVP – Minimum Viable Product

13/08/2013

In my previous post I was trying to offer insights into the lean methodology. But the process in startups does not end with validation of a problem and solution. Even if we have performed validation well at first, we can never be sure enough how precise our findings are and if every property and feature of a developed product would be really appreciated by customers. Therefore, it is better to start with something small at first. With something that implements only a solution for very basic scenarios and maybe is neither fully automated. It is good to start with a minimum viable product (MVP) – an entry point for development in lean startups. The notion MVP makes sense independently of the lean methodology.

MVP = the product with the smallest possible set of features so that it would still be used by a substatial part of a target group

(for purposes of the lean startup: so that it would be used by most of early adopters)

Measure, measure, measure, …

For purposes of the lean startup, MVP must additionaly contain measuring tools which allow you to observe characteristics of success and failure. For example, you should be able to capture how many people left immediately after displaying an intro page, how many people clicking on “sign up” were discouraged by a registration form, etc. Thanks to that you can obtain basic data allowing to tune up and improve your product. Also do not give up on the personal contact with first users. Realise that these users have been willing to cope with your buggy and simplified version of your product. Therefore, they should also likely be willing to provide you with a useful feedback.

If your product development is going to the dead end, it is better to find it before releasing a complete version of it. For instance, you can find out that a browser plugin would be found more useful than a web service or vice versa. Such a change leads to trashing big portions of code. You must find it out as soon as possible and MVP is the right way to do it.

What is MVP and what is not

I have found two basic types of MVPs that appear repeatedly in web-based startups. They do not negate each other and so they can be combined to some extent:

  • Concierge – This notion is used for products where automatization is replaced by human work on background. It is especially proper for products where an immediate response and elaborated UI are not that important. Typically, the product only consists of a better landing page and a form for request submission.
  • Single-feature application – Even if the final product should be a complex system, only one feature is developed properly. It should be the feature with a potential to attract target audience (even if it was just an attractor, not a key stone). It is especially proper for products that are depend on UI and an immediate response.

Example: One of  TechPeaks startups is going to develop a product allowing bands easy production of on-line music videos. In the end, they want to allow mixing music videos from videos available on-line with a Creative Commons licence. Nevertheless, they want to offert a single-feature MVP first, allowing to upload a static picture displayed with a music track on YouTube. Of course, such a product attracts less attention than a final product, but it may earn its early adopters. This way they can get users to learn on and measure on. In this case they can also combine with concierge, because even implementation of a simple service producing single-image videos can be hard to implement in a week. However, with concierge, they can design a web page and a submission form in one day.

Of course, one can image more complex MVPs, but it is always necessary to discuss deeply, whether it is really MVP, or we only lie to ourselves. Technologists and developers by heart tend to lie themselves often. For instance, it is hard for me to respect the fact that an architecture of a final product does not need to build on an architecture of MVP. Therefore, instead of hacking something quickly, I develop MVPs with isolated modules, data schemas and no code redundancies. It is very hard to unlearn.

If you find out that development of MVP should take a man-month or more, you must justify well that it is really an MVP. It is not given that the first MVP succeeds. Rather it does not. Then you have to learn from that, change something and move further. And this may happen even several-times and you trash your code everytime. Smaller product you develop, less code you trash, more repetitions you can handle and a bigger chance for success you have.

If MVP does not offer any real services to a customer but only presents a future product, it is not MVP. It can only by used for solution validation (see the previous post). The interesting point is that it can sometimes be time-efficient to skip a solution validation phase and validate the solution directly with MVP. However, this is efficient only if MVP implementation is taking approximately the same time as creation of a solution presentation (typically, if you go with a concierge MVP).

Conclusion

As I have written at the beginning of the post, MVP is just an entry point of lean startup product development. Of course, it is further necessary to build a real product out of it. I am not telling too much if I just note that addition of any feature should be accompanied with an idea – assumptions extraction – validation cycle again. The product is then developed in small iterations rather than in big release batches. But it would be enough matter for the new post.

To conclude, I summarize advantages and risks of MVP:

Advantages:

  • MVP protects you from trashing months of development.
  • Earlier customer feedback → bigger motivation for developers and better marketing.
  • Sooner you are online, more valuable you are in eyes of inverstors, because you have a history and historical data to present.

Risks:

  • It may happen that MVP would have a different target group to a final product.
  • Underestimated minimum – yes, sometimes a customer must see more of the product in order to be attracted and take the product seriously.
  • Company/developers credibility affection when the product is too untested and buggy. In most cases, bugs matter less than developers think. Nevertheless, there are specific products which cannot effort being buggy (e.g. customer’s data transformation).

Links to relevant reading:

Leave a Reply

Your email address will not be published. Required fields are marked *


*