process & strategy
MVP (minimum viable product)
What is a minimum viable product (MVP)?
An MVP is the smallest version of a product that still delivers real value to users and lets you learn whether your idea works - before you've built the whole thing. The point isn't to ship something cheap and broken; it's to ship the smallest complete, usable slice that tests your riskiest assumptions with real people, fast.
Also known as: mvp, minimum viable product, minimum viable
Prefer to watch?
Watch the recap 1:02
The demo
You want to build a car. Two ways to get there. Step through each and ask, at every stage: could a real person use this yet - and could you learn anything from them?
What this demo shows (text version)
The goal is a car, built two ways. In "build it in parts" you make a wheel, then a chassis, then a body, then the finished car - and at every stage before the last, the user has nothing they can actually use, so there's no real feedback until the whole thing is done. In "build an MVP each time" you make a skateboard, then a scooter, then a bicycle, then the car - each a complete, usable way to travel that real people can try and react to at every step.
That's an MVP: the smallest complete, genuinely useful version that tests your riskiest assumptions and lets you learn from real users early. It's not a cheaper, broken version of the final product - the "viable" matters as much as the "minimum". Build the least that delivers real value, learn, and iterate.
An MVP is the fastest honest way to learn whether you're building the right thing - not a stripped-down, half-broken version of the final product. The classic illustration: if the goal is a car, don't ship a lone wheel, then a chassis, then a car (each useless until the end); ship a skateboard, then a scooter, then a bike - each a complete, usable way to get from A to B that you can put in front of real users and learn from. Build the minimum that delivers genuine value and tests your riskiest assumption, get real feedback, and iterate. The "viable" matters as much as the "minimum": it must actually work and help someone, or you learn nothing useful.
Building the car piece by piece, users had nothing usable until the very end - and if the idea was wrong, you found out far too late. The skateboard-to-bike path gave people something that worked at every stage, so you learned and adjusted as you went. That's the real point of an MVP: not a smaller, worse product, but the smallest complete and useful thing you can learn from early.
The MVP, central to Lean Startup thinking, exists to maximise validated learning per unit of effort: build the least you can to test whether people actually want and will use the thing, then iterate based on real evidence rather than assumptions. It de-risks big bets by surfacing wrong assumptions early, when changing course is cheap, instead of after a full build.
Henrik Kniberg's famous drawing captures the common mistake: building a car incrementally (wheel → chassis → body → car) leaves users with nothing usable until the end and no early feedback, whereas building a means of travel incrementally (skateboard → scooter → bicycle → car) gives a complete, usable product at every step that people can use and react to. Each version is "minimum" but genuinely "viable".
The pitfalls are at both ends of the phrase. Skimp on "viable" and you ship something broken or valueless that drives users away and teaches you nothing real (a bad first impression also lingers, via negativity bias). Over-invest in "minimum" and you've built too much before learning anything. Define the riskiest assumption, build the smallest thing that genuinely tests it while delivering real value, measure honestly, and iterate - the MVP is a learning tool, not a launch shortcut.