Misconceptions around Minimum Viable Product

misconceptions around minimum viable product

Build Measure Learn loop

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.

What is a Minimum Viable Product?

This concept came from Eric Ries’ influential book, The Lean Startup (which you should definitely read if you haven’t already).

lean startup book

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 for those customers. The MVP is to reduce the uncertainty around the customers and what they value. This gives the business confidence to proceed with the product. They may also choose to pivot or cancel the product.

The MVP is not a set of features

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.

The MVP is not a final product and is not an excuse for poor quality

Some people (for example, this article) criticize 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). And this waste is 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 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.

The MVP is not a prototype

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.

Riskiest Assumption Test

Some people have moved from talking about MVPs to RATs. This stands for Riskiest Assumption Test. The idea is that when thinking up your product, you should identify your riskiest assumptions. These might be things like “will people want to pay for this?”, “will this scale past 1000 users?”, “will people share their location data or photos with our app?”.

These are assumptions that could completely kill your product if proved false. Focusing your initial release on testing these risky assumptions can give very useful information. This data can inform your decision to proceed, kill or pivot your product.

RAT can be a useful way to reframe your thinking about an MVP. It can move your thinking from “a big desirable list of features” to “the smallest set of things we can release to get it out and learn from”.

If your organization is struggling with the concept of an MVP, then reframing it as an RAT (Riskiest Assumption Test) might help them move away from those mistakes.

Of course, an RAT is again an initial release, and not a final product and not an excuse for building bad products.

Leave a Comment:

1 comment
Add Your Reply