MVP (Minimum Viable Product): What It Actually Means

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.

From ShipFit production data 637 ideas · October 2025 to August 2026

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.

Incremental

Nothing is testable until the end, so you learn nothing until you have spent everything.

Iterative

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.

Two ways of getting to the same product. Only the second returns evidence on the way, because every stage does the whole job badly rather than doing a fraction of it perfectly.

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.

Five standard forms, ordered by build cost. Each isolates a different assumption, and each has something it structurally cannot tell you, which is the column most write-ups leave out.

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.

Four ways the term causes damage. The first is the ordinary case and it is not a matter of discipline: the word itself now points at the wrong object for most people who use it.

Ries’s definition, word by word

Ries’s own wording is worth reading closely:

“The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”

What is in that sentence: validated learning and least effort. What is not in it: a list of features, a number of weeks or an aesthetic standard.

What an MVP actually is	What people often mean
A test for one specific hypothesis	A stripped-down launch
Designed to be killed if the hypothesis fails	Designed to be the foundation
Often not a working product at all	Always a working product
Measured by what you learned	Measured by how much you shipped

If your MVP cannot fail, it is not an MVP. It is a small launch.

A worked example

Write the hypothesis before you scope anything:

“[Buyer segment] will [take a specific action] in response to [the offer] because [underlying reason].”

For example: “Solo founders will pay $50 to receive a custom buyer persona report within 24 hours, because they are stuck on deciding who pays and have no other affordable option.”

Then ask what the smallest test is that could falsify it. Here it is a landing page and a Stripe checkout, not a SaaS dashboard. It could even be a social post offering the service, or an email to ten people in your network. The dashboard comes after the hypothesis survives.

One more form belongs alongside the five above: the smoke test, or fake door test. An ad campaign or pre-order page for a product you have not built tests whether demand exists at the price you intend, before any of the product does.

If the smallest test you can think of takes six months and $50K, you did not pick the smallest test. You picked a launch.

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.

Case study It worked

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.

Source: Hsieh, Delivering Happiness, 2010; Amazon acquisition filing, 2009.

Frequently asked questions

What is an MVP?

A minimum viable product is the smallest thing you can build that produces evidence about one risky assumption. The load-bearing word is viable, and it does not mean good enough to sell; it means capable of returning a verdict. An MVP is judged by what it teaches rather than by what it does, which is why several standard forms, such as a landing page or a concierge service, are barely software at all.

What is the difference between an MVP and a first version?

Purpose and disposability. 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. In practice the distinguishing test is whether an assumption and a failing threshold were written down before any code existed. If they were not, you have a small first version, which is a perfectly reasonable thing to build but cannot tell you that you were wrong.

What are the common types of MVP?

Landing page, which tests whether anyone will express intent and takes hours. Concierge, where you deliver the outcome by hand for a few customers, testing whether solving the problem creates real value. Wizard of Oz, a real interface with a person doing the work invisibly behind it. Piecemeal, stitching existing tools together to deliver the outcome end to end. And single-feature, building one capability properly and nothing around it. Pick by what you need to learn, not by what you can build.

Does an MVP mean low quality?

No. Minimum applies to scope, not to execution. A deliberately rough experiment can still break in ways that produce a verdict on your engineering instead of on your assumption, and a user who cannot complete the task tells you nothing about whether they wanted to. Narrow the scope hard, then execute that narrow scope properly.

What is the difference between iterative and incremental delivery?

Incremental delivery ships a fraction of the finished product each round, so nothing is usable until the end and no stage returns evidence. Iterative delivery ships something that does the whole job badly, then better, so every stage is testable by a real user. The skateboard-to-car illustration makes the point: both routes end at the same product, and only one teaches you anything on the way. An MVP is the first usable stage, not the last unusable one.

How long should it take to build an MVP?

Days to a few weeks. If your MVP takes four months or more to build, you have scoped a first release, not an MVP. Real MVPs are embarrassingly small: Dropbox's was a short demo video, and Buffer's was a landing page with a pricing table and a sign-up button. The point is not to be minimal for its own sake; it is to test the hypothesis as cheaply as possible.

What's the difference between an MVP and a prototype?

A prototype tests whether something is technically buildable; an MVP tests whether the market wants it. A prototype's audience is your team or investors; an MVP's audience is real buyers. They can overlap, because a working prototype shown to buyers is an MVP if the goal is to test demand, but they answer different questions.

Should I ship the MVP publicly?

It depends on what you are testing. To test demand, ship publicly to your buyer segment and collect behavioural evidence. To test a workflow, keep it private with 5 to 10 buyers in concierge mode. A public launch is loud and noisy; a private concierge is quieter but produces deeper signal. Pick based on the hypothesis.

If my MVP succeeds, do I keep building on it?

Often you throw most of it away. The MVP's job was learning, not load-bearing architecture. A landing page that converts visitors to card-on-file tells you the demand is real, and you still need to build the product. A Wizard of Oz MVP that proves users will pay for the human-served version tells you to automate, and you still need to build the automation. The MVP is the cheap test, not the product.

Related on ShipFit

Keep exploring

Master guide

Validate your business idea

The 9-step playbook from market verdict to ship-ready spec.

Framework

Superhuman PMF Engine

Rahul Vohra's method for measuring product-market fit and then improving it: the 40% benchmark, the survey mechanics, and the roadmap it hands back to you.

Framework

The Mom Test

The Mom Test is Rob Fitzpatrick's framework for customer interviews that generate real signal. Not praise. Three rules, applied step-by-step, with examples.

Guide

Launch Plan

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.

Guide

Validation with AI

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.

Calculator

CAC / LTV ratio calculator

Does each customer make you money? Or cost you money?

Q&A

How long does startup validation take?

Two to four weeks of focused work for a single idea. Stage 1 (market verdict) takes a day. Stages 2-3 (buyer + pain) take a week of interviews. Stage 4 (positioning) takes two days. Stage 5 (V1 scope) takes a day. Stages 6-7 (pricing + behavioral evidence) take 1-2 weeks because you need 20+ buyers and a Fake Door Test running. ShipFit compresses the decision time to 30-60 minutes; the gating work is the human conversations between stages.

For founders

non-technical founders

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.

Comparison