Minimum Viable Product
One of the most important concepts in all of software is the notion of minimum viable product (often referred to as “MVP”). But if you’ve been around software products for a while, you know that term is used in many different ways, and while the term intuitively resonates with people, there’s often a lot of confusion about what this really means in practice.
You can find it defined as the smallest possible experiment to test a specific hypothesis, all the way up to the the tangible realization of a product vision.
I’m not arguing here that any of the definitions out there are right or wrong, but I am arguing that the confusion is not helping product teams, and this is simply too important of a concept to have so much ambiguity.
I have long defined minimum viable product as the smallest possible product that has three critical characteristics: people choose to use it or buy it; people can figure out how to use it; and we can deliver it when we need it with the resources available – also known as valuable, usable and feasible.
I love the concept popularized by Eric Ries of the smallest possible experiment to test a specific hypothesis, but I refer to that that as an “MVP Test” so that people don’t confuse an experiment with a product.
But beyond the definition, it’s equally important to recognize that it’s not enough just to think you have defined MVP (which is what most product owners do – it’s their opinion), you need to have evidence that you have this – we call this validated customer learning.
Further, I define product discovery as the process of how we identify the minimum viable product and get this validated customer learning.
While my definitions above hopefully sound straightforward, I still get many questions from product teams about this critical concept:
- How do we rapidly converge on an MVP?
- How do we know we have actually achieved MVP? What level of “proof” do we need? How many customers need to agree to buy it?
- Is the MVP intended to be something that we sell, or is it just an experiment?
- If it’s something we intend to sell, what if a customer won’t buy it? Does this mean it’s not MVP?
- Who is responsible for discovering the MVP?
- Who makes the decisions regarding MVP?
- How long should we keep trying to achieve MVP before we give up?
- What should we do when we identify a pivot opportunity?
- Do we need to wait until we have identified MVP before we start building production software?
- Is MVP the same as “minimum product?”
- Is MVP the same as “product vision?”
- Is MVP the same as MMF (Minimum Marketable Feature)?
- What happens after we have achieved MVP?
- How do I go from MVP to backlog items?
- Is MVP a moving target? Can I lose it once I’ve found it?
- Is there only one MVP for a given market or could there be many?
- Do we handle MVP the same way for products for consumers as we do products for businesses?
These are all important questions and I can understand why people can get confused, so I thought I would try to address these with a series of articles. I’ll do my best to make this abstraction real, so you can see the value and hopefully put this fundamental concept to work for you.
Please feel free to send me additional questions and I’ll try to incorporate them in as well.