Lately, the term MVP—Minimum Viable Product—has been receiving undeserved backlash from various product gurus. Despite its intuitive name, there is still a lot of confusion surrounding its meaning. Calls from these influencers to change its definition only add to the confusion.

‍

As someone who has built products for 15 years and spent the last 8 years consulting on creating new value propositions, product discovery, and early validation, I’d like to share my perspective on this term. I believe that MVP still holds significant value, and I want to explain why product managers—and others in the field—should continue to use it.

‍

What’s the Confusion About?

While the definition might sound intuitive, people interpret it in different ways, ranging from the smallest possible experiment to a tangible, working first-version of your product. So the question we need to answer, and which I will try to address in this article, is the following:

Is it an experiment, in which case the MVP can take many shapes or forms, or is it an actual functional product that customers can use?

‍

A brief history of the MVP

Let’s start by looking at the origin of the term, as some of the confusion stems from its very own creators.

The term "Minimum Viable Product" (MVP) was coined by Frank Robinson, the co-founder of the product development consulting firm SyncDev. However, the concept was popularized and brought to widespread attention by Eric Ries in his book "The Lean Startup."

Frank Robinson introduced the term MVP and defined it as the product with the highest return on investment versus risk. He described it as the product that allows a team to collect the maximum amount of validated learning about customers with the least effort.

Eric Ries popularized the concept through "The Lean Startup," emphasizing the MVP as a critical tool for startups to test hypotheses, validate learning, and iterate quickly based on feedback. To quote Eric, an MVP should be “the smallest thing you can make or do to test your hypothesis.” Ries's interpretation focuses on the MVP as a means to minimize the development cycle time and maximize learning about the customer. He advocates running lightweight experiments to de-risk assumptions, and he called those experiments MVPs.

So, it’s quite clear that the inventor of the term, Frank Robinson, defines it as an actual functional product, while Eric Ries, who brought the term to fame, defines it as an experiment. 

‍

Who's Right?

The answer, perhaps unsurprisingly, is that both interpretations have merit depending on the context.  Robinson's view aligns with the need for a functional product that customers can interact with, providing tangible feedback. Ries's approach, however, emphasizes the importance of rapid iteration and learning, which can sometimes mean using non-functional prototypes or simpler forms of testing. 

‍

That said, I would still go with the original definition of the MVP—an actual working product. Here are several reasons why I believe this is the correct approach:

‍

#1 We already have established terminology for testing

Experiments and prototypes are already existing, widespread, and accepted terms for rapid experimentation, learning, and validation of product hypotheses. The actual problem is that product teams do not do enough of these. Adding MVP to the mix as yet another type of experiment is not going to make people experiment more.

‍

#2 It’s natural language 

If the designation - Minimum Viable Product -  contains the word product, then subconsciously people will expect to get a product. And not only subconsciously.

When I was still running my software company, our customers came to us to build an MVP. I am 100% sure they were not expecting a paper prototype or a video demonstration of how their product would work. Similarly, when an executive wants an MVP and asks their product teams for it, they envision an actual product, not just a landing page. It’s hard to beat natural language in this context.

Of course, we were guilty of jumping right into building the MVP, just as product teams follow orders and start building MVPs, but that has nothing to do with the term itself. If we did not have the term MVP, there would be something else, and people would still build without proper discovery and validation. It’s actually good to have a term that defines the minimal viable version of your product using terms a human would use in normal speech. 

‍

#3 Different learning objectives

One common interpretation across the board is that the MVP should serve as a learning platform, which I fully support. But the question is: what are we trying to learn? If we all agree that the ultimate goal for the product is to achieve Product-Market Fit, then it will need to check all the boxes of desirability, feasibility, and viability. If one is missing, the product will fail.

That’s why for each stage, we need to use the right tool or method to validate assumptions and learn.

‍

Prototype

A prototype is an early sample, model, or release of a product built to test a concept or process. It is a tool for visualizing how the product will function or look, often used to gather user feedback and make improvements. Prototypes can range from very basic, such as paper sketches, to highly interactive, simulated versions that closely resemble the final product. As such, the prototype is a quick, inexpensive way to test desirability. Examples include landing pages, Wizard of Oz, video explainers, email campaigns, crowdfunding pages, paper prototypes, and paid ads. 

‍

Proof of Concept (PoC)

Once there is confidence in desirability, it's time to commit more resources to build a PoC. This is primarily used to verify that a certain concept or aspect of the product can be developed, focusing on proving the feasibility of the idea. It’s particularly important if the product relies on new technologies like AI or complicated, specialized technical implementations. A PoC is typically developed to a point where it can be shared internally but is not usually exposed to external users.

‍

Minimum Viable Product (MVP)

But most importantly, a product needs to be viable, meaning people are willing to pay to use it. This is what the MVP is for. It’s a version of a new product that includes only the essential features necessary to meet the needs of early customers and provide feedback for future product development. So, it’s a market-ready product, though minimal, used to validate the business concept, aka viability, with real customers.

‍

How to Build an MVP? 

