1Fast Overview
Everything you need in 30 seconds.
Minimum Viable Product (MVP) is the simplest version of a product, service, or idea that is still complete enough to test your riskiest assumption with real people, in the real world.
The point is not to ship something small. The point is to learn something true, as cheaply and quickly as possible, before you commit real time and money to building more.
An MVP can be a landing page, a video, a spreadsheet, or a person doing a job by hand. It only has to be viable enough to produce an honest answer to the question: does anyone actually want this?
- Field: Product development, entrepreneurship, decision science
- Coined by: Frank Robinson, 2001; popularized by Steve Blank and Eric Ries
- Core question: "What is the smallest thing we can build to test our biggest assumption?"
- Best used for: New products, new features, new internal processes, unproven ideas
- Related to: Jobs to Be Done, Theory of Constraints, Premortem Analysis
2Mental Model Compass
How this model relates to others in the series. Click or tab to any point.
Select a model
Click or tab to any dot on the compass to read how it relates to the Minimum Viable Product.
3Build Your Understanding
Four short stages. Work through them in order, or jump around.
Stage 1: The core idea
Most failed products aren't badly built. They're well built versions of something nobody wanted. An MVP flips the order: test demand first, build quality second.
Stage 2: "Minimum" and "viable" are both doing work
Minimum means stripped down to only what's needed to test the assumption. Viable means it still has to work well enough that the test is honest. A broken, confusing MVP teaches you nothing, because people will reject it for being broken, not because they didn't want the idea.
Stage 3: One assumption at a time
An MVP tests your single riskiest, most uncertain assumption, not everything at once. "Will people pay for this?" is a different test than "Can we build this at scale?" Mixing them produces a confusing result that answers neither question clearly.
Stage 4: Build, measure, learn, repeat
An MVP isn't a one-time event. It's the first lap of a loop: build a small test, measure what actually happened, learn from the gap between what you expected and what you observed, then decide what to test next.
4Examples Across Contexts
The same model, four different settings.
Dropbox's earliest public test wasn't working file-sync software. It was a three-minute screen-recorded video showing the product as if it already existed, posted to a tech community in 2008. The team wanted to know whether people cared enough to want early access, without first building the full syncing engine. The beta waitlist reportedly jumped from about 5,000 to around 75,000 names within a day, and the video attracted thousands of upvotes almost overnight. That response was the evidence they needed to justify building the real thing.
Before Zappos became a shoe retailer with its own warehouses, its founder tested the core assumption, that people would buy shoes online, by photographing inventory at a local shoe store and listing those photos on a simple website. When an order came in, he personally bought the pair at retail price and shipped it himself, often at a loss once shipping was factored in. The business lost money on every sale, but it answered the one question that mattered before any inventory was purchased: will strangers actually buy shoes without trying them on first?
A mid-sized company wants to know whether an internal AI-assisted ticket-routing tool would actually save its support team time. Instead of commissioning a custom build, a manager spends two weeks manually applying the proposed routing rules to incoming tickets and timing the before-and-after. The "product" is a person following a checklist, not software. If the manual version saves meaningful time, the company has evidence to justify the engineering investment. If it doesn't, no code was wasted finding that out.
Someone considering leaving their job to start a weekend cooking class business doesn't need a studio lease or a brand before finding out if anyone will pay. A believable first test is posting one class on a community board, charging a small fee, and running it in their own kitchen for six strangers. If nobody signs up, the idea is cheaply disproven. If people show up and pay, that's real evidence worth acting on, for the cost of one afternoon rather than a year's rent.
5Worked Application
Walking through a realistic case, step by step.
Scenario: A product manager at a mid-size company believes customers would value a self-serve way to cancel their own subscriptions, instead of calling support. Leadership is skeptical it's worth the engineering quarter it would take to build properly.
-
Name the riskiest assumption
Not "can engineering build this," but "will enough customers actually use self-serve cancellation, and will it meaningfully reduce support calls." That's the assumption worth testing first.
-
Design the smallest honest test
Add a single "Cancel my subscription" link in the account settings page. Behind it: a short form that emails the request straight to a support agent, who processes it manually within the hour. No new backend logic is built.
-
Set a measurable threshold in advance
The team agrees beforehand: if at least 15% of cancellation requests over one month come through the new link instead of a phone call, that's strong enough evidence to justify the real engineering build.
-
Ship it to a limited audience
The link is shown to 20% of customers for four weeks, not the full base, limiting both engineering risk and support load while the hypothesis is tested.
-
Measure what actually happened, not what felt true
38% of cancellations in the test group came through the link. Support call volume for cancellations dropped by nearly a third among that group. The assumption held, and held more strongly than expected.
-
Decide, and feed the result forward
Leadership approves the full build, now backed by a real number instead of an opinion. The manual email step gets automated, and the team moves on to testing the next assumption: whether adding a "pause" option would reduce cancellations in the first place.
6Common Mistakes
Confusing "minimum" with "low quality"
An MVP that's broken, confusing, or slow doesn't test your idea. It tests whether people tolerate bugs, and the answer is usually no. The product must still work.
Testing too many assumptions at once
Bundling price, feature set, and audience into one test means a failure doesn't tell you which part was wrong, so you can't act on the result.
Treating the MVP as the finished launch
Some teams ship the minimal version, call the project done, and never return to build on what they learned. The MVP is a question, not an answer by itself.
Not deciding the success threshold in advance
Without a number agreed on beforehand, ambiguous results get interpreted however the loudest person in the room prefers, which defeats the purpose of testing at all.
7When Not to Use It
Safety-critical or regulated systems
A stripped-down version of a medical device, aircraft component, or financial compliance system can create real harm or legal exposure. Some domains require the "complete" version before any real-world test.
Trust-dependent, one-shot sales
Enterprise buyers signing a multi-year contract, or a couple booking their wedding photography, are often evaluating whether you look complete and credible. A visibly minimal version can cost you the sale before you learn anything.
High fixed cost of iteration
Physical products with expensive tooling, like injection-molded hardware, can't be cheaply revised the way software can. The "minimum" version may still require most of the investment, undercutting the whole point of testing cheaply.
When the answer is already clear
If strong evidence already exists, from direct customer commitments, contracts, or a near-identical prior test, running another MVP just delays a decision you already have grounds to make.
8Related Models
9Try It Yourself
Answer three short questions. Get a custom prompt you can take anywhere.
10Save as Skill
Turn this model into something your own AI assistant can apply on demand.