Key takeaways
  • An MVP is the smallest thing that proves the hypothesis. Scoped to learn, not to ship.
  • Most "MVPs" prove nothing because they're scoped to ship.
  • Think Kniberg's skateboard: ship something usable at each step; know the MVP/MMP/MLP family.

The phrase MVP arrives in every kickoff meeting and is taken to mean the same thing in none of them. To one stakeholder it means v1, a stripped-back but complete-feeling product. To another it means prototype, something to show investors. To engineering it often means v0 with all the technical debt. To Eric Ries, who named the concept in The Lean Startup, it means none of those. It means the smallest experiment that produces validated learning about a hypothesis. Three letters, six words, easy to remember, and almost universally ignored in practice.

The cost of the confusion is real. Teams ship something they've called an MVP, get reasonable usage, declare success, and then six months later realise they've built a product that nobody pays for. They proved adoption, not viability. They proved can people use this — not will people choose this when they have alternatives. The MVP delivered exactly what it was scoped to deliver, which was the wrong question.

Ries's original definition.

The framing in The Lean Startup (2011) is precise: an MVP is the version of the product that allows the team to collect the maximum amount of validated learning about customers with the least effort. It is an experiment, not a product. It has a hypothesis stated in advance, success criteria stated in advance, and a decision rule for what comes next: pivot, persevere, or kill.

The implications are pointed. Validated learning means learning that comes from the behaviour of real users with real stakes, not from interviews about a mock-up. Least effort means the team has actively scoped down, not scoped a wishlist. Hypothesis means the team wrote down what they think is true and what would convince them they're wrong. The MVP is the cheapest way to find out.

The "ship the MVP" anti-pattern.

The most common misuse is treating the MVP as a version. We're shipping the MVP next month. Then v1 will follow. If your team talks like this, you don't have an MVP. You have a phase 1. There's nothing wrong with phase 1, but it's not the same artefact. A phase 1 is scoped to ship. An MVP is scoped to learn. The two roadmaps look completely different.

The tell is whether the team can articulate the hypothesis. Ask: what will this MVP prove or disprove? If the answer is "that users like the product" or "that we can build it" or "that it's viable", you have a phase 1 in MVP clothing. A real MVP has a sharp hypothesis (users in segment X will pay £Y/month for capability Z if we remove their current alternative), and the experiment is designed to answer exactly that.

Kniberg's skateboard.

The clearest visual rebuttal to the anti-pattern is Henrik Kniberg's diagram from 2016. Two rows of staged delivery. The top row builds a car by piece: wheel, then chassis, then body, then the finished car. The user has nothing usable until the last step. The bottom row solves the underlying problem, getting around, at every step: skateboard, then scooter, then bike, then motorcycle. Each is a usable product. Each can be released. Each generates feedback. The car arrives at the same time in both rows; only one of them learned anything along the way.

Diagram · Kniberg's skateboard — two ways to build the same product
Kniberg's skateboard — two contrasting paths to building a product Two horizontal rows comparing approaches to delivering a product. The top row, marked Wrong, shows four stages of building a car by part — wheel, chassis, car body, finished car — where the user has nothing usable until the final stage. The bottom row, marked Right, shows four stages of solving the underlying problem of transportation — skateboard, scooter, bike, motorcycle — where each step is a complete, rideable vehicle that delivers value. A right-side note in italics reads: Row 2: every step delivers value. ROW 01 · WRONG Wheel Chassis Car body Finished car :( :( :( :) ROW 02 · RIGHT Skateboard Scooter Bike Motorcycle :) :) :) :D Row 2: every step delivers value. Row 1: only the last step does. Same destination. Different learning.
Kniberg's drawing makes the point in one image. The car arrives at the end of both rows. But row 2 sells skateboards, learns from skater behaviour, finds out that half the market actually wanted scooters, and ends up shipping a motorcycle the market has already endorsed.

MVP, MMP, MLP: the family of related artefacts.

Three terms get tangled. Worth separating them because each has a different job.

  • MVP: Minimum Viable Product. The smallest experiment that produces validated learning. Optimised for speed of feedback. Often embarrassing-looking. Lives only long enough to prove or disprove the hypothesis.
  • MMP: Minimum Marketable Product. The smallest product you'd actually sell. Optimised for commercial readiness. Has pricing, support, onboarding. Not the same artefact as the MVP. It is what you build after the MVP validated the hypothesis.
  • MLP: Minimum Lovable Product. Term popularised by Jiaona Zhang and others as a corrective to ugly MVPs. The smallest product users actually love. Minimum on scope, but high on craft. Useful framing for consumer products where "viable" isn't enough.

The right artefact depends on the question. Pre-product-market-fit, you want an MVP — cheap, ugly, fast learning. Post-PMF, you want an MMP or MLP. Viability is no longer the question; the question is whether you can sell it at scale, or whether people will love it enough to tell others.

Ship a wheel and the user has nothing. Ship a skateboard and they have a ride.

The four-quadrant trap.

A common mistake when scoping an MVP is to grade features on a two-axis matrix (impact vs effort, or must-have vs nice-to-have) and ship the high-impact, must-have quadrant. The result is usually a complete-but-thin product that doesn't actually test anything sharp. Every feature is in the MVP because every feature scored "must-have", but nobody ever asked which hypothesis each feature was testing.

The better question is hypothesis-led: what is the riskiest assumption? Build the smallest thing that tests that assumption. If your riskiest assumption is that users will adopt a new workflow, the MVP is the workflow change, not the polished UI around it. If your riskiest assumption is that users will pay, the MVP is a paywall and an order form, not a free trial that collects emails. The four-quadrant matrix optimises for completeness. Hypothesis-led scoping optimises for learning.

When you need different.

MVP doesn't suit every context. Three where it falls down hard:

  • Regulated industries. Healthcare, finance, defence. You can't ship a half-built medical device "to learn". The MVP equivalent is a paper prototype with regulated stakeholders, a wizard-of-oz back end, or a closed pilot under a research protocol. The principle holds (smallest experiment, sharpest hypothesis) but the form changes.
  • Network-effect products. If your product only works at scale (marketplaces, social networks, multi-sided platforms), the MVP cannot be small without being useless. Look at how Airbnb seeded the supply side manually, or how Reddit ran fake accounts to populate the early site. The MVP question becomes: what is the smallest credible-feeling experience that gets us past the cold-start problem?
  • Established markets with high quality bars. If you're entering against incumbents in an enterprise space, an ugly MVP gets you laughed out of the room. Here the closer cousin is the MLP. Minimum scope, maximum craft on the surface that matters.

Where this lands at Product Pieces.

When we work through scoping with a team, usually in the Discovery Set Piece or as part of the PM Piece, the first question is always: what's the hypothesis? If the team can't state it in one sentence, with the segment, the change, the measurable outcome and the kill criterion, the MVP scope conversation is premature. We slow down. We write the hypothesis. We size the experiment. Often the team realises the cheapest valid experiment is half what they were planning to build — and twice as informative.

If your team has the symptom (an MVP that "launched successfully" and then revealed nothing about whether the product should exist), the missing piece is usually upstream of scope. It's the hypothesis the team never wrote down.

Next issue: N°16: Product/Market Fit. The thing the MVP is trying to find.