In this next section, I want to share a practical approach and guidelines for developing a good MVP. After 15 years of building MVPs—many of which were costly failures that could have been avoided with proper product discovery and experimentation—and 8 years focusing exclusively on validation and experimentation, I believe I have an end-to-end approach to build MVPs the right way. This approach, we now use at Design Sprint Academy,  incrementally de-risks the process through learning and iteration, using the right methods and involving the right people at every step.

‍

The process of building a successful MVP can be visualized through a structured approach that involves several key steps. As a side note, this process aligns with the Osborn-Parnes model of Creative Problem Solving (CPS), which has been tried and tested for decades. It's something I recently discovered and wish I had known about twenty years ago.

Step 1: Opportunity Finding

The starting point of many projects is usually fuzzy, unclear, and messy. Stakeholders often make broad requests such as, “We need to do something with AI,” “We want to target a new customer audience with our product,” or “What features do we need to build to be competitive?” These are hardly problem statements primed for immediate solution development.

To navigate this ambiguity, we use frameworks such as Cynefin to help stakeholders sense the context they are in, prioritize their requests, and establish a way forward towards a clearer product vision.

‍

Step 2. Product Hypothesis. 

At this stage, we are formulating hypotheses about how our product will solve customer problems. To guide the conversation, we use the 4U framework, which provides clear criteria on how unworkable, unavoidable, urgent, and underserved a problem is. These clear criteria make it easier to align stakeholders and gain their buy-in, which is often one of the biggest headaches for product managers. You can read more about it here. 

‍

Step 3. Minimum Viable Customer Segment

This step involves identifying a group of potential customers who share similar needs and characteristics, and is small enough to dominate but large enough to be sustainable. A smaller, well-defined audience allows for more focused feedback on your product. Additionally, a smaller audience means that when it’s time to build the MVP, you can focus only on essential features, reducing development time and costs. Typically here we’d review existing user research, run user interviews and build personas and customer journey maps. 

‍

Step 4. Problem Definition

With data mounting, we can now engage stakeholders (decision makers) to clearly define the problems or opportunities, decide what experiments to run, and get the buy-in to proceed. This process is usually smooth because, at this point, it is clear what the value of solving the problem is for both the user and the business. At Design Sprint Academy we created a specialized workshop, structured approach - Problem Framing - for this purpose. 

‍

Step 5. New Value Proposition

This stage focuses on creating the new value proposition and testing it with the customers we identified earlier in the process. It involves lots of experimentation, prototyping, and validation. While there are many methods available, we prefer using the Design Sprint. I have yet to discover a more efficient, faster (it takes only four days), user-centric approach to designing new products that involve and align all stakeholders (business, design, and technology).

Additionally, a validated and tangible  prototype will make conversations with stakeholders much easier, as they will clearly understand what the product is about, securing their buy-in more effectively.

‍

Step 6. Learn & Decide

Based on the learnings, you might need to revisit and possibly change the customer audience or even the problem definition. In some cases, you may decide to pivot or kill the product idea altogether. However, if you receive validation, you can move on to the next stage. It's important to note that the validation at this stage is focused on desirability.

‍

Step 7. Proof of Concept

‍

I see this as an optional step, especially if the product is built with familiar technologies or if the team has reasonable confidence that it’s feasible to build the idea validated in the previous stage. However, if you are using a new technology, such as creating your first AI product, it would be a smart idea to start with a proof of concept (PoC) before committing your resources to full development.

Similar to the design sprint prototype, a PoC will help in securing buy-in and support from stakeholders. By the end of this stage, the product should have both feasibility and desirability reasonably validated.

‍

Step 8.  Business Case

Now that the value proposition is clear and the technical implementation is known, product and business stakeholders can build a business case. Many organizations start with this step, filling Excel files with unrealistic projections not backed by any data or evidence. However, at this stage, there is enough evidence and confidence to start putting together a realistic business case. Our go-to method for this is a Business Model Workshop to create the busines model (the viability part of the equation). It’s Ok to have a few iterations on this. 

‍

Step 9.  The MVP 

Finally, we’re here. No business model can test viability as effectively as a real product in the market. That’s why the MVP is essential. However, we also want to ensure the product roadmap contains only the essential set of features that allow us to test viability effectively.

‍

After the MVP is launched, product teams can enter more familiar territory to scale and grow products based on the learnings they get. 

‍

Timeline to an MVP

So, how long does it take to develop an MVP based on this approach? It depends on the context and how broad or fuzzy the starting point is, but typical timeframes are as follows:

• Step 1 to 4: From initial idea to clear problem definition – 4 weeks
• Step 5-6: Testing and validating new value proposition – 2 to 3 weeks
• Step 7: Proof of Concept – 4 weeks
• Step 8: Business Model – 1 to 2 weeks
• Step 9: Plan, Build and launch an MVP – 1 to 3 months

‍

Conclusion

I believe that much of the confusion around MVPs stems from the lack of context within a broader process. When teams skip discovery and validation to jump straight into building MVPs, it's no wonder there's backlash. In reality, the call is for more learning, more experimentation, and using those insights to build meaningful products.

That's why I think the original definition of MVP should not change—it's a good one. Instead, we should focus on understanding how MVP, along with other tools and methods, fits together in the process of bringing products to life. By doing so, we can ensure that MVPs are both effective and valuable.

‍