One of the most controversial topics in Agile / Lean thinking at the moment is the Minimum Viable Product, or MVP. This article will try and clear up the misconceptions around Minimum Viable Product. This concept came from Eric Ries’ influential book, The Lean Startup. In that book, Ries suggests that startups should not focus on building a complex quality product. Instead they should quickly release a rough product that is used to gather information from customers. This then starts the famous “Build – Measure – Learn” cycle.
The term Minimum Viable Product is now being used and abused all over the world. Mostly by people who don’t understand the actual meaning behind the term.
The fundamental point about an MVP is that it is all about learning. Its purpose is not to win customers, nor gain market share, nor disrupt a market, nor defeat competitors. It has one purpose only: to create validated learning.
Startups are companies that by definition are operating under conditions of extreme uncertainty. More specifically, they are operating with extreme uncertainty about their customers. And about the value proposition of a product or service towards those customers. The MVP exists to reduce the uncertainty around the customers and what they value. This gives the business confidence to proceed with the product. Alternatively, they may choose to pivot or cancel the product.
Some people seem to think of MVP is a minimum set of features they would like to see. “OK we’ve come up with a list of 20 features in our Product Planning workshops. These 10 features are MVP, and these other 10 we can live without.” The problem is that this forgets that the purpose of the MVP is to learn, not to sell or convert customers. The only features that an MVP should contain are some form of value proposition, and the ability to record information about how customers are interacting with it. That is, some kind of analytics. There is no point in building ten features into a product when you don’t know if customers are interested in it at all.
Some people (for example, this article) criticise the concept of the MVP because it leads to poor products – they focus too much on the Minimum and not enough on the Viable. The MVP is not a final product and it is not an excuse for selling rubbish. The purpose of it is quickly produce something, learn, iterate, and either pivot (build something else) or persevere (make it better). The idea is to first Build the Right Thing (find something that people want), and then Build the Thing Right (make it really good so people love it).
Building the Thing Right before you find out whether people want it or not can lead to enormous waste (Newton, Zune, Kin), much greater than the waste of poor quality products. But of course you have to remember that the MVP is not the final or only iteration, it is the very first. The whole point of it is to gather learning which you can use to inform the future iterations of your product. If you build an MVP and dust your hands and walk away saying “Yep we did the MVP, so now we’re done”, you don’t understand the concept. See also this article.
Some people think that MVP is all actually old hat and that UX people have been doing it for years. But they call it Rapid Prototyping instead of MVP. Quickly create a prototype and test it with customers and let the learnings inform the initial design. Rapid Prototyping is definitely a good idea and should be done, but it is not an MVP.
A prototype is something that people test in some kind of usability lab. While this customer testing is valuable, it is not a product and is not being used in a realistic environment. The best way to learn from customers is to learn from how they use the product in a real-world scenario. Even if that is a shabby version of it. Not sitting in a lab in front of a camera and microphone. Get the MVP out and make sure it has analytics and start learning from real customers.