Liqiongyu Lenny Skills Plus 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

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):

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)

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.

Anti-patterns (common failure modes)

1. Salami-slicing without a hypothesis. Cutting scope purely by effort (drop the hardest things) instead of by learning value. The slice ships but validates nothing because no hypothesis was defined.
2. Phantom MVP. Labeling a barely-functional stub “MVP” without an end-to-end user journey. Users can’t complete the core task, so no signal is generated.
3. Scope freeze theater. Declaring scope frozen while allowing “small” additions through side channels. The cut list exists on paper but is never enforced; the team ships late anyway.
4. Deferral graveyard. Cutting items to a “later” list with no revisit triggers. Deferred work is never re-evaluated and either rots or resurfaces as tech debt surprises.
5. Lovability confusion. Adding polish and delight features (animations, empty-state illustrations) while the core flow is broken. “Lovable” means the slice is coherent and trustworthy, not decorated.

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 (timeline planning): “We’ve already defined the MVP slice; now create a milestone plan with dates and a stakeholder update cadence.” Response: the slice is scoped; use managing-timelines to build the execution timeline and comms cadence.

Boundary example (roadmap prioritization): “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.

Converted and distributed by TomeVault — claim your Tome and manage your conversions.