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 also6
Worse Is Better
A simpler, less correct design that ships and spreads beats a more correct one that doesn't, because adoption compounds.
Method7 connections
Feature Creep
A product accumulates features one reasonable addition at a time until the sum is bloated, slow, and hard to use.
Method9 connections
Second-System Effect
The tendency for a system's successor, freed of its predecessor's constraints, to become dangerously over-engineered.
Method12 connections
Fermi Estimation
Reaching a defensible order-of-magnitude answer by decomposing a question into estimable factors.
Method24 connections
Acceptance Testing
Checking that software does what its users and stakeholders actually need, the criteria agreed before building, and the gap between passing every test and building the right thing.
Testing & Verification9 connections
User Story
A short description of something a user wants, written in their terms and meant as a reminder to have a conversation, which became agile development's basic unit of planning.
Version Control & Delivery4 connections
Linked from8
- Acceptance TestingTesting & Verification
Checking that software does what its users and stakeholders actually need, the criteria agreed before building, and the gap between passing every test and building the right thing.
- 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.
- Product BacklogVersion Control & Delivery
The single ordered list of everything a team might build next, kept in priority order and refined continuously so the top items are small and clear enough to start, though in practice backlogs tend to grow faster than teams can empty them.
- Second-System EffectMethod
The tendency for a system's successor, freed of its predecessor's constraints, to become dangerously over-engineered.
- User StoryVersion Control & Delivery
A short description of something a user wants, written in their terms and meant as a reminder to have a conversation, which became agile development's basic unit of planning.
- Worse Is BetterMethod
A simpler, less correct design that ships and spreads beats a more correct one that doesn't, because adoption compounds.