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).
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 purpose of an 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.
MVP does not equal Lean Startup
Eric Ries wrote the famous book “Lean Startup”
A lot of people think that MVP and a Lean Startup are the same. This isn’t true. The idea became famous in the Lean Startup book by Eric Ries, but it had been around for a while.
A lot of people think it came from Steve Blank in 2005, in his book “Four Steps to the Epiphany”. But it was Frank Robinson who created it in 2001. It was part of his SyncDev methodology. You can read a bit more about that here.
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.”
An MVP is not a project scope list!
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.
This thinking is common in Waterfall type firms that are trying to go to agile. They do a big release every six months. So they define “MVP” as “the set of features and stories that we really want to have in that big release”.
That’s a scope list, not a product! This is completely missing the point of MVP. It is a small experiment that you quickly create to get some learning.
MVP is all the good features you can afford
This is similar to the last point. Some people try and stuff as many features as they can afford into an MVP. They want to maximize revenue for spend. So they figure out how much money they have and see how many features they can “buy” for that money. And then think that is their MVP.
This is typical of “big batch”, “mass production” or Waterfall type of thinking. Instead of Lean thinking, which focuses on speed, value and learning.
MVP contains just enough to learn about where you can create value. And where you can’t.
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 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 about MVP and funding.
If the MVP fails, the whole business is doomed
Some people think their whole business rests on the success of the MVP. Well it doesn’t (hopefully). An MVP is an experiment. Some experiments work, some don’t. Inventors don’t throw out their whole workshop when their first iteration isn’t successful! Some inventions take dozens or hundreds of iterations. Same with product development.
If the MVP doesn’t work, gather your learning, get back to the drawing board, and work on your next experiment. Facebook started out as a way for college students to look at class photos. It went ok but didn’t really wow anyone. But look where it is now!
The MVP is not a prototype
An MPV is not a prototype for user testing, it is a product!
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 (RAT)
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.
This video provides some good information about what an MVP really is, with examples:
Frequently Asked Questions
What are the limitations of Minimum Viable Product?
The main limitation of an MVP is that it is created quickly and usually doesn’t have a large set of detailed features. This can lead to some customers being disappointed.
What are Minimum Viable Product assumptions?
The key assumptions are:
- it is just an experiment, not a full product
- its purpose is to generate learning, not generate revenue
- an MVP must be iterated on, so it is not a final product.
What are three critical characteristics for your Minimum Viable Product?
The three critical characteristics are:
- it is designed to be iterated on and scaled upon (so must be extensible)
- it is missing features but displays good quality and doesn’t feel broken or cheap
- it is small and quick to create.
What are the factors to consider in making a Minimum Viable Product?
The main factors to consider are:
- It demonstrates enough potential benefit to potentially turn early adopters into regular users
- it provides some kind of feedback loop or learning mechanism
- It is missing features but has enough value to excite people.
