The Different Meanings of "MVP"

Minimum Viable Product

I first stumbled over the phrase of “Minimum Viable Product” when I took a deep dive into Lean Startup. The phrase might not have been invented by Eric Ries, but most people I meet refer to Lean Startup when talking about MVPs. Lean Startup is a great tool to set up experiments in order to validate assumptions on product, market, or any other aspect relevant to MVPs. By clarifying these assumptions, complexity is reduced step by step. So the primary goal of a “Minimum Viable Product” is to validate assumptions. This helps you decide whether you want to change direction (pivot) or to maintain the current path (persevere). In order to do this, quality is often a minor issue. Many assumptions can be validated with abysmal quality, many MVPs are thrown away after validation. A scribble, digital model, or Lego prototype might be enough to do this. “Value” is probably defined as knowledge, not as business or customer value.

Minimum Valuable Product

Unfortunately, the abbreviation of “Minimum Valuable Product” is also “MVP”. This doesn’t help, but let us understand what we mean here. When you look into Scrum you will find that quality is not negotiable. With Scrum, you have to produce a “Done” increment every Sprint, meaning it has to be potentially releasable. The word “potentially” points to the fact that even if quality is good enough for the product to be released, the feature set present might not be sufficient for a release. Scrum also focuses very strongly on “value” in every single product backlog item. Value is usually defined in categories that describe customer value or business value, so it is more about concrete usefulness for somebody, leading to a potential monetarisation, rather than building up knowledge to find out what might create value at all. So a “Minimum Valuable Product” is what comes out at the end of every Scrum Sprint.

Minimum Marketable Product

Most Product Owners I meet do not talk about Sprints or experiments when they say “MVP”. What they are really talking about is their urge to get a product out into the market place. This means they need the sum of several Sprints to produce enough value for the market to actually buy the product. This is what I call a “Minimum Marketable Product”. It’s the least amount of high-quality functionality the market is willing to accept and pay for. It’s what most companies would describe as the ideal outcome of a “release”.

Minimum Lovable Product

This expression originates – as far as I know – from this article by Henrik Kniberg. In addition to a MMP, a MLP is not only sellable but the customer actually craves for it. Think in terms of the Kano model: A small set of features creates a high delight in the customer, leading him, in some cases, to even camp out in front of the store in order to buy it. Ideally, a MMP is a MLP at the same time. However, in most cases I know, creating a MLP takes several releases while a MMP is possible in every release.

Bulky Marketable Product

The above sections always talk about some sort of a “Minimum” set of functionality. Most traditional organizations talk about “MVP” but actually define some sort of bulky behemoth. They state that the new product “must do everything the old one did” before releasing it or believe “nobody will buy it without this full set of features”. These assumptions lead to multi-year initiatives and create a “Bulky Marketable Product”. Such a BMP violates the principles of quick feedback and learning from the actual market customer. If you want to build products as a BMP, then please do not call it an MVP.

What does this mean for you?

Next time you talk to somebody using the term “MVP”, ask her what she is looking for. A throw-away prototype to speed up learning? A high-quality product increment? A product with a minimum set of features to sell in the marketplace without damaging the brand? Something customers will actually love? A big chunk of bulkiness? The answer to this question will highly influence the way you create your product, the contents of your Product Backlog and your quality guidelines (e.g. as defined in your Definition of Done). Choose the right approach for your situation at hand!

Did this little post help you? Please let us know in the comments section. Thank you!