A framework by Eric Ries
Eric Ries built the MVP to run an experiment. It is not a licence to ship something rough. What you learn is the progress, so the build should be whatever answers the question. Minimum can cost more care than the full version. The word most teams skip is viable.
What the letters stand for
MVP is a way to make rigorous the idea that we are doing an experiment.
Rigorous is the operative word. Ries puts founders in the same category as scientists, which is not how most people use the acronym.
The framework
Ries tells a story about a company facing three years and eighteen million dollars of engineering. He proposed a cheaper instrument first.
instead of paying three years and $18 million to you know make the thing let's go take a brochure take it to some customers
The customers laughed them out of the room. Not because the brochure was thin, but because the product solved a problem nobody in that room had.
we don't pay for efficiency we build data centers how much they cost to operate to somebody else's problem
Eighteen million dollars of engineering would have produced the same sentence three years later. That is the arithmetic behind the method, and it explains why Ries keeps redirecting teams to the goal underneath the deliverable.
our goal is learning
His own team pushed back that the goal was to close the contract. He kept answering that the contract was how they would find out whether the thing worked at all.
Practice
Start from the question you are trying to answer, then work backwards to the smallest thing that answers it.
Name what you believe about the customer and what would prove it false. Without that sentence there is no experiment, only a small build.
This is his stated shortcut for teams that cannot agree on scope. Two rounds of halving gets most lists to something testable.
A brochure counted. So can a landing page, a concierge service or a hand-run spreadsheet. The artifact only has to be able to produce a real answer.
Ries watches teams explain away a failed test by blaming the polish. Setting the bar first is what stops the second run from being a rerun.
His rule is that minimum is context-dependent and often needs more rigor than teams assume. In a regulated or high-trust market the viable half is expensive, and skipping it invalidates the test.
If the team says it shipped and cannot say what it now knows, the experiment did not run. That is the check Ries applied to his own contract negotiation.
Conditions
Ries has a blunt read on the backlash, and he does not blame a bad explanation.
all the criticisms of MVP are really just people expressing their frustration with how un certain startups are
The method asks a founder to hold two things at once. I am certain enough to make people follow me, and I do not know how this works. He thinks that discomfort is the real objection.
The first one is where the sharpest disagreement sits. Garry Tan's advice to launch the jankiest version reads as the opposite instruction. For consumer software with a forgiving audience it is.
Primary sources
A 2025 interview where he restates the definition, and the long 2023 retrospective where he works through what the movement got wrong.
Eric Ries · Made IT Podcast
The Definition, Restated in 2025
"MVP is a way to make rigorous the idea that we are doing an experiment"
Eric Ries · Lenny's Podcast
Practical Advice for Defining Minimum and Viable
"cut it in half and cut it in half again and build that"
Eric Ries · Lenny's Podcast
The Brochure That Saved $18 Million
"let's go take a brochure take it to some customers"
Eric Ries · Lenny's Podcast
What the Criticism Is Really About
"people expressing their frustration with how un certain startups are"
Where experts disagree
Eric Ries
treats the MVP as an instrument for answering a question, which puts rigor at the centre. Minimum is context-dependent and often demands more care than teams assume, because a test run below the market's threshold of viability returns a result about your polish rather than your idea.
Garry Tan
tells founders to launch the jankiest version that does the job, on the grounds that time spent perfecting anything before contact with users is time spent on assumptions. Shipping rough and early is the fastest way to find out whether anyone cares.
The condition is the market's tolerance for rough. In consumer software with a forgiving audience the jankiest build is a valid experiment, and Tan's advice wins on speed. In regulated, enterprise or high-trust markets, the viable half is what makes the result readable at all, and shipping under that bar produces a clean negative about the wrong variable. Ries is not arguing for polish; he is arguing that you cannot learn from a test the customer refuses to take seriously.
Want the full playbook?
From Uri Levine, Dharmesh Shah, Jeffrey Pfeffer, and 25 more. Drop one .md into Claude, Cursor, or ChatGPT. Your AI cites practitioners, not guesses.
Instant .md download · One-time purchase · No subscription
Related frameworks
Shipping
The Fogg Behavior Model
Bj Fogg
Motivation, ability and a prompt must converge. When a behavior fails, check the prompt first and motivation last.
Shipping
Make Time
Jake Knapp
Pick one Highlight a day, not a longer to-do list. Getting faster at the inbox only refills it, so name what the day is for and defend one block.
Shipping
Kill Criteria
Annie Duke
Name the signals that mean stop before you launch, and attach an action to each one while you still have no stake in the answer.
Shipping
Do Things That Don't Scale
Paul Graham
Startups don't take off by themselves. Recruit the first users by hand and do the unscalable work that delights them.
