mvp-scope-planner

Test each candidate capability against four questions: whether it completes the core journey, tests the primary assumption, is required by safety or compliance constraints, or whether excluding it makes the result unusable. Classify each item as MVP, later, experiment-only, or not planned with a recorded rationale.

Define the thinnest complete user journey from entry to achieved outcome first, then remove only capabilities outside that journey. Keep accessibility, privacy, security, and failure recovery in scope since they are quality constraints, not optional polish.

Avoid MVP scoping when the problem or target user is undefined, when scope is already decided and you only need milestones, or when the release has fixed compliance or contractual requirements. In those cases use milestone planning or label the release accurately instead.

Expose the consequence of removing each item rather than debating importance abstractly. Present coherent scope options with explicit cost and learning tradeoffs so stakeholders can choose based on evidence, not pressure.

When an integration dominates cost or uncertainty, run a concierge test, prototype, or dependency spike before committing to the build. Prefer reversible or manual solutions only when they do not transfer unacceptable burden to users or operators.