A minimum viable product is the version of a product that lets a team learn the most about its customers for the least effort. That is close to Eric Ries's original wording, and almost every part of how the term gets used in practice drifts away from it.

The drift matters commercially. When founders say "MVP" and mean "version one, but cheaper," they end up spending four months and a large part of their runway building a small, polished, complete product that nobody has yet shown any sign of wanting. The build succeeds. The company does not.

So it is worth being precise about what the term is actually for.

The definition, and why the name is bad

Ries defines it as "that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort." He has been blunt about the misreading it invites: "MVP, despite the name, is not about creating minimal products."

Both words in the middle of the phrase mislead.

Minimum sounds like a quality instruction. It is not. It is a budget instruction, and the budget is effort, not features. An MVP can be enormously laborious — founders manually fulfilling orders by hand — and still be minimal in the sense that matters, because none of that labour was spent building something that might be thrown away.

Product sounds like a thing you ship to a market. Often it is not. A recorded demo, a spreadsheet, a concierge service run over email, a pre-order page — all of these have functioned as MVPs. What makes them MVPs is not their form. It is that each one was built to answer a question.

Marty Cagan adds the constraint that stops this collapsing into permission to ship anything at all. His minimum viable product is the smallest product where "people choose to use it or buy it; people can figure out how to use it; and we can deliver it when we need it." Valuable, usable, feasible. Drop any one of those and the result no longer tests what you think it tests. A product nobody can figure out how to use produces data about your onboarding, not about your idea.

The question comes before the build

Here is the practical test we apply before any MVP scope conversation at the studio. Finish this sentence:

If we are wrong about ______, nothing else we build matters.

Whatever fills that blank is what the MVP exists to test. Everything not in service of that sentence is a candidate for deletion, no matter how reasonable it sounds in a planning meeting.

The sentence is harder to complete than it looks, because most founding teams have several assumptions stacked on top of each other:

  • A problem assumption. People experience this pain often enough and sharply enough to act.
  • A solution assumption. This particular approach resolves the pain better than what they do today.
  • A behaviour assumption. They will change an existing habit to adopt it.
  • A commercial assumption. They will pay, or someone will pay on their behalf, at a price that works.
  • A distribution assumption. You can reach them repeatably and affordably.

These are not equally risky, and the riskiest one is rarely the technical one. Steve Blank's framing still holds: "There are no facts inside your building, so get outside." An MVP is how you go and get the fact.

Rank the five for your own business. The MVP tests the top one. If the top one is a distribution assumption, the correct MVP might not involve building software at all.

Four things an MVP is not

1. Not a cheap version of the product you already decided to build

This is the most expensive misreading, because it feels responsible. The team writes the full specification, then cuts it by two thirds, then builds the remaining third well.

The problem is that the cut was made on the wrong axis. Cutting a predetermined plan down to its cheapest third still assumes the plan was right. You end up with a smaller answer to a question nobody asked. Tom Eisenmann's research at Harvard Business School names this pattern a false start: teams that "overlook a crucial step in the lean start-up process: researching customer needs before testing products," and rush "fully functional offerings that don't fit any market needs."

The output looks like diligence. It is actually a bet placed before the odds were checked.

2. Not a prototype

A prototype answers a design question — is this the right flow, does this interaction read clearly — with simulated behaviour and no real consequences. An MVP answers a demand question, and to do that it needs real consequences: real money, real data, real commitment, real disappointment when it fails.

The distinction is not fidelity. A Figma file shown to a buyer who then signs a letter of intent has produced real evidence. A fully coded application shown to friendly advisors has not.

3. Not a feature list

Scope written as a list of features quietly reintroduces the original problem, because feature lists have no natural stopping point and every item on them sounds defensible in isolation. Scope written as a single completed user journey does have a stopping point: the journey either completes or it does not.

We have written separately about how to cut MVP scope without cutting the value — the short version is that one journey finished end to end beats five journeys implied.

4. Not a permanent excuse for poor quality

"It's just the MVP" is a reasonable thing to say about missing features. It is not a reasonable thing to say about a broken signup, an unreadable interface, or a page that takes eight seconds to load, because those failures corrupt your data. If users bounce, you cannot tell whether they rejected your idea or your execution, and you have spent the money without buying the answer.

Cagan's usable criterion is doing real work here. An unusable MVP is not a lean experiment. It is a ruined one.

How to tell whether yours qualifies

Run your current plan through these five questions. Honest answers only — the exercise is worthless as advocacy.

  1. What specific belief would this disprove? If you cannot name a result that would make you stop or change direction, you are building, not testing.
  2. What is the smallest version that would still produce that result? Not the smallest you are comfortable showing. The smallest that still generates trustworthy evidence.
  3. Who exactly sees it, and how do you reach them? An MVP with no audience produces no learning, only a deployment.
  4. What does the user actually give up? Money, time, data, a switch away from an existing tool. Evidence gets stronger as the cost to the user rises. Free sign-ups are the weakest signal in the set.
  5. When do you decide? Set the date and the threshold before you launch, not after you see the numbers.

If you can answer all five in a paragraph, you have an MVP. If the answers keep expanding into a roadmap, you have a small product and an optimistic label.

Where this leaves the build

None of this is an argument against building things well. It is an argument about sequence. The craft is not wasted — it is deferred until you know which thing deserves it, which is also when the craft is worth the most.

In practice that means the early weeks look less like engineering and more like structured interrogation: framing the riskiest assumption, choosing the cheapest honest instrument to test it, and agreeing in advance what result would change your mind. The build follows the answer.

That sequencing is most of what we do in product and UI/UX design with early-stage teams — deciding what deserves to exist before anyone commits to making it properly.

If you are holding a specification you are not yet sure about, the useful next step is not to cut it in half. It is to write down the one sentence that could invalidate all of it, and then design the smallest honest way to find out.

Common questions

What does MVP stand for?

Minimum viable product. The phrase was popularised by Eric Ries in the lean startup movement, building on earlier work by Frank Robinson and Steve Blank. Both words in the middle are widely misread: "minimum" refers to effort spent rather than quality delivered, and "product" can mean a video, a spreadsheet, or a manual service.

How long should an MVP take to build?

Six to eight weeks is realistic for a focused build with a settled scope and a small experienced team. Ten to twelve weeks is normal where there are real integrations or regulated data. If a plan runs beyond roughly three months, the usual cause is scope rather than engineering speed.

Does an MVP have to be software?

No, and often it should not be. Concierge MVPs delivered by hand, pre-order pages, recorded demos and spreadsheets have all served as legitimate MVPs. What makes something an MVP is that it was built to answer a specific question, not that it was built in code.

What is the difference between an MVP and a beta?

An MVP tests whether a product should exist, usually with a narrow audience and a specific hypothesis. A beta tests whether a product that has already been committed to works correctly at scale. They sit at opposite ends of the same process and answer different questions.

Can an MVP be too small?

Yes. If it is so limited that users cannot complete a meaningful journey, or so rough that they cannot understand it, the result is uninterpretable — you cannot tell whether they rejected the idea or the execution. That is the one outcome that spends the budget and buys no information.

Sources and further reading