Scoping & Cutting

Scope

• Converting a fuzzy initiative into a ship-able slice that fits a fixed time budget (“appetite”)
• Creating a cut list (what to drop/defer) with explicit trade-offs and rationale
• Defining an MVP as a hypothesis test (what you’re validating, not just “smaller”)
• Choosing a Minimum Lovable Slice (viable and emotionally resonant) instead of a “barely works” release
• Using Wizard-of-Oz / concierge approaches to validate value before building full automation
• Preventing scope creep via explicit non-goals + change control

• “Cut scope / descope this feature so we can ship by <date>.”
• “Define an MVP for this initiative (what hypothesis are we testing?).”
• “We have 2–6 weeks; what can we ship that still matters?”
• “Scope creep is killing us; define what’s in/out and how changes happen.”
• “We need a minimum lovable version, not a compromised mess.”

• You don’t yet know what problem you’re solving (use

  problem-definition

  )
• You’re choosing between many competing initiatives (use

  prioritizing-roadmap

  )
• You need a decision-ready PRD with requirements (use

  writing-prds

  ) or a build-ready design/tech spec (use

  writing-specs-designs

  )
• You’re setting long-term product strategy or vision (use

  defining-product-vision

  )

Inputs

• The initiative/feature and the decision (ship vs defer vs stop) + target date or time budget
• Target user/segment + the core user journey you want to improve
• Success metric(s) + 2–5 guardrails (trust, quality, cost, latency, support load)
• Constraints and non-negotiables (legal/privacy, platform, dependencies, team size)
• Candidate scope items (bullets are fine) + known unknowns

• Ask up to 5 questions from references/INTAKE.md.
• If answers aren’t available, proceed with explicit assumptions and list Open questions that would change the cut decisions.

Outputs (deliverables)

1. Context snapshot (decision, date/appetite, stakeholders/DRI, constraints)
2. Outcome + hypothesis (what must be true; what you’ll validate)
3. Appetite + success bar (time budget, “done means…”, guardrails)
4. Minimum Lovable Slice spec (core flow, must-haves, non-goals)
5. Cut list (cut/defer/keep with rationale + impact on risks)
6. Validation plan (Wizard-of-Oz/concierge/prototype as needed) + success criteria
7. Delivery plan (milestones within appetite + scope-change rules)
8. Risks / Open questions / Next steps (always included)

Workflow (8 steps)

1) Intake + decision framing

• Inputs: User request; references/INTAKE.md.
• Actions: Clarify the decision, date/appetite, DRI, constraints, and what “shipping” means (where it lands, who uses it).
• Outputs: Context snapshot.
• Checks: You can state: “We are deciding to ship <slice> by <date> with <team> under <constraints>.”

2) Define the outcome and hypothesis (MVP = test)

• Inputs: Context snapshot; current evidence/risks.
• Actions: Write the outcome in user terms; define the key hypothesis (or 2–3). Choose success metric(s) + guardrails.
• Outputs: Outcome + hypothesis section; metrics/guardrails.
• Checks: You can answer: “What will we learn/validate by shipping this slice?”

3) Set appetite (time as a budget) + non-negotiables

• Inputs: Target date/timebox; constraints; team capacity.
• Actions: Set a hard time budget (e.g., 2/4/6 weeks). List non-negotiables (policy, privacy, reliability, design constraints).
• Outputs: Appetite + constraints section.
• Checks: Appetite is explicit and agreed; scope is the variable, not the deadline.

4) Design the Minimum Lovable Slice (MLS)

• Inputs: Outcome + constraints; candidate scope items.
• Actions: Define the smallest end-to-end flow that delivers the core value and feels coherent. Add 1–2 “lovability” elements that increase trust/clarity (not random polish).
• Outputs: MLS spec (core flow, must-haves, non-goals, assumptions).
• Checks: The slice is end-to-end (not a partial subsystem) and a user could describe why it’s valuable.

5) Build a cut list with explicit trade-offs

• Inputs: MLS spec + candidate scope items.
• Actions: Create a table of items to keep / cut / defer, with rationale tied to outcome, risk, and appetite. Convert “nice-to-haves” into “later” with a clear trigger for revisiting.
• Outputs: Cut list table + short decision rationale.
• Checks: Every removed item has a reason; non-goals are as clear as goals.

6) Add a validation plan (Wizard-of-Oz / concierge where helpful)

• Inputs: Riskiest assumptions; cut list.
• Actions: Choose the fastest validation method to de-risk the top unknown(s) (manual ops, scripted demo, prototype). Define what data/feedback counts as “validated”.
• Outputs: Validation plan (method, audience, script, success criteria, timeline).
• Checks: The plan can run without building the full system; success criteria are defined before running it.

7) Delivery plan + scope-change guardrails

• Inputs: MLS spec; validation plan; appetite.
• Actions: Break the work into milestones that fit the appetite. Define scope-change rules (how requests are evaluated; what gets traded off; who decides).
• Outputs: Delivery plan + scope-change policy.
• Checks: New scope can only enter by removing or shrinking something else (“trade, don’t add”).

8) Quality gate + finalize

• Inputs: Full draft pack.
• Actions: Run references/CHECKLISTS.md and score with references/RUBRIC.md. Ensure Risks / Open questions / Next steps are present with owners.
• Outputs: Final Scoping & Cutting Pack.
• Checks: A stakeholder can approve the slice async and the team can execute without re-litigating scope.

Quality gate (required)

• Use references/CHECKLISTS.md and references/RUBRIC.md.
• Always include: Risks, Open questions, Next steps.

Examples

prioritizing-roadmap