Tool/Design and Human Factors/No. 0618
Minimum Viable Product
A minimum viable product (MVP) is a limited offering used to test a key assumption before a full build. Coined by Frank Robinson and popularized by Eric Ries in lean startup practice, it seeks useful evidence with less time, cost and exposure to failure.
Also called MVP
- Evidence
- Useful, modest evidence
- Read
- 6 min
- Links
- 10 connections
- Useful when
- Deciding under uncertainty · Designing products · Running projects
01You've seen this when…
- at work
Your team proposes an automated reporting service. Before building it, you send three customers a manually prepared report and watch whether they use it.
- in life
You want to organize a neighborhood soccer league. You arrange one Saturday game to see who actually shows up before designing a website and ordering jerseys.
- out in the world
A library considers lending household tools. It starts with a small collection at one branch and tracks borrowing, returns, and staff time before expanding.
02The idea
The reporting service sounds useful in a meeting. Delivering a small report can show whether a customer reads and acts on it, and whether they will pay for another one. You can get those answers before building the machinery.
A minimum viable product is a deliberately limited offering used to learn something important before making a larger commitment. In lean-startup usage, it can be a working product or an experiment around a proposed product. The point is not to release the fewest features. It’s to get useful evidence while spending less time and money and limiting exposure to failure.
Minimum is relative to the question. A demonstration may test whether people understand an unfamiliar idea. A manually delivered service may test whether they value the result. Neither proves that an automated system will work reliably.
Viable means credible enough for the test and safe enough for the people involved. You can leave out account customization. You cannot leave out protections that prevent users from losing money or exposing private information.
Usability testing asks whether people can use something. Pretotyping focuses on checking interest before substantial implementation. Both can overlap with an MVP. The distinguishing purpose is learning enough to guide the next investment.
03How to use it
- Choose the assumption that could sink the plan. Customers may not need the result, may be unwilling to pay for it, or may never return after one use. Let the uncertainty that matters most guide your first test, even if another feature would be easier to build.
- State what behavior would support or weaken it. For a hypothetical meal-planning service, payment and a second purchase tell you more than compliments about the menu. Decide beforehand which results would justify continuing and which would call for changing direction or stopping.
- Build only what that test requires. Use a spreadsheet, a limited release, or manual delivery if that gives customers the relevant experience. A Wizard-of-Oz prototype, where people perform work that appears automated, can help test an experience without building the automation. Don’t mislead users about consequential limitations.
- Recruit people who resemble the intended users. Friends may be unusually patient. Enthusiasts may tolerate setup that ordinary customers won’t. Test under realistic conditions, including the proposed price when willingness to pay is the question.
- Keep safeguards outside the feature-cutting exercise. Identify privacy, accessibility, financial, and physical risks. Some safeguards must be complete from the start; others require restricting who participates and what the test can do.
- Record behavior and investigate the reasons. Track the action you care about, then talk to people who complete it and people who abandon it. A small test can reveal a serious obstacle without giving a precise estimate of market demand.
- Make the next decision promptly. Review the evidence at an agreed point. Decide whether it supports continuing or calls for revising the assumption or stopping. Set an endpoint for an inconclusive pilot.
This is Build-Measure-Learn with a deliberately small build. The experiment is valuable only if its result can change what you do.
04A worked example
Dropbox faced a difficult demonstration problem: file synchronization is valuable when it quietly works, but an unfamiliar service is hard to explain in words. Drew Houston had a working prototype. Building out the whole service before checking interest would still require substantial work.
As Eric Ries recounts in The Lean Startup, Houston made a narrated video showing the proposed experience and put it in front of a technology-minded audience. Beta signups rose sharply.
What it looks like A promotional video presented ahead of a product release. Nobody watching the video is yet depending on Dropbox to protect their files.
What’s actually going on A limited test makes the experience concrete and checks whether the intended early audience wants access. The demonstration draws on a working prototype. Signups provide evidence of interest while leaving open whether synchronization is reliable and whether people will pay for the service and keep using it.
What made it work The demonstration tested a specific uncertainty with a relevant audience, whose signups supplied a behavioral response. It created a way to learn before a full build. The next stage still had to test whether people would use and trust the service.
05When to reach for it
Think in terms of value of information: will this test answer a question whose answer could alter the decision?
06When it misleads
- Minimum becomes an excuse for careless work. A broken checkout measures customers’ tolerance for checkout failures and leaves demand unclear. Cut scope before cutting the quality needed to interpret the result.
- One successful test becomes proof of everything. A preorder leaves repeat demand untested. Manual delivery leaves the profitability of automation untested. List what remains unknown after each test.
- The measured action replaces the underlying goal. Registrations are easy to count, but may be a weak proxy for continued use. Measure the behavior closest to the assumption, even when another dashboard metric looks more impressive.
- Failure has more than one explanation. Weak uptake could reflect poor recruitment, confusing presentation, an unsuitable price, or an unwanted product. Investigate before declaring the underlying idea dead.
- A handful of users becomes a market forecast. Early adopters can reveal problems and possibilities. They cannot establish how a broad population will behave. Keep confidence proportional to the evidence.
- The downside cannot be contained. A small medical or financial product can still cause large harm. Use simulation, supervised trials, and expert review where necessary. A safe-to-fail experiment requires a contained downside, even at small scale.
An MVP also needs an owner, a review date, and a next step. Otherwise, temporary manual work becomes permanent, and the team accumulates a fragile service while the learning needed to make it dependable stalls.
07Roots
Frank Robinson, a product-development consultant at SyncDev, coined minimum viable product in 2001. His framing balanced the risk faced by the supplier with the value received by the customer. A first offering could be too large and expensive, but it could also be too thin to attract anyone. The useful minimum sat between those failures.
Eric Ries encountered a related problem at IMVU, a startup built around 3-D avatars and online chat. The team invested in connecting its product to existing instant-messaging services, then learned that customers didn’t want to use it that way. Working software had answered a question the team hadn’t adequately checked.
Ries made learning the center of the idea in his 2009 blog writing and his 2011 book, The Lean Startup. The MVP became a way to test assumptions, with a smaller feature list serving that purpose. It spread through startup practice into larger companies and service design. Along the way, the abbreviation often lost its purpose: teams began calling any small or unfinished release an MVP, regardless of its learning purpose.
08How solid is this?
The approach is grounded in iterative testing, but MVPs vary widely and famous cases are retrospective success stories. A well-designed test can resolve a specific uncertainty. The venture’s overall success remains an open question.
09Connections
- Often confused withPretotyping, Safe-to-Fail Experiment
- Helps counter Overconfidence Effect, Escalation of Commitment, Proxy Objective
- Part of Build-Measure-Learn, Gall’s Law, Value of Information
- IncludesUsability Testing, Wizard-of-Oz Prototype
10Origin and sources
Frank Robinson coined the term at SyncDev in 2001. Eric Ries popularized its learning-focused use through his 2009 writing and The Lean Startup (2011).
- [1]SyncDev. Minimum Viable Product.
- [2]Ries, E. (2009). Minimum Viable Product: a guide. Startup Lessons Learned.
- [3]Ries, E. (2011). The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown Business.
Suggest an edit· Updated 2026-10-02