Minimum Viable Product

The smallest thing you can build that produces a clear answer to one question about your customers.

The term is everywhere, and almost everyone reads it wrong. “Minimum viable product” sounds like a product: a small, cheap, stripped-down first version you ship to start collecting revenue. Read that way, the MVP becomes a license to launch something thin and call the thinness a strategy. The original meaning points somewhere else entirely. An MVP isn’t a product you sell, it’s an experiment you run. The minimum is set by what you need to learn, not by what you can afford to build. Getting this distinction right is the difference between spending six months building toward an answer and spending six months building away from the question.

What It Is

A minimum viable product is the smallest build that lets a team run one validated-learning cycle about its customers. Eric Ries, who popularized the term in The Lean Startup (2011), defined it as the version of a new product that allows the team to collect the maximum amount of validated learning about customers with the least effort. The load-bearing word is learning, not product. Frank Robinson, who coined the phrase at SyncDev in 2001, framed it as the point where the product on offer and the customer most willing to pay first meet: the smallest thing that pulls a real buying signal.

Both definitions share a property the casual reading drops: an MVP is built to answer a question, and the question comes first. Before anything is built, the team names the riskiest assumption holding up the business: that a specific customer has a specific problem, that they’ll change their behavior to adopt a solution, that they’ll pay. The MVP is then the cheapest construction that forces that assumption to reveal itself as true or false. A feature that doesn’t bear on the question doesn’t belong in the MVP, however easy it is to add.

This is why “minimum” and “viable” pull against each other on purpose. Minimum pushes toward the smallest build. Viable insists the build still produces a trustworthy signal: it has to be real enough that a customer’s response means something. An MVP that is too minimal tests nothing; one that is too complete tests slowly and expensively. The art is finding the smallest version that still draws an honest reaction.

Why It Matters

The MVP is where a team’s beliefs first collide with reality, and the cost of getting it wrong compounds. A team that treats the MVP as a small product optimizes for shipping: it builds what it can, launches, and waits to see what happens. A team that treats it as an instrument optimizes for evidence: it decides in advance what result would change its mind, then builds only enough to produce that result. The first team learns slowly and at random; the second learns fast and on purpose.

The three audiences read the MVP from different seats. A founder reads it as the fastest path to knowing whether to keep going, and the discipline it imposes (name the assumption, define the signal, build the minimum) is what keeps a team from confusing motion with progress. An investor reads an MVP as evidence of how a team thinks: a crisp experiment with a clear result signals founders who test rather than assume, which is exactly the habit that survives contact with a hard market. A candidate weighing an offer reads the MVP history as a tell about the company’s culture, a sign of whether decisions are made on data or on the founder’s conviction.

The instrument also has a known limit, and naming it is part of using it well. An MVP run with early adopters measures early-adopter behavior, which is not the same as mainstream demand. The people willing to try a rough first version are unusual: higher pain threshold, more patience, different needs than the customers who come later. Reading their enthusiasm as proof of broad demand is how teams walk into the Chasm. The MVP answers the question it was built to answer; it does not answer questions about a market it never reached.

How to Recognize a Real One

A genuine MVP, as opposed to a thin product wearing the name, has three marks. It’s built around a stated hypothesis: the team can say what they were trying to learn before they built it. It defines the signal in advance: a number, a behavior, a conversion that will count as the assumption confirmed or denied. And it’s sized to the question, not to a launch: often far smaller than a shippable product, sometimes not a product at all.

The forms vary widely because the question varies. A concierge MVP delivers the service by hand before any software exists, to learn whether anyone wants it done. A Wizard-of-Oz MVP presents an automated-looking front end with humans doing the work behind it. A landing-page MVP tests demand with a sign-up button and no product behind it yet. Each is minimal in a different dimension, and each is chosen by asking which construction most cheaply produces the needed signal.

How It Plays Out

Dropbox is the canonical case of an MVP that was not a product at all. The riskiest assumption was demand: would ordinary people want seamless file sync badly enough to switch? Building the working sync engine was expensive and slow, so before committing to it Drew Houston made a short screencast in 2008 demonstrating the product as if it already worked, narrated to an audience of technical early adopters. The beta waitlist jumped from 5,000 to 75,000 people overnight. No product had shipped; the video was the MVP, and the signal it drew justified building the real thing.

Zappos ran the same logic in the opposite medium. Before building inventory, warehouses, or fulfillment, founder Nick Swinmurn photographed shoes in local stores, posted them online, and when an order came in, bought the shoes at retail and shipped them himself. The construction was almost nothing, but the question it answered was the one that mattered: will people buy shoes online without trying them on? Real transactions, not opinions, settled it. Only after the answer came back yes did the company that became a billion-dollar acquisition get built behind it.

Consequences

Treating the MVP as a learning instrument changes what a team builds, in what order, and why. It pulls the riskiest question to the front, where it’s cheapest to answer, and it forces the team to commit to a result before they see it. That commitment is what makes the result trustworthy rather than a story told after the fact.

Benefits. A team that runs MVPs as experiments spends its scarcest resource, the time before the money runs out, on the questions that actually determine survival. It builds less, learns more, and reaches the pivot-or-persevere decision with evidence instead of opinion. By 2025, AI tooling has compressed the build cost of many MVPs from months to days. That shifts the binding constraint from can we build it to do we know what we are trying to learn, which makes naming the hypothesis more valuable, not less: cheap building makes aimless building cheap too.

Liabilities. The hardest failure is the false read: an MVP that draws a strong signal from a segment too narrow or too unusual to build a company on. Early-adopter enthusiasm and broad demand feel identical at the MVP stage, and the gap between them is where the False Positive Trap lives. An MVP also tests only what it was designed to test; a clean result on the demand question says nothing about whether the economics work at scale. And “minimum” invites a quality floor low enough to poison the result. If the build is so rough that customers reject the execution rather than the idea, the experiment has measured the wrong thing.

Related Articles

Sources

• Eric Ries, The Lean Startup (2011) — popularized the MVP as the instrument of validated learning and defined it as maximum learning for least effort.
• Frank Robinson, SyncDev — coined “minimum viable product” in 2001, framing it as the convergence of the smallest product and the most willing early customer.
• Steve Blank, The Four Steps to the Epiphany (2005) — the customer-development backbone that grounds the MVP in testing hypotheses against real customers before building at scale.
• Drew Houston / Dropbox — the 2008 explainer-video MVP that drew a beta waitlist of 75,000 before the product was built, widely documented in Houston’s own public retellings.