scoping-cutting

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 (use writing-specs-designs)
• You’re setting long-term product strategy or vision (use defining-product-vision)
• You already have a scoped slice and need a timeline/milestone plan with stakeholder cadence (use managing-timelines)
• You’re planning the actual launch/release (rollout, rollback, monitoring) for an already-scoped feature (use shipping-products)

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