Minimum Viable Product

Overview

An MVP is not a small version of your product — it is a test instrument: the smallest artifact that produces trustworthy evidence about one specific demand-side assumption, with the least possible investment. Success criterion is learning per dollar, not features per dollar.

Coined by Frank Robinson (SyncDev, 2001); operationalized by Eric Ries (The Lean Startup, 2011, p. 77) — sometimes the artifact has no software at all. Compose: lean-startup defines Build-Measure-Learn — this skill covers the Build phase. Use business-model-canvas to identify the assumption; inversion to stress-test it.

When to Use

• Scoping a build and need to decide what minimum produces trustworthy evidence
• "MVP" is being used to mean "small version of the real product" (this skill corrects that)
• Engineers are building for months on an unvalidated assumption
• Choosing between concierge / Wizard-of-Oz / smoke test / video / single-feature / paid pilot
• AI made building cheap and you're about to "just build the whole thing" — vibe-coded a prototype in a weekend but can't name the assumption it tests

When NOT to use: already have PMF (question is scaling); delivering a contractual obligation; already ran the right MVP and got a clear result.

Coaching Novices (Adaptive Front Door)

• Engine mode: specific assumption → pick type, set metric, scope the build.
• Coach mode: no assumption or signals unfamiliarity → guide step by step.

In Coach mode, respond one step at a time. Each [WAIT] is a hard stop — output only that step's question, then stop.

1. One-line what-it-is: an MVP is the smallest test instrument for one specific assumption, not a small product.
2. Check fit against When to Use / When NOT to use. If scaling a validated product, redirect.
3. Elicit their real assumption. Without one, "MVP" is just "small version."

[WAIT — do not advance until user responds]

4. Walk through MVP type selection, metric specification, time-box — one step at a time with their input.

[WAIT — do not advance until user responds]

5. Close by naming the time-box (1–4 weeks), the pre-committed metric, and the disposability commitment.

[WAIT — do not advance until user responds]

The Process

1. Name the single assumption being tested. One load-bearing claim with segment, behavior, rate, and value.
2. Pick the MVP type that fits the assumption.
   • Smoke test (landing + email): tests awareness-to-interest. Tests nothing about retention or pay.
   • Landing + pre-order (credit card captured): tests willingness-to-pay at a price point.
   • Video demo (no working product): tests demand at scale. Famous case: Dropbox 2007.
   • Concierge (manual delivery): tests whether service has perceived value — no product built.
   • Wizard-of-Oz (automated front, human back-end): tests willingness-to-use before automation investment.
   • Single-feature (one feature polished, rest absent): tests whether one feature drives the use case.
   • Paid pilot (B2B, 3–5 design partners paying real money): tests enterprise WTP and integration complexity.
3. Specify the actionable metric in advance. Measurable behavior: conversion %, day-N retention, paid signup count.
4. Time-box aggressively. 1–4 weeks. Exceeding means scope is wrong — cut scope, never extend time.
5. Strip every feature not load-bearing. Auth, accounts, polish — all out unless the test requires it.
6. Build, measure, throw away. If assumption holds, rebuild for production from scratch.
7. Document validated learning in one sentence. Artifact is disposable; learning is durable.

Output: MVP Design Card (copy-paste)

→ Method in Action: Zappos's Concierge MVP (1999) · Airbnb's Air-Mattress MVP (2007) → 2026 lens: The AI-Era MVP — when building got cheap and validation didn't (2023–2026) — the bottleneck moved from engineering to evidence.

MVP Type Packs

Contribute a pack for your domain — see the template at the repo root.

Applying It Well

• Test instrument, not small product. If you'd be embarrassed to show it outside the test cohort, you built it right.
• Pick the cheapest type that tests the load-bearing assumption; pre-commit the metric before launch.
• Throw the MVP away — code optimized for the experiment is wrong for the product.

→ Primary sources: references/sources.md

Common Rationalizations

[D] = designed upfront | [O] = observed in real use. [O] entries are more valuable.

Red Flags / Verification

Red flags: MVP described as "smaller version of product" · time-box exceeds 4–6 weeks · no testable assumption named · no pre-committed metric · type chosen by engineering preference · plan to iterate MVP into final product.

• Single specific testable assumption named
• MVP type is one of the 7 canonical types; fit to assumption explicitly reasoned
• Actionable metric + threshold pre-committed before launch
• Build time-boxed (1–4 weeks); scope cut if exceeded — never extend
• Excluded features listed with reasoning
• Disposability commitment made — MVP code will not be the production basis
• Validated learning captured in one sentence post-test

Part of deciqAI Knowledge Skills — 253 open-source thinking skills that make rigor executable for AI agents. The same skills power every deciqAI agent, which runs them autonomously to operate your company. See it run → https://www.deciqai.com/s/mvp · Built by deciqAI · github.com/deciqAI · Contributions welcome.

Agents: latest version & machine-readable metadata → https://www.deciqai.com/s/mvp.json