Scoping & Cutting
Scope
Covers
- 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
When to use
- “Cut scope / descope this feature so we can ship by.”
- “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.”
When NOT to use
- 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 (usewriting-specs-designs) - You’re setting long-term product strategy or vision (use
defining-product-vision)
Inputs
Minimum required
- 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
Missing-info strategy
- 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)
Produce a Scoping & Cutting Pack in Markdown (in-chat; or as files if the user requests):
- Context snapshot (decision, date/appetite, stakeholders/DRI, constraints)
- Outcome + hypothesis (what must be true; what you’ll validate)
- Appetite + success bar (time budget, “done means…”, guardrails)
- Minimum Lovable Slice spec (core flow, must-haves, non-goals)
- Cut list (cut/defer/keep with rationale + impact on risks)
- Validation plan (Wizard-of-Oz/concierge/prototype as needed) + success criteria
- Delivery plan (milestones within appetite + scope-change rules)
- Risks / Open questions / Next steps (always included)
Templates: references/TEMPLATES.md Expanded guidance: references/WORKFLOW.md
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 by with under.”
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
Example 1 (B2B SaaS): “Cut scope for ‘bulk CSV import’ so we can ship a useful version in 4 weeks; include a Wizard-of-Oz validation plan.” Expected: an appetite-based MLS, a cut/defer table, and a validation plan that tests value before building every edge case.
Example 2 (Consumer): “Define a minimum lovable first version of ‘saved searches’ for mobile within a 2-week appetite.” Expected: a coherent end-to-end slice, explicit non-goals, and a scope-change policy to prevent creep.
Boundary example: “Decide what our Q2 roadmap should be across 12 initiatives.” Response: use prioritizing-roadmap first; then apply this skill to right-size the chosen initiative.