| name | define-an-mvp |
| category | start |
| description | Define the smallest product or service that delivers one real user outcome and tests the riskiest product assumption with explicit exclusions and evidence. Use when a product idea has grown into too many features, a team cannot agree what version one includes, or a validated problem needs a first release boundary. |
define-an-mvp
Minimize the investment required to learn, not the care required to serve the user. Keep the full critical
outcome, remove optional automation and breadth, and decide in advance what evidence changes the next build.
Inputs
- Gather the validated problem evidence, target user, current alternative, assumption map, constraints, and owner.
- Name the learning deadline, risk tolerance, budget, privacy, safety, and operational capacity.
- Separate required outcome from requested features.
Procedure
- Write the target user, situation, current problem, and observable successful outcome.
- Rank assumptions by uncertainty and consequence. Choose the one the first release must test.
- Map the complete critical journey from entry through outcome, failure, recovery, and support.
- Mark the minimum capability needed at each step for the outcome to remain real and trustworthy.
- Replace automation with a documented manual process where it is safe, honest, and learnable.
- Remove extra audiences, channels, integrations, customization, dashboards, and scale features.
- Write explicit included and excluded lists plus the condition that could add each excluded item.
- Define quality, privacy, accessibility, support, data, and recovery requirements that cannot be cut.
- Choose the exposure group, success signal, guardrails, duration, stop rule, and next decision.
- Estimate build and operating effort, then cut again if the learning question can be answered more directly.
- Review the boundary with delivery and support owners and publish the MVP brief.
Boundaries
Do not call a broken, unsafe, deceptive, inaccessible, or unsupported experience minimal. Never conceal
manual work or pretend a prototype is a finished service. Do not add features merely to satisfy internal stakeholders.
Done
- An MVP brief names one user, problem, outcome, riskiest assumption, and complete critical journey
- Included and excluded capabilities have explicit decision conditions
- Non-negotiable quality, privacy, accessibility, support, and recovery requirements are approved
- Exposure, evidence, guardrails, stop rule, owner, and next decision are defined before building
Then use start-an-app or build-web-app for implementation and launch-a-product for controlled exposure.
