Back to Details

scoping-cutting

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

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 <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.”
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
    )
涵盖内容
  • 将模糊的项目转化为符合固定时间预算（即“预期时间”）的可交付版本
  • 创建包含明确取舍依据的裁剪列表（需舍弃/延期的内容）
  • 将MVP定义为一个假设验证测试（明确验证目标，而非单纯“缩小版”）
  • 选择最小可喜爱交付版本（Minimum Lovable Slice）——既具备可行性又能引发用户情感共鸣，而非“勉强可用”的版本
  • 采用Wizard-of-Oz / 礼宾式方法，在实现全自动化前验证价值
  • 通过明确的非目标+变更控制机制防止范围蔓延
适用场景
  • “裁剪这个功能的范围，以便我们能在<日期>前交付。”
  • “为这个项目定义MVP（我们要验证什么假设？）。”
  • “我们有2–6周时间；能交付哪些仍有价值的内容？”
  • “范围蔓延严重影响我们的工作，明确哪些内容在范围内/外，以及变更流程。”
  • “我们需要一个最小可喜爱版本，而非妥协后的半成品。”
不适用场景
  • 你尚未明确要解决的问题（使用
    problem-definition
    ）
  • 你需要在多个竞争项目中做选择（使用
    prioritizing-roadmap
    ）
  • 你需要一份可用于决策的PRD（产品需求文档）（使用
    writing-prds
    ）或可用于开发的设计/技术规格文档（使用
    writing-specs-designs
    ）
  • 你正在制定长期产品战略或愿景（使用
    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.
最低必要输入
  • 项目/功能信息，以及核心决策（交付/延期/终止）+ 目标日期或时间预算
  • 目标用户/用户群体 + 你希望优化的核心用户旅程
  • 成功指标 + 2–5个管控指标（信任度、质量、成本、延迟、支持负载）
  • 约束条件与不可协商项（法律/隐私、平台、依赖项、团队规模）
  • 候选范围项（可用项目符号列出）+ 已知未知项
缺失信息处理策略
  • 从references/INTAKE.md中最多提出5个问题。
  • 如果无法获取答案，基于明确假设推进，并列出会影响裁剪决策的待解决问题。

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
生成一份Markdown格式的范围规划与裁剪包（可在对话中直接提供；若用户要求，可作为文件输出）：
  1. 上下文快照（核心决策、日期/预期时间、利益相关人/负责人、约束条件）
  2. 成果目标+假设（必须成立的前提；需验证的内容）
  3. 预期时间+成功标准（时间预算、“完成”的定义、管控指标）
  4. 最小可喜爱交付版本规格（核心流程、必备项、非目标）
  5. 裁剪列表（保留/裁剪/延期的内容，附带与成果、风险、预期时间相关的依据）
  6. 验证计划（按需采用Wizard-of-Oz/礼宾式/原型法）+ 成功标准
  7. 交付计划（符合预期时间的里程碑 + 范围变更规则）
  8. 风险/待解决问题/下一步行动（必须包含）
模板：references/TEMPLATES.md
扩展指南：references/WORKFLOW.md

Workflow (8 steps)

工作流程（8步）

1) Intake + decision framing

1) 需求收集+决策框架搭建

  • 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>.”
  • 输入：用户请求；references/INTAKE.md
  • 行动：明确核心决策、日期/预期时间、负责人、约束条件，以及“交付”的定义（交付渠道、使用人群）
  • 输出：上下文快照
  • 校验标准：能够清晰表述：“我们决定在<日期>前，由<团队>在<约束条件>下交付<版本>。”

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

2) 定义成果目标与假设（MVP=验证测试）

  • 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?”
  • 输入：上下文快照；现有证据/风险
  • 行动：以用户视角撰写成果目标；定义核心假设（2–3个）。选择成功指标+管控指标。
  • 输出：成果目标+假设部分；指标/管控指标
  • 校验标准：能够回答：“通过交付这个版本，我们将了解/验证什么？”

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

3) 设置预期时间（时间作为预算）+不可协商项

  • 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.
  • 输入：目标日期/时间框；约束条件；团队产能
  • 行动：设定硬性时间预算（例如2/4/6周）。列出不可协商项（政策、隐私、可靠性、设计约束）。
  • 输出：预期时间+约束条件部分
  • 校验标准：预期时间明确且已达成共识；范围是变量，而非截止日期。

4) Design the Minimum Lovable Slice (MLS)

4) 设计最小可喜爱交付版本（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.
  • 输入：成果目标+约束条件；候选范围项
  • 行动：定义能够传递核心价值且逻辑连贯的最小端到端流程。添加1–2个“可喜爱性”元素以提升信任度/清晰度（而非无意义的优化）。
  • 输出：最小可喜爱交付版本规格（核心流程、必备项、非目标、假设）
  • 校验标准：该版本是端到端的（而非部分子系统），且用户能够说明其价值所在。

5) Build a cut list with explicit trade-offs

5) 构建带有明确取舍的裁剪列表

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

6) 添加验证计划（按需采用Wizard-of-Oz/礼宾式方法）

  • 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

7) 交付计划+范围变更防护规则

  • 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

8) 质量校验+最终定稿

  • 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.
  • 输入：完整的草稿包
  • 行动：使用references/CHECKLISTS.md进行检查，并通过references/RUBRIC.md进行评分。确保风险/待解决问题/下一步行动部分已明确负责人。
  • 输出：最终版范围规划与裁剪包
  • 校验标准：利益相关人能够异步批准该版本，且团队无需重新讨论范围即可执行。

Quality gate (required)

质量校验（必填）

  • Use references/CHECKLISTS.md and references/RUBRIC.md.
  • Always include: Risks, Open questions, Next steps.
  • 使用references/CHECKLISTS.md和references/RUBRIC.md。
  • 必须包含：风险、待解决问题、下一步行动。

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.
示例1（B2B SaaS）：“为‘批量CSV导入’功能裁剪范围，以便我们能在4周内交付可用版本；需包含Wizard-of-Oz验证计划。”
预期输出：一份基于预期时间的最小可喜爱交付版本、裁剪/延期表格，以及一份在构建所有边缘案例前验证价值的验证计划。
示例2（消费级产品）：“在2周的预期时间内，定义移动端‘保存搜索’功能的首个最小可喜爱版本。”
预期输出：一个逻辑连贯的端到端版本、明确的非目标，以及防止范围蔓延的范围变更政策。
边界示例：“确定我们12个项目的Q2路线图内容。”
回应：先使用
prioritizing-roadmap
，再应用本方法调整选定项目的范围大小。