Minimum Viable Product
The smallest version of a product that lets you learn something real from actual users, not the smallest embarrassing version.
Minimum Viable Product is the smallest version of a product capable of producing a genuine, validated round of learning about whether it solves a real problem for real users — not, despite the common shorthand, simply "the smallest thing we can ship." Eric Ries formalized the term in The Lean Startup, but the core idea predates the label: build the least you need to test the riskiest assumption, then let what you learn decide what to build next, rather than deciding the whole roadmap up front on guesses.
The word "viable" is where most misuses of the term go wrong. A product with half its buttons broken isn't an MVP, it's an unfinished product — it can't produce a valid signal, because users can't tell you whether the idea works when the execution is too broken to experience the idea at all. The famous counter-example is Dropbox's original "MVP": not a working product at all, but a screen-recorded demo video of a system that didn't yet exist, released to gauge signup interest — minimal in build effort, but fully viable as a test of the actual question being asked (do people want this), because the video let people evaluate the real value proposition without a single line of the eventual sync engine.
The core discipline is naming the assumption being tested before deciding what to build, then building only what's needed to test that one thing — not a smaller version of the final product's feature list, which is a different exercise entirely and usually the wrong one. A ride-sharing MVP that manually dispatches drivers by phone isn't a smaller ride-sharing app; it's a different, cheaper way to find out whether people want the ride at all, before any app gets built.
MVP is often confused with "prototype" or "beta," but neither of those implies the same commitment to learning from real usage — a prototype can be thrown away after a demo, an MVP is supposed to generate data that changes the next decision. It's the practical expression of Gall's Law applied to product strategy: start with something that works at a small scale, and let the complex version grow from what that teaches you.
See also4
Gall's Law
A complex system that works evolved from a simple system that worked; a complex system built from scratch never does.
Method5 connections
Feature Creep
A product accumulates features one reasonable addition at a time until the sum is bloated, slow, and hard to use.
Method6 connections
Second-System Effect
The tendency for a system's successor, freed of its predecessor's constraints, to become dangerously over-engineered.
Method10 connections
Worse Is Better
A simpler, less correct design that ships and spreads beats a more correct one that doesn't, because adoption compounds.
Method6 connections
Related1
Nearby in the graph rather than deliberately chosen. Looser, sometimes surprising.
Linked from5
- Feature CreepMethod
A product accumulates features one reasonable addition at a time until the sum is bloated, slow, and hard to use.
- Gall's LawMethod
A complex system that works evolved from a simple system that worked; a complex system built from scratch never does.
- Parkinson's LawMethod
Work expands to fill the time allotted for it, so a deadline shapes effort more than the task's actual size does.
- Second-System EffectMethod
The tendency for a system's successor, freed of its predecessor's constraints, to become dangerously over-engineered.
- Worse Is BetterMethod
A simpler, less correct design that ships and spreads beats a more correct one that doesn't, because adoption compounds.