Download App
Ready to become a better product manager?
Build your product skills with short, practical lessons you can fit around your day.
Start with our free courses and upgrade anytime.
A minimum viable product (MVP) is the smallest implementation that lets real users complete a meaningful task, so a team can observe what happens and decide what to do next.
A shared MVP definition prevents two expensive errors: overbuilding before learning, and calling weak signals validation. The PM sets the bar for what counts as credible — which decision the MVP informs, what observable behavior maps to the assumption, and what remains unresolved afterward.
State the decision the MVP informs, the assumption it tests, the observable user behavior that maps to that assumption, and what the test cannot establish. Scope the smallest implementation that completes a meaningful task with enough quality and trust to make the result interpretable — then hand assumption-to-test matching and evidence interpretation to the validation workflow.
Synthetic example — hypothetical scenario, not measured results. A team wonders whether managers act on weekly staffing-risk summaries. They hand-write four summaries from real schedule data and deliver them inside the existing manager workflow. Managers open, forward, and reschedule shifts from them. That manual loop can function as an MVP because real value is delivered and observed; a polished mock shown in interviews could not answer the behavior question.
A minimum viable product is the smallest implementation that lets real users complete a meaningful task, so the team can observe what actually happens and decide what to do next. The phrase comes from Lean Startup: Eric Ries defined the MVP as the version of a new product that lets a team collect the maximum validated learning about customers with the least effort.
Each word carries weight:
The most common confusion is treating every cheap test as an MVP. Use this boundary: if users cannot complete a meaningful part of the real job through it, it may be a useful test, but it is not an MVP.
| Candidate | Verdict | Why |
|---|---|---|
| A manually delivered end-to-end service that target customers reuse | Can be an MVP | Enough of the real value loop exists: users act, the team observes repeated behavior, commitment, or payment in a defined context. |
| A narrow production slice behind controlled exposure | Can be an MVP or pilot | Real users complete a real task with real consequences. The label depends on the learning objective and operating context, not on size alone. |
| Customer interviews or surveys | Research method, not an MVP | They reveal context, motivations, and prior behavior — but no product loop exists for users to act through. |
| A clickable prototype in a moderated test | Usually a prototype, not necessarily an MVP | It answers comprehension or usability under test conditions. It does not by itself establish value, demand, or live behavior. |
| A landing page measuring signups | An experiment, not an MVP by itself | It observes response to a proposition and call to action under that traffic and context. A signup does not establish usage, retention, or willingness to pay. |
| A slide deck, vision doc, or demo video with no usable path | Not an MVP | Nothing real can be completed through it, so no product behavior is observed — however persuasive it looks. |
Synthetic examples — hypothetical scenarios, not measured results. A team testing whether managers act on weekly staffing-risk summaries hand-writes the first four summaries from real schedule data and delivers them inside the existing manager workflow. Managers open, forward, and reschedule shifts from them. That manual loop can function as an MVP: the value (earlier action) is delivered, even though automation does not exist yet.
Contrast: the same team shows a polished mock of a risk dashboard in interviews and hears enthusiasm. That is a useful comprehension signal, but nobody staffed a shift through it — so it cannot answer whether the summary changes behavior. The mock is a prototype test, not an MVP.
“Minimum” without “credible” produces stubs that teach nothing: too little quality, trust, or functionality for the result to be interpretable. The bar is set by the decision, not by a feature count — higher stakes, irreversible exposure, or weak existing evidence raise it; reversible, low-risk contexts lower it.
Before scoping anything, answer these four questions. If any answer is missing, the MVP is not defined yet:
Matching the right instrument to the assumption — and interpreting mixed evidence honestly — is a larger discipline than this page. It belongs to Validation and MVPs, which teaches assumption-to-test matching without pretending evidence creates certainty.
These concepts overlap with MVP. The table states each one's job so this page does not absorb theirs.
| Concept | Its job | Boundary |
|---|---|---|
| Prototype | Explore comprehension, flow, or interaction cheaply | A representation for a specific question. It becomes MVP material only when a real value loop runs through it. |
| Proof of concept / technical spike | Establish whether something can be built or perform reliably | Answers feasibility. It says nothing about desirability or usability on its own. |
| Pilot | Operate a bounded real deployment with real users | A pilot can serve as an MVP when its objective is learning; pilots run for operational or rollout reasons are a different job. |
| Minimum marketable / lovable product | Ship the simplest offering the market will accept or love | Optimizes for selling and early-customer value. An MVP optimizes for learning and may never be sold as-is. |
| Experiment (e.g. A/B test, fake door) | Observe a defined effect under controlled conditions | A method, not a product. Experiments can sit inside an MVP strategy; most are not MVPs themselves. |
A minimum viable product is the smallest implementation that lets real users complete a meaningful task, so the team can observe what actually happens and decide what to do next. Minimum refers to scope; viable means the experience is complete and trustworthy enough that the learning is interpretable.
No. An MVP can be a manually delivered service, a narrow production slice, or a concierge-style workflow — as long as enough of the real value loop exists for users to act and for the team to learn. Slides, visions, and opinions alone are not MVPs.
Not automatically. A prototype in a moderated test answers comprehension or usability questions; a landing page measures response to a proposition under specific traffic and context. Either can be a legitimate test, but neither is an MVP unless users can complete a meaningful part of the real job through it.
A prototype is a representation used to explore or evaluate something specific — comprehension, flow, or interaction — often without a working value loop. An MVP implements enough of the value loop that real use produces decision-relevant evidence. A prototype can be part of validation without being the MVP.
An MVP optimizes for learning: the smallest credible vehicle that answers the current question. A minimum marketable product optimizes for selling: the simplest offering the market will accept from early customers. A successful MVP often grows toward an MMP, but they answer different questions.
When the uncertainty can be answered more cheaply — an interview for workflow context, a prototype for comprehension, a data check for frequency, a technical spike for feasibility — building even a small product is waste. An MVP earns its cost only when real use is the instrument the question requires.
Once the meaning is clear, the next job is matching your riskiest assumption to the cheapest test that can answer it — and deciding whether that test needs to be an MVP at all. Learn that workflow in Validation and MVPs, or clarify the earlier gate — whether the problem deserves investment — in what problem validation really means.
Build your product skills with short, practical lessons you can fit around your day.
Start with our free courses and upgrade anytime.