Minimum Viable Product¶
Minimal product release — instantiates Minimum Viable Learning Release
Ships the smallest usable product that still delivers the one core benefit, so real usage — not opinion — decides whether the rest gets built.
A Minimum Viable Product is the smallest shippable artifact a user can operate by themselves that still delivers the single core benefit — built so that the behaviour it produces answers whether the fuller product is worth building. Its defining claim is that the release is a product the user drives, not a service someone performs for them and not a workflow someone runs behind the scenes; and its whole reason to exist is the behavioural evidence that comes back from real, unassisted use. The art is holding two things at once: trim everything that does not serve the core benefit, but keep what remains above a value floor, because a product stripped below usefulness produces feedback about underbuilding rather than about the idea. An MVP is not "version 0.1 with fewer features" — it is the smallest thing that can tell the truth about whether people will actually use the core.
Example¶
A four-person team wants to build a language-learning app: lessons, speech scoring, streaks, a social feed, gamified rewards. Instead they ship one screen — spaced-repetition flashcards for Spanish only, one starter deck, sign-in by email and nothing else. It delivers the core benefit (you genuinely learn words), and it instruments day-7 and day-30 return plus words-mastered per active user. They commit before launch to the reading: if a real cohort keeps coming back and clears a set retention and mastery bar, they expand into more languages and speech scoring; if people install, drill for two days, and vanish, the core loop itself is wrong and no amount of speech scoring will save it — pivot. Three weeks and one screen later they know which world they are in, having spent none of the budget the full build would have consumed.
How it works¶
- Name the one core benefit. Everything the release must still deliver reduces to a single job the user came for.
- Hold the value floor. Cut hard, but keep the artifact above the threshold where use is pleasant and reliable enough that behaviour means something.
- Ship to real, unassisted users. No concierge hand-holding — the point is what people do when the product stands alone.
- Read a behavioural signal against a pre-set bar. Retention, task completion, or willingness to pay — chosen in advance and tied to a committed expand / pivot / stop rule.
Tuning parameters¶
- Scope floor — how much you strip before use stops being meaningful; too much yields a hollow product, too little defers the learning.
- Value-threshold height — how polished the core must be; higher costs more but makes the signal trustworthy.
- Signal choice — behavioural (cohort retention, paid conversion) versus vanity (installs, page views); the former informs a decision, the latter flatters one.
- Decision-bar strictness — how strong the evidence must be to expand; loose bars rationalize, tight bars kill promising loops early.
- Iteration cadence — one-shot read versus rapid weekly re-ships that chase the core loop.
When it helps, and when it misleads¶
Its strength is that it forces the value question ahead of the build cost: you learn whether anyone will use the core before you pour months into everything around it. Its classic failure is the hollow MVP — stripped below the value floor, so early churn reflects underbuilding, not a bad idea — and its classic misuse is chasing vanity metrics,[n1] celebrating download counts while cohort retention quietly says no one stays. The discipline that keeps it honest is to pre-commit both the value floor and the behavioural signal before shipping, and to treat "people installed it" as the beginning of the question, never the answer.
How it implements the components¶
core_user_need— reduces the release to the single benefit the stripped product must still deliver.viable_value_threshold— sets the floor below which use stops being meaningful, guarding against the hollow build.learning_signal— reads real unassisted behaviour (retention, completion, willingness to pay) as the evidence.expansion_or_pivot_criteria— the pre-set bar that converts that signal into build / pivot / stop.
It holds no manual support_boundary around hand-delivery — that is Concierge Test — and never bounds exposure with a participant_or_rollout_boundary, which is Limited Cohort Rollout. And unlike its near-twin Minimum Viable Process, it keeps no learning_record of workflow handoffs: this page watches a user's uptake of a product they operate, not a process's internal flow.
Related¶
- Instantiates: Minimum Viable Learning Release — the MVP is the product-domain instance of the pattern, delivering real core value while reading whether to expand.
- Consumes: Concierge Test — where demand is unproven, the value is best validated by hand first, so the MVP is built only after the outcome is known to be wanted.
- Sibling mechanisms: Pilot Service · Concierge Test · Alpha Release · Limited Cohort Rollout · Small-Batch Policy Pilot · Minimum Viable Process · Feature-Flag Release
Editorial Notes¶
Form Classification¶
Form family: Experiment, Test & Rehearsal
Rationale: Minimum Viable Product operates as a bounded trial, probe, simulation, or rehearsal that generates evidence from performance because it ships the smallest usable product that still delivers the one core benefit, so real usage — not opinion — decides whether the rest gets built.
Independent corroboration: The frozen evidence defines Minimum Viable Product as 'Ships the smallest usable product that still delivers the one core benefit, so real usage — not opinion — decides whether the rest gets built', so its operative form is Experiment, Test & Rehearsal.
Nearest alternative: Intervention, Treatment & Transformation — The product directly serves users, but the bounded release is primarily an evidence-generating field test of real behavior against a preset bar.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Innovation & Entrepreneurship
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: The minimum viable product is a canonical Lean Startup mechanism for validated learning.
Related originating lineages:
- Organizational & Management Science — Lean product and iterative development practice shaped organizational implementation.
Review resolution: Both independent reviews place the primary provenance in innovation_entrepreneurship. The queued differences (origin_mode_disagreement, domain_reach_disagreement) concern secondary metadata, not primary lineage. The final retains organizational_management only where a reviewer supplied a formative-lineage rationale; downstream use or broad applicability by itself is not treated as origin. origin_mode=cross_disciplinary_synthesis because the supplied rationales identify formative contributions that are composed in the mechanism's present form. domain_reach=multi_domain records established application breadth separately from provenance. confidence=high preserves the more cautious evidence assessment. encyclopedia_synthesis=false records whether either reviewer identified deliberate corpus-level composition.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
"MVP" is the most abused label in the family: teams call any thin launch an MVP. What makes it this mechanism is not the smallness but the committed learning signal — a small product with no pre-set decision attached is just a small product, not a viable learning release.
[n1] Vanity metrics — figures that look impressive but do not inform a decision (cumulative downloads, raw signups), as contrasted in lean-startup practice with actionable metrics like cohort retention. An MVP that reports the former is measuring its own applause, not the core need. ↩