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.

It helps to always keep in mind the point of these MVP Tests, which is to get to this notion of Product Market Fit.  That’s when we actually have a viable product.

But beyond the definition, it’s equally important to recognize that it’s not enough just to think you have achieved Product Market Fit (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 utilize MVP Tests to hopefully achieve Product Market Fit.

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 Product Market Fit?
  • How do we know we have actually achieved Product Market Fit?  What level of “proof” do we need?  How many customers need to agree to buy it?
  • Is the MVP Test 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 Product Market Fit?
  • Who is responsible for discovering Product Market Fit?
  • Who makes the decisions regarding each MVP Test?
  • How long should we keep trying to achieve Product Market Fit before we give up?
  • What should we do when we identify a pivot opportunity?
  • Do we need to wait until we have identified Product Market Fit before we start building production software?
  • Is an MVP Test the same as “minimum product?”
  • Is Product Market Fit the same as “product vision?”
  • Is an MVP Test the same as MMF (Minimum Marketable Feature)?
  • What happens after we have achieved Product Market FIt?
  • How do I go from MVP Test to backlog items?
  • Is Product Market Fit a moving target?  Can I lose it once I’ve found it?
  • Is there only one Product Market Fit for a given market or could there be many?
  • Do we handle MVP Tests 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.

NOTE: Updated in January of 2014 to reflect consistent nomenclature (MVP Tests vs. Product Market Fit vs. Product Vision).

Share This