Mvp Scoping

MVP Scoping

When to Use

Activate when a founder or PM has an idea or a full feature spec and needs to distill it down to the smallest version worth building. Trigger phrases include "what's our MVP," "what should we cut," "scope this down," "what do we build first," "we only have 4 weeks," or "help me prioritize what to include." Also activate when a team is struggling with scope creep and needs to draw a clear line between must-have and nice-to-have.

Context Required

• From startup-context: company stage, team size, runway/timeline pressure, existing product (if any), technical stack and constraints.
• From the user: the full feature vision or spec, target user segment, the core hypothesis being tested, available timeline and resources, any non-negotiable requirements (compliance, security, contractual commitments).

Workflow

1. State the hypothesis — Define what the MVP is designed to learn or prove. Format: "We believe that [user segment] will [behavior] if we provide [capability], and we'll know we're right when [measurable signal]."
2. List all candidate features — Enumerate every feature, capability, and requirement from the full vision.
3. Apply MoSCoW prioritization — Classify every item as Must Have, Should Have, Could Have, or Won't Have (this time).
4. Identify risks — For each Must Have, identify technical, market, and execution risks. Flag any Must Have that carries high risk and may need a spike or prototype first.
5. Define the cut line — Draw a clear boundary. Everything above the line ships in v1. Everything below has a specific trigger for when it gets built.
6. Estimate and validate — Rough-size the Must Haves. If they exceed the available timeline by more than 20%, force-rank the Must Haves and demote the lowest.
7. Write the MVP spec — Produce a concise scope document with explicit inclusions, exclusions, and deferred items.

Output Format

Hypothesis Statement

One sentence stating what the MVP will test and how success is measured.

MoSCoW Classification

Must Have (v1 — ships or the product fails)

Should Have (v1.1 — ships within 2-4 weeks after launch)

Same table format. These improve the product meaningfully but are not required for the core hypothesis test.

Could Have (v1.2+ — ships if data supports it)

Same table format. These are enhancements contingent on v1 learnings.

Won't Have (not this product/quarter)

List with brief reasoning for each exclusion.

Risk Register

MVP Scope Summary

Concise paragraph describing what v1 does, who it's for, and what it explicitly does not do.

Success Criteria

Specific metrics and thresholds that determine whether the MVP validated the hypothesis.

Frameworks & Best Practices

• MoSCoW prioritization.
  • Must Have: Without this, the product does not work or the hypothesis cannot be tested. Apply ruthlessly. If more than 40% of features are Must Have, your bar is too low.
  • Should Have: Important but the product can launch without it. Users will notice the gap but can work around it.
  • Could Have: Nice-to-have. Include only if time permits with zero impact on Must Haves.
  • Won't Have: Explicitly out of scope this cycle. Naming these prevents scope creep.
• The "cupcake, not a layer of cake" principle. An MVP is a complete, small experience — not an incomplete large one. A cupcake is a whole dessert. A cake layer with no frosting is an unfinished project.
• Optimize for learning speed. The MVP's job is to test a hypothesis as fast as possible. Every feature should either be required for the test or removed.
• Manual before automated. If a process can be done manually for the first 50 users, do not build automation for it in the MVP. Concierge MVPs and Wizard-of-Oz MVPs are valid.
• One user segment. MVPs that try to serve multiple segments serve none well. Pick the segment with the strongest pain and the shortest sales cycle.
• Hard conversation forcing function. If the team cannot agree on Must Haves, ask: "If we could only build 3 features, which 3 would we pick?" Start from zero and add, rather than starting from everything and cutting.
• Deferred is not deleted. Maintain a deferred backlog with explicit triggers: "Build feature X when metric Y reaches threshold Z." This reassures stakeholders that their requests are heard.
• Risk-first sequencing. Build the riskiest Must Have first. If it fails, you learn early and cheaply. If it works, everything else is lower risk.
• Scope creep signals. Watch for: "while we're at it," "it would be easy to also," "users will expect," and "competitors have." Each phrase requires the response: "Does this change our hypothesis?"