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