Debunking Common Misconceptions Around the MVP

Be clear whether it's an experiment or version 1

Product teams love "Minimum Viable Products" (MVP). This concept helps so much in focusing on what is needed next and eliminating or postponing everything else. However, behind this seemingly straightforward concept lies a web of misunderstandings that often lead to misinterpretations and missed opportunities.

Maybe we should even ditch the term? But not so fast. Let me try to shed some light.

Before we start, let’s immediately scope out the first clunky version of a product which is neither valuable nor usable nor anything else but just a minor iteration of the engineering team. In no way, this should be called an MVP.

Also, forget this ill-famous illustration of the idea of an MVP:

I believe this is totally misleading because these different “products” shown do not address the same needs. When you add functional as well as emotional jobs to be done, this becomes apparent immediately:

Would you travel long distances with the family on a skateboard? Or cruise the Alps on the weekend with your buddies from high school on an e-scooter? See…..

Below, I will explain a better visual. But before that, let’s focus on two relevant interpretations of the term:

MVP as an Experiment to Learn From

“Think of an MVP as the 'test' version of your product, designed to validate assumptions and gather user feedback, rather than a complete, polished solution.” — Eric Ries

With that definition, Eris Ries popularized the concept of an MVP. Note how he emphasizes the learning aspect here. In that sense, an MVP is an experiment more than it is a product. It serves as a vehicle to test and validate critical assumptions about a product.

Of course, it could be a product or feature, implemented just enough to collect feedback. But it doesn’t have to be — it doesn’t have to be working software even: In Value Proposition Design, Alex Osterwalder and co-authors explain how both, the Business Model Canvas and the Value Proposition Canvas can be utilized as MVPs to validate assumptions about the Ideal Customer Profile (ICP) and their specific jobs, pain, and gains. Just with paper and Post-It’s, no software at this stage.

And even when we build software, it might be a prototype rather than a “Version 1” (see below). I like to call it prototype because:

• It focuses on the key parts of the user journey but ignores edge cases.

• It is working software but in no way complete, e.g. it ignores QA aspects, coding conventions, or scalability issues.

• It is what I love to call throwaway software: not even meant to be used later on but focused purely on learning — maybe even built with specific tools, such as Low Code / No Code platforms.

While this approach is totally reasonable, I wonder whether the term MVP is actually right: it is neither a product (nobody can really use it) nor viable (we cannot sell it). Hence, I would recommend referring to experiments or prototypes instead.

OK but what if we really build a working product? This brings us to the second interpretation of MVPs:

MVP as Version 1

"Remember, an MVP is not the final destination; it's the starting point. It's the foundation upon which you can iterate, improve, and create a remarkable product." — Marty Cagan

That definition, even though it doesn’t explicitly say so, already goes more in the direction of working software: a version 1 product, a beta program, a feature only made accessible with an early access program, or similar. Something that at least a certain fraction of customers can try and use — as opposed to sticky notes or fake door landing pages.

Even more, it’s assumed to serve as a starting point for later iterations, as an initial version of our product (software in our case) that will be extended and built upon. Very much in line with the Build—Measure—Learn loop of Lean UX, it assumes:

• We consider a future product but then reduce to the max in order to focus on the most essential capabilities first.

• We truly build and deliver that bare minimum and ship it as our version 1 product to customers, at least to some of them.

• We observe customers using it, ideally with built-in metrics.

• We learn from that usage data, extend, and improve our product.

• We then continue the loop.

Why the ICP is Critical

A visual also shared oftentimes to illustrate the idea of an MVP is this:

This diagram is very much consistent with the above definition of a Version 1: Imagine the full product across all relevant aspects of the software (light green), but then focus on only the bare minimum to create something already valuable enough (dark green). Think of it as a small piece of cake from the bottom to the cream — not just one layer of the cake.

To select that bare minimum, you need to be crystal clear about your ideal customers and their jobs, pains, and gains. Specifically for B2B, just the type of customer won’t be enough but you need to understand target user personas. Imagine, you are building a better product for truck-based logistics — will you improve the life of their CFOs (e.g. by providing efficiency gains), their Logistics Managers (e.g. by making route planning easier), or their truck drivers (e.g. by providing simpler tools to be used while on the road)? Only with that, you will be able to sufficiently narrow down the required user journey.

Based on the learnings from that initial version, you can then extend your product offering:

Depending on stage and maturity, this might mean still focusing on the same customer segment but extending your offering along their user journey — or addressing adjacent customer segments.

In any case, it’s crucial that you initially reduce to the bare Minimum of your customer’s needs, then validate your assumptions to find a Viable solution that you, finally turn into a Product.