I’m done talking about MVP, let’s talk about real products

The concept of MVP is so ambiguous it leads to confusion in product design conversations.

When you hear “MVP,” what comes to mind? If you’re a regular person, you’ll probably think about the Most Valuable Player in some sporting match. However, if you’re reading this, you’re likely thinking about the famous (or infamous?) Minimum Viable Product. But, do you really know what it means?

I recently took part in a workshop where the facilitator asked the participants about their definitions of MVP. We all gave different answers. Most of us viewed it as a functional product that provides value to users, even if it’s not perfect. However, depending on who you ask, you will get a different interpretation.

Designers often associate MVP with crappy visuals and insufficient time to do proper research. Developers view MVP as squeezing in as much work as possible before the release date. Managers see MVP as the cheapest and fastest solution to satisfy stakeholders.

As a designer, I have my own issues with the concept. It bothers me that no definition of MVP includes making the product delightful or meaningful. Some designers have tackled this problem by using the variation Minimum Lovable Product or Minimum Marketable Product. But this doesn’t quite cut it.

Regardless of the different interpretations, the core of the problem lies in the confusion it creates in conversations around product design. So, why is the MVP concept so divisive?

The Lean Startup messed everything up

In the old days, the open-source community talked about RERO (Release Early, Release Often). It promoted frequently releasing software to get feedback and improve the product.

Around the early 2000s people in Agile circles began talking about MVP. It was understood as the smallest release of a product that adds value to its customers. A process that relied on rapid iteration and continuous improvement.

This classic definition understands the MVP as an entire product with only the essential features necessary to add value. Unfortunately, many people understood it as the infamous Phase 1 (we all know there is never Phase 2), using the MVP as an excuse to ship half-assed products.

In 2011, Eric Ries published The Lean Startup redefining the term as the smallest thing you could make to validate a hypothesis. He called this process “validated learning”, in which the primary goal was to identify risks and test assumptions before making product decisions.

Ries’ definition has nothing to do with releasing a working product. He actually advises against launching anything before having enough evidence to justify it.

At this point, conversations around product design started to get messy. Different understandings of MVP began to clash. Some maintained the classic definition of working software while others promoted the idea of MVP as an experiment.

In 2020, Marty Cagan presented an integrated concept of MVP in his book Empowered. Like the classic definition, he emphasizes delivering customer value as the primary goal. On the other hand, like Ries’ interpretation, Cagan also highlights its utility as a tool for validating hypotheses about customers and the market.

I like Ries’ concept about validated learning, but he shouldn’t have named it MVP. If he had just talked about experiments instead of rebranding the term, he would have saved product teams lots of misunderstandings. While I believe Cagan’s definition works best, Ries has sold more books, so I guess he wins the ownership of the concept.

The absence of consensus leaves each product team to create its own definition of MVP. Unfortunately, most interpretations prioritize releasing features as quickly and cheaply as possible, with little to no emphasis on learning, iterating, or improving the product. In fact, experimentation is often perceived as a risk rather than a learning opportunity, resulting in teams being punished rather than rewarded for it.

Should the MVP be an experiment or a product?

Shipping a quality product is the most expensive way to test an idea. So, unless you are absolutely sure that your product will be loved by your customers, don’t ship it. Instead, launch an experiment before investing time and effort.

Experiments are essential to understand if our idea makes sense.

Shipping quickly is irrelevant if we’re delivering the wrong product. The real question isn’t whether we can build a product fast, but whether we should build it at all.

However, just doing experiments without customer feedback is a complete waste. Is important to test a risky idea before investing in it, but real validation happens when users interact with the product.

Ship as fast as you can, but test every risky assumption, and learn from each release. Viewing MVP as an experiment encourages learning while seeing it as a working product incentivizes shipping speed. This combination is powerful, but it needs to be balanced.

How to talk about MVP with your team and stakeholders

I suggest avoiding the term altogether. Consider alternative language like ‘beta launch’ for limited-feature releases, or ‘experiment’ or ‘test’ for learning-focused initiatives.

The most important thing to understand is that building a successful product requires both experimentation and iteration. Experiment just enough to reduce uncertainty. Release as soon as you have something valuable for your customers. Iterate once you get feedback from the market.

In any case, if you insist on talking about MVP, make sure everyone on your team is aligned with the definition. And please, don’t let that definition be “the first crappy release of the product”.

I’m done talking about MVP, let’s talk about real products was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.