MVP (Minimum Viable Product)
The smallest version of a product that can be shipped to real users to test a critical hypothesis — not a polished early version of the final product, but a learning instrument.
MVP comes from Eric Ries's The Lean Startup (2011), building on earlier Steve Blank work. The phrase is one of the most-misused in startup vocabulary.
What MVP actually means
Ries's original definition: the smallest version of a product that lets you test a critical hypothesis about your business model. The MVP is a learning instrument, not a partial product.
The hypothesis being tested is usually one of:
- "Do customers want this enough to pay for it?"
- "Will customers use this in the way we think they will?"
- "Can we deliver this profitably?"
If the MVP doesn't test a specific hypothesis, it's not an MVP — it's just a poorly-finished product.
Famous MVPs
- Dropbox (2007): a 3-minute video showing how Dropbox would work, before any code was written. Hypothesis tested: would the use case attract demand? 75,000+ waitlist signups in days = yes.
- Zappos (1999): founder photographed shoes at local stores, listed them for sale online, bought them at retail and shipped to customers when ordered. Hypothesis tested: would people buy shoes online? Yes, sustained → built real inventory system later.
- Airbnb (2007): founders rented air mattresses in their own apartment during a design conference when hotels were sold out. Hypothesis tested: would strangers pay to stay in other people's homes? Yes, but only for specific situations → narrowed positioning.
What these share: each was much smaller than the eventual product but was sufficient to answer the specific question.
What MVP isn't
- A v1 of the full product, but with fewer features. (That's a "v1", not an MVP.)
- A beta. (A beta is for surfacing bugs in a near-complete product.)
- The minimum technically buildable thing. (Technical minimum has nothing to do with what's needed to test the hypothesis.)
The misuse is everywhere: teams ship a stripped-down version of their planned product, call it MVP, learn nothing specific, and add features in subsequent versions because that was the plan all along.
A better question to ask before building
"What's the most expensive part of being wrong about this, and what's the smallest thing we could ship to find out?"
That question produces real MVPs. "What can we ship in 2 sprints?" produces v1s mis-labeled as MVPs.
Related
- PMF — what MVPs are usually testing for
- Lean Canvas — the strategy canvas that pairs with MVP thinking
- Lean Canvas vs Business Model Canvas