The most expensive way to find out a product is wrong is to finish it. An MVP is the cheap way, but only if you treat it as a question you're asking customers, not a smaller pile of features you've decided to ship.

The quick version

  • An MVP (minimum viable product) is the smallest thing you can put in front of real users to learn whether your idea is worth pursuing, not a stripped-down launch.
  • Eric Ries defines it as the version that gets you through the build–measure–learn loop with the least effort and the most validated learning. Iterative delivery is just running that loop, again and again.
  • The whole point is the learn step. A team that ships an MVP and measures nothing has built a small product, not run an experiment.
  • The idea is widely abused. "MVP" gets used to justify shipping something embarrassing, or a feature factory with no decision attached. Name what you're actually doing: testing, or launching.

The idea in depth

The term predates the startup hype around it. Frank Robinson, co-founder of the consultancy SyncDev, coined "minimum viable product" around 2001, framing it as the right-sized product that is "big enough to cause adoption, satisfaction and sales, but not so big as to be bloated and risky", the product with maximum return on investment divided by risk, built by running product development and customer development in parallel (Robinson, via SKMurphy). Note the emphasis: viable, not minimal. A skateboard is minimal; a skateboard that nobody will ride is just minimal.

The version most people mean came later. In The Lean Startup (2011), Eric Ries reframed the MVP around learning: it's "that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort." Crucially, Ries says it's "not necessarily the smallest product imaginable", it's simply the fastest way through one turn of the build–measure–learn feedback loop. You build the smallest thing that tests a real assumption, measure how actual users respond, and learn enough to decide whether to persevere or pivot. Then you do it again. That loop, run repeatedly, is iterative delivery.

