What an MVP is
A minimum viable product is the smallest thing you can build that produces evidence about one risky assumption. The term was popularised by Eric Ries in The Lean Startup (2011), building on earlier use by Frank Robinson and Steve Blank.
The load-bearing word is viable, and it does not mean “good enough to sell”. It means the thing is capable of returning a verdict. An MVP is judged by what it teaches, not by what it does, which is why several of the standard forms are not software at all.
That definition has largely been lost. In common use “MVP” now means a small first version of the real product, which is a different object with a different purpose, and the confusion is expensive: a small first version has no named assumption, no threshold that would count as failure, and therefore no way to be wrong.
What an MVP is not
It is not version one. A first release is something you intend to keep and grow; an MVP is something you are prepared to throw away the moment it has answered its question.
It is not a product with the features removed. Removing features from a product you have already decided to build tests nothing, because the decision was made before the experiment.
It is not an excuse for poor quality. The scope is minimal; the execution of that scope is not. A broken experiment returns a verdict on your engineering rather than on your assumption.
We can put a number on how far the word has drifted, and it is our own number. ShipFit proposes an MVP scope, sorts it into Lean, Balanced and Full, and recommends one. What a tool built to cut scope actually recommends is a seven-month build.
Across 208 AI-generated MVP plans, the average recommended build was 31 weeks and 16 features. The lean option, which the engine never once recommended, averaged 14 weeks.
- Features proposed per idea
- 19.8 mean
- Features in the recommended build
- 16.0 mean
- Recommended build time
- median 30.5 31.4 weeks
- The lean alternative
- recommended 0 times out of 208 14.0 weeks
Sample: n = 208 ideas that reached MVP scoping
What it does not say: A tool that exists to cut scope recommended a seven-month first release, and recommended the same package every single time. Both are worth knowing.
This one is unflattering to us, and we are publishing it anyway. A tool that only reports the numbers making it look good is not reporting numbers.
Nothing is testable until the end, so you learn nothing until you have spent everything.
Every stage moves someone from A to B, so every stage returns evidence.
Both rows end at the same place and only one of them teaches you anything on the way. A minimum viable product is the first green marker, not the last grey one, which is why “we are building the MVP” and “we are building a smaller version of the product” describe different activities.
The common forms
The question that picks the form is not “how much can we build” but “what are we trying to find out”. Three of these five are barely software.
| Form | Tests | Build | How | What it cannot tell you |
|---|---|---|---|---|
| Landing page | Will anyone express intent? | Hours | Describe the product, ask for an email or a card, measure the rate. | Measures interest in a description, not willingness to use a product. |
| Concierge | Does solving this manually create real value? | Days | Deliver the outcome by hand, openly, for a handful of customers. | Does not test whether the automated version is wanted at the same price. |
| Wizard of Oz | Will people use the interface, if the outcome is real? | Days to weeks | A real front end with a person doing the work invisibly behind it. | Cannot scale, and the illusion sets an expectation you must later meet. |
| Single-feature | Is one specific capability worth paying for? | Weeks | Build the one thing properly and nothing else around it. | Closest to a real product, and therefore easiest to mistake for one. |
| Piecemeal | Does the workflow hold together at all? | Days | Stitch existing tools together to deliver the outcome end to end. | Proves the workflow, not that anyone will switch to your version of it. |
How to scope one
- Write the assumption down first. One sentence, in the form “we believe [buyer] will [behaviour] because [reason]”. If you cannot write it, you are not running an experiment.
- Write the threshold. What result would make you stop? Deciding this after seeing the data is the single most common way the method gets hollowed out, and it is invisible from outside.
- Pick the cheapest form that can produce that result. Work up the table above, not down. Most teams start at “single-feature” out of habit.
- Cut everything that does not serve the test. Not everything that is nice to have. Everything that does not change the answer.
- Decide in advance who reads the result and when. An experiment nobody has agreed to act on is a release with an experiment’s name attached.
- The word now means "small first version" to most people
When a founder and an engineer say MVP they frequently mean different objects, one an experiment and one a release. Neither notices, because the word is the same and the scope discussion sounds identical.
Instead: Say which you mean. "Experiment" and "first release" are both perfectly good words and they do not get confused with each other.
- The assumption is written after the build
A team ships something, sees the numbers, and constructs the hypothesis that fits. This produces a narrative rather than evidence, and it always concludes that the team was broadly right.
Instead: Write the assumption and the failing threshold before any code exists, and put them somewhere other people can see.
- Minimum is applied to quality rather than to scope
A deliberately rough experiment can still be broken in ways that produce a verdict on your engineering instead of on your assumption. Users who cannot complete the task tell you nothing about whether they wanted to.
Instead: Narrow the scope hard and then execute that scope properly.
- It cannot test things that take a long time to be true
Retention over a year, network effects, trust in a regulated market. None of these compress into a short experiment, and running one anyway measures a proxy while reporting it as the thing.
Instead: Name the proxy as a proxy, and validate it against the real outcome before you rely on it.
How ShipFit scopes an MVP
Stage 5 (What’s V1?) runs every candidate feature through the cannot-ship-without test and produces three packages (Lean, Balanced, Full) with the Must list explicit in each. Each package is tied to the hypothesis from Stage 1, so what ships is scoped against what it is meant to prove rather than against what would be nice to have.
An MVP in practice: Zappos
The clearest example of the definition on this page, from a founder who lost money on every early sale on purpose.
Zappos · 1999
Sold shoes it did not own, photographed in shops it did not run.
Nick Swinmurn wanted to know whether people would buy shoes online without trying them on, which in 1999 was a genuinely open question. Building inventory, warehousing and returns to find out would have cost a great deal and taken a year.
He went to local shoe shops, asked to photograph the stock, put the photos on a website, and when somebody ordered a pair he went back and bought them at retail. He lost money on every sale, which was the point: he was buying an answer, not margin.
Zappos sold to Amazon in 2009 for roughly $1.2bn.
- Inventory owned at test time
- none
- Margin per early sale
- negative, deliberately
- Acquisition, 2009
- ~$1.2bn
What it shows: The manual, unscalable, loss-making version of the service is often the fastest instrument available. It answers the demand question without committing to the operating model.
Further reading
- Lean Startup validation. The loop an MVP exists inside.
- MoSCoW. How to cut a candidate list down to a scope an experiment can test.
- ICE scoring. How to sequence what survived the cut.
- The Mom Test. Often cheaper than an MVP, when the question is answerable by asking.
- TAM SAM SOM. The market the MVP is being aimed at.
Frequently asked questions
What is an MVP?
What is the difference between an MVP and a first version?
What are the common types of MVP?
Does an MVP mean low quality?
What is the difference between iterative and incremental delivery?
Related
Keep exploring
The 9-step playbook from market verdict to ship-ready spec.
The JTBD framework in plain terms: the four forces of progress, the switch timeline, and how the Christensen and Ulwick schools actually differ.
The 7 Powers, each with its benefit and its named barrier, plus the Power Progression that decides which of them a startup can realistically build and when.
Most product launches fail not because the product was bad, but because the launch was a list of channels nobody mapped to a buyer. Here is the template that fixes that.
Default-prompted AI is a slop machine: agreeable, plausible-sounding, useless for validating an idea. Here's how to use AI for the parts where it actually adds signal, and where to keep it out of the way.
Does each customer make you money? Or cost you money?
Use Rahul Vohra's Superhuman PMF Engine. (1) Survey active users with the Sean Ellis question 'how would you feel if you could no longer use this?'. (2) Segment respondents by 'very disappointed' / 'somewhat disappointed' / 'not disappointed'. (3) Profile your fans (the very disappointed) to find your real ICP. (4) Build a roadmap that's half doubling-down on what fans love and half closing the on-the-fence blockers. (5) Re-run quarterly. The score should rise.
Validation for non-technical founders using AI builders and no-code. The bottleneck isn't building anymore, it's deciding what to build. ShipFit decides.
ValidatorAI's Val chatbot scores your idea 0-100 with a chat and a 14-step launch roadmap. Used by 300,000+ founders. ShipFit forces 9 sequential decisions with live data and a 24% Kill rate. A chat is not a decision sequence. A score is not a verdict.
Ready to make your next product a success?
9 decisions between your idea and a product worth building.