INNOVATIONWeeks to result

Minimum Viable Product (MVP)

Build the smallest thing that lets you start learning from real customers

Problem it solves

stagnant innovation

Best for

People looking to apply Minimum Viable Product (MVP) in their work and life

Not ideal for

Those seeking quick fixes without sustained effort or reflection

Overview

Why this framework exists

The Minimum Viable Product is the version of a new product that allows a team to collect the maximum amount of validated learning about customers with the least effort. It is not simply a smaller or cheaper product; it is specifically designed to test fundamental business hypotheses. The MVP may lack many features that will prove essential later, and it may seem embarrassingly simple, but its purpose is learning, not revenue.

MVPs come in many forms depending on what needs to be tested. A video MVP (like Dropbox's explainer video) tests demand without building the product. A concierge MVP delivers the product experience manually to a tiny number of customers to learn what they value. A Wizard of Oz MVP presents an automated facade while humans perform the work behind the scenes. A smoke test MVP uses a landing page or fake door to measure interest before building anything.

The critical principle is that any additional work beyond what is required to start learning is waste. Entrepreneurs consistently overestimate how many features are needed to start gathering customer feedback, and they underestimate how much can be learned from a rough early version. The MVP challenges entrepreneurs to question every assumption about what customers need by putting something real in front of them as fast as possible.

Core principles

5 total
  1. Any work beyond the minimum needed to start learning is waste.
  2. The right form of your MVP depends entirely on which hypothesis most urgently needs testing.
  3. Entrepreneurs consistently overestimate how many features are required before customers can give meaningful feedback.
  4. Learning comes from putting something real in front of customers, not from debating internally.
  5. A rough early version in the hands of real users produces more useful data than a polished version in your head.

Steps

5 steps
  1. Identify the Riskiest Assumption to Test
    Determine which leap-of-faith assumption, if wrong, would invalidate the entire business. This is typically either the value hypothesis (do customers want this?) or the growth hypothesis (can we acquire customers efficiently?). Your MVP should target this specific assumption.
  2. Choose the Right MVP Type
    Select the lightest-weight form of MVP that can test your hypothesis. Options include video demonstrations, landing page smoke tests, concierge delivery to individual customers, Wizard of Oz prototypes, or single-feature products. Match the MVP type to the assumption you need to test.
  3. Strip Away Everything Non-Essential
    Remove every feature, design element, and piece of infrastructure that does not directly contribute to testing your hypothesis. If you are unsure whether something is necessary, leave it out. You can always add it in the next iteration if the data shows it matters.
  4. Launch to Early Adopters, Not the Mainstream
    Target customers who feel the problem most acutely and are willing to try imperfect solutions. Early adopters can imagine what the product could become and will provide more useful feedback than mainstream customers who expect a polished experience.
  5. Measure Customer Behavior, Not Opinions
    Track what customers actually do with your MVP rather than what they say they would do. Measure sign-up rates, activation rates, retention, and willingness to pay. These behavioral metrics reveal the truth about your hypothesis far more reliably than surveys or focus groups.

Examples

2 cases
Dropbox's Video MVP

Dropbox founder Drew Houston faced a challenge: the product required complex technical infrastructure to build, but he needed to validate demand first. Instead of building the full product, he created a three-minute video demonstrating what the product would do. The video was targeted at technology early adopters and showed the planned user experience.

OutcomeThe video drove Dropbox's beta waiting list from 5,000 to 75,000 overnight, validating massive demand before the full product was built. This allowed Houston to raise funding and build the product with confidence that customers wanted it.
Food on the Table's Concierge MVP

Food on the Table CEO Manuel Rosso started his meal planning service with a single customer. Rather than building an app, he personally went to the grocery store, found deals, and created customized meal plans for one family. He then manually repeated this process, adding one customer at a time, learning exactly what they valued before automating anything.

OutcomeBy serving customers manually, Rosso discovered which features actually mattered and built a product based on real customer behavior rather than assumptions. The company grew from one customer to thousands, automating only the processes that had been validated through personal delivery.

Common mistakes

3 traps
Building too much before launching
The most common mistake is spending months adding features before any customer sees the product. Every feature added before launch is based on untested assumptions. If the fundamental value proposition is wrong, all that additional work is wasted. Ries found at IMVU that many features they assumed were essential turned out to be irrelevant.
Confusing MVP with low-quality product
An MVP is not about cutting corners on quality. It is about being disciplined regarding which features to include. The features you do build should work well. The distinction is between necessary quality (things customers care about) and unnecessary features (things you assume customers care about but haven't verified).
Fearing negative feedback from an imperfect product
Many entrepreneurs delay launching because they fear criticism. But early adopters expect imperfection and are forgiving if they see the core value. Waiting until the product is perfect dramatically increases the risk of building something nobody wants while burning through precious time and capital.

Origin story

How this framework came to be

The Minimum Viable Product is the version of a new product that allows a team to collect the maximum amount of validated learning about customers with the least effort. It is not simply a smaller or cheaper product; it is specifically designed to test fundamental business hypotheses. The MVP may lack many features that will prove essential later, and it may seem embarrassingly simple, but its purpose is learning, not revenue.

MVPs come in many forms depending on what needs to be tested. A video

Source

Traced to primary
Source · BOOK
The Lean Startup
Eric Ries · 2011
Open source →

Related frameworks

Browse all Innovation →