flowchart LR
  I(["Riskiest assumption
(what must be true?)"]) --> B("Build: smallest test of it")
  B --> M("Measure: real user behaviour")
  M --> L("Learn: validated or not?")
  L -->|"Validated"| P(["Persevere: next assumption"])
  L -->|"Wrong"| V(["Pivot: change the bet"])
  P --> I
  V --> I
Build–measure–learn is a loop, not a launch. The MVP is whatever gets you round it fastest. Leaders Loop

So the move is: before you scope anything, write down the single riskiest assumption your idea depends on, usually "people will want this" or "people will pay for this", and design the cheapest test that could prove it false. Often that test isn't software at all. A landing page, a concierge service you run by hand, a fake "buy" button that logs intent: each can answer the question for a fraction of the cost of the real build.

Why most MVPs aren't the problem the team thinks they are

Teams usually justify an MVP by talking about saving time. The deeper case is about waste, and there's a number people love to quote here: the Standish Group's finding that, on average, around 64% of software features are rarely or never used, with only about 20% used always or often. It's a striking figure, and exactly the kind of statistic worth handling carefully.

An MVP isn't a smaller product. It's a question you ask before you commit to the answer.

An honest limitation. That 64% number is real but narrower than its fame suggests. It was presented by Standish chairman Jim Johnson at the XP 2002 conference, and as Mike Cohn has pointed out, it came from a study of four internal applications, no commercial products. Cohn's plea is blunt: if you're using it to imply every product everywhere is 64% waste, "please stop." So treat it as a vivid illustration, not a law. The softer, still-damning version: teams routinely build features nobody asked for, and you can't tell in advance which ones. That uncertainty, not a precise percentage, is the real reason to test before you build. The risk with the MVP idea isn't that it's wrong; it's that it gives a feature factory a respectable-sounding name.

The fix is a habit: tie every MVP to a decision you'll actually make based on the result. Write it down first, "if fewer than X of these users come back in a week, we drop it." If you can't name the decision the experiment informs, you're not testing. You're just building a bit less.

Iterative, not just incremental: build the skateboard, not the wheel

The most useful correction to bad MVP practice is a drawing. In 2016 the agile coach Henrik Kniberg sketched two ways to deliver a car: one builds a wheel, then a chassis, then a body, and the customer has nothing usable until the very end. The other delivers a skateboard, then a scooter, then a bike, then a motorbike, then the car, something the customer can actually use, and react to, at every step. The point isn't that a skateboard is a great car. It's that each version is whole enough to learn from, and the feedback reshapes what comes next.

That's the difference between incremental and iterative. Incremental delivery builds the planned thing in slices; iterative delivery changes the plan as the slices teach you. Tellingly, Kniberg has since said the diagram is widely misread and that he'd rather drop "MVP" for plainer terms, earliest testable, usable, lovable, to force teams to say which one they mean. An "earliest testable" release can be rough and internal; an "earliest lovable" release is something you'd put your name to in public. Confusing the two is how a learning experiment ends up shipped to your whole customer base as if it were finished.

flowchart TD
  subgraph BAD["Incremental: nothing usable until the end"]
    W("Wheel") --> CH("Chassis") --> BO("Body") --> C1(["Car (finally)"])
  end
  subgraph GOOD["Iterative: usable + learning at every step"]
    S(["Skateboard"]) --> SC(["Scooter"]) --> BK(["Bike"]) --> MB(["Motorbike"]) --> C2(["Car"])
  end
After Henrik Kniberg's MVP sketch: deliver something whole at each step, and let the feedback redraw the destination. Leaders Loop

Try this on your next release. Ask "what's the earliest version a real user could complete one whole job with?", then ship that, and only that, with a way to watch them use it. If the answer is "they can't do anything until all of it ships," you've designed a wheel, and you won't learn a thing until it's too late to matter.

A worked example

Take an internal tools team, call the lead Priya, asked to build a self-service expense system to replace a spreadsheet everyone hates. (Illustrative figures throughout; this is a teaching example, not real data.) The full brief is large: approvals, currency conversion, policy checks, accounting export, a mobile app. The instinct is to scope a "small" version of all of it and ship in three months.

Instead, Priya names the riskiest assumption. It isn't "can we build this", they obviously can. It's "will people actually file expenses promptly if it's easy?" The spreadsheet's real failure is that claims pile up for weeks. So the MVP tests that one thing: a single web form that captures a photo and an amount and emails finance. No approvals engine, no app, no export. Finance processes the rest by hand for now, a concierge MVP.

flowchart TD
  A(["Brief: full expense system (~3 months)"]) --> Q{"Riskiest bet:
will people file promptly?"}
  Q --> M(["MVP: one photo-and-amount form,
finance handles the rest by hand"])
  M --> D{"In 2 weeks: median
filing time under 3 days?"}
  D -->|"Yes, habit forms"| P(["Persevere: automate the manual back end"])
  D -->|"No, still piles up"| V(["Pivot: the problem is reminders,
not the form"])
One sharp question, one tiny build, one pre-agreed threshold, that's an MVP doing its job. Leaders Loop

Before launch, Priya writes the decision rule: "If median filing time drops below three days within two weeks, we persevere and start automating the manual back end. If it doesn't, the problem was never the form, it's reminders and incentives, and we pivot." A hand-run form costs a few days of build and a little finance time. It either earns the three-month investment or saves it, and the team learns it now, not after the money is spent.

Frequently asked questions

Isn't an MVP just a buggy, half-finished product?

That's the most common failure mode, and it's a misread. The "viable" in MVP means it genuinely delivers value for the narrow thing it does, a skateboard that rolls, not a car missing three wheels. If users can't get one real job done, you'll learn nothing except that broken things frustrate people. Shrink the scope, not the quality of what's in scope.

What's the difference between iterative and incremental delivery?

Incremental builds the pre-decided product in slices; iterative lets each slice's feedback change what you build next. You want both, but iterative is the one that protects you from finishing the wrong thing. Incremental alone is just a slow march to a destination nobody re-checked.

Do MVPs only make sense for startups?

No. Any time you're uncertain whether something will be used, paid for, or adopted, a new internal tool, a feature in a mature product, a process change, the same logic applies: test the assumption cheaply before you commit. Established companies arguably need it more, because they can afford to build the wrong thing for longer.

How do I stop "MVP" becoming an excuse to ship junk?

Name what you're doing. Borrow Kniberg's vocabulary: is this release testable (rough, limited audience, for learning), or lovable (public, polished, your reputation on it)? And attach a decision to every test. An MVP with no metric and no threshold isn't a minimum viable product, it's just a small product with good PR.

How long should an MVP take?

Short enough that you'd cheerfully throw it away. If it takes so long that sunk cost makes you defend the result no matter what the data says, it's too big to be an experiment. The unit isn't weeks or months in the abstract, it's "shorter than the time it would take to fall in love with the idea."

Related in the Toolkit

An MVP only earns its keep when it's pointed at the right bet. Discovery, validation & de-risking is where you find the riskiest assumption worth testing, and roadmapping & prioritisation is how you decide which loop to run first when everything feels urgent.

Where to go next