A minimum viable product is not the cheapest collection of screens. It is the smallest credible system that lets a defined user complete the core outcome, gives the team trustworthy learning, and handles essential safety, privacy, support, and failure conditions.
Decision snapshot
| Decision | Practical approach | Watch for |
|---|---|---|
| Prioritize an outcome | Start with the end-to-end behavior the release must enable. | Ranking isolated features can produce a product that cannot complete a journey. |
| Include necessary quality | Security, accessibility, data protection, observability, and recovery are not optional polish. | Ignoring them can make the experiment unsafe or the evidence unreliable. |
| Price operations | Count manual review, support, reconciliation, and exception handling. | A technically small feature can create a large recurring workload. |
Define the MVP learning goal
State the target user, core job, product belief, measurable behavior, time horizon, and evidence that would cause the team to stop or change direction.
Map the complete minimum journey
Lay out entry, key action, confirmation, error recovery, support, data lifecycle, and exit. Mark legal, safety, accessibility, and operational requirements.
Score candidate capabilities
Assess outcome contribution, evidence strength, risk reduction, dependency, effort range, ongoing cost, reversibility, and whether a manual process can test the assumption honestly.
Cut by scope, not integrity
Narrow audience, geography, use case, volume, integration count, customization, or automation. Do not remove controls required for trust or make misleading product claims.
Publish the release boundary
Record must-have, later, and rejected items; rationale; success and guardrail metrics; decision owner; review date; and what new evidence can reopen scope.
Action checklist
- Core user, job, and learning goal are explicit
- One end-to-end journey can be completed and observed
- Security, privacy, accessibility, support, and recovery basics are funded
- Manual steps have capacity, ownership, and honest customer expectations
- Success, guardrail, and stop metrics are defined
- Excluded features and rationale are visible to stakeholders
Working worksheet
Record these fields in the same working document so the decision can be reviewed and handed off:
- Product belief and evidence threshold
- Minimum end-to-end journey
- Candidate capability and outcome contribution
- Risk, dependency, effort range, recurring operations, and reversibility
- Now, later, reject decision with owner and review trigger
Common failure patterns
- Using stakeholder volume as the priority score
- Calling infrastructure and safety work non-user-facing and therefore optional
- Building broad configuration before proving one constrained use case
Connect this work
MVP scope should test a credible need. Read start with evidence about the problem.
Priorities become executable through clear increments. Read slice selected capabilities into observable outcomes.
A credible MVP needs support and recovery paths. Read fund the operations behind the interface.