Back to Details

solution-scoping

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Solution Scoping

解决方案范围界定

Decide what to build first—and what to cut.
决定优先开发内容——以及需要裁剪的内容。

Why This Exists

设计初衷

Forces hard prioritization decisions before development starts, when cutting features is cheap.
在开发开始前就做出艰难的优先级决策，此时裁剪功能的成本最低。

Input Requirements

输入要求

This skill works best with:
  • problem-framing
    output (problem statement, JTBD, assumptions)
  • user-modeling
    output (personas, scenarios, insights)
Can also work with a raw feature list if the user has one.
该技能在搭配以下内容时效果最佳：
  • problem-framing
    输出（问题陈述、JTBD、假设条件）
  • user-modeling
    输出（用户画像、使用场景、洞察结论）
如果用户已有原始功能列表，也可直接使用。

Workflow

工作流程

Step 1: Gather Context

步骤1：收集背景信息

Ingest upstream artifacts or ask:
  • What problem are you solving?
  • Who are you solving it for?
  • What features are you considering?
  • Any constraints—time, budget, skills?
导入上游产出物，或询问以下问题：
  • 你要解决什么问题？
  • 服务的目标用户是谁？
  • 你正在考虑哪些功能？
  • 是否存在任何约束条件，比如时间、预算、技术能力？

Step 2: Generate Feature List

步骤2：生成功能列表

If not provided, brainstorm features based on:
  • User jobs-to-be-done
  • Persona pain points
  • Scenarios from user modeling
  • Competitor features (if known)
Keep it exhaustive initially—we'll cut later.
如果用户未提供功能列表，则基于以下内容进行头脑风暴：
  • 用户待办事项（JTBD）
  • 用户画像中的痛点
  • 用户建模中的使用场景
  • 竞品功能（如有了解）
初始阶段尽量列出所有可能的功能，后续再进行裁剪。

Step 3: Apply Prioritization

步骤3：执行优先级排序

Use one or more frameworks to force ranking:
Impact vs Effort Matrix
  • High impact, low effort → Do first
  • High impact, high effort → Plan carefully
  • Low impact, low effort → Maybe later
  • Low impact, high effort → Cut
MoSCoW Method
  • Must have — Product doesn't work without it
  • Should have — Important but not critical
  • Could have — Nice to have
  • Won't have — Explicitly out
User Value Filter For each feature, ask:
  • Does it solve the core problem?
  • Which persona needs it most?
  • What happens if we ship without it?
使用一种或多种框架进行强制排序：
影响 vs 投入矩阵
  • 高影响、低投入 → 优先开发
  • 高影响、高投入 → 谨慎规划
  • 低影响、低投入 → 后续考虑
  • 低影响、高投入 → 直接裁剪
MoSCoW方法
  • 必须有（Must have）—— 缺少则产品无法正常运作
  • 应该有（Should have）—— 重要但非核心
  • 可以有（Could have）—— 锦上添花
  • 不会有（Won't have）—— 明确排除在外
用户价值筛选 对每个功能，思考以下问题：
  • 它是否解决核心问题？
  • 哪个用户画像最需要它？
  • 如果不开发该功能，会有什么影响？

Step 4: Define MVP Boundary

步骤4：定义MVP边界

Draw a hard line:
  • What's in the first release?
  • What's deferred to v1.1?
  • What's cut entirely?
The MVP should be the smallest thing that tests your core assumption.
明确划分界限：
  • 首个版本包含哪些内容？
  • 哪些内容推迟到v1.1版本？
  • 哪些内容被完全裁剪？
MVP应该是能够验证核心假设的最小可行产品。

Step 5: Validate Cuts

步骤5：验证裁剪项

For each cut, confirm:
  • Can the product still solve the core problem?
  • Will users still get value?
  • Are we cutting for good reasons or fear?
对每个裁剪项，确认以下内容：
  • 产品是否仍能解决核心问题？
  • 用户是否仍能获得价值？
  • 我们裁剪是出于合理原因，还是因为恐惧？

Output Format

输出格式

Automatically save the output to 
design/04-solution-scoping.md
using the Write tool while presenting it to the user.
markdown
undefined
使用Write工具自动将输出内容保存至
design/04-solution-scoping.md
，同时展示给用户。
markdown
undefined

Solution Scoping: [Project Name]

Solution Scoping: [Project Name]

Context

Context

[Brief summary of the problem and target user]
Core assumption to test: [The main bet this MVP validates]
Constraints:
  • Timeline: [If any]
  • Budget: [If any]
  • Skills: [Technical limitations]
  • Other: [Platform, dependencies, etc.]
[Brief summary of the problem and target user]
Core assumption to test: [The main bet this MVP validates]
Constraints:
  • Timeline: [If any]
  • Budget: [If any]
  • Skills: [Technical limitations]
  • Other: [Platform, dependencies, etc.]

Feature Inventory

Feature Inventory

All Considered Features

All Considered Features

#FeatureUser ValueEffortNotes
1[Feature][High/Med/Low][High/Med/Low][Context]
2[Feature][High/Med/Low][High/Med/Low][Context]
3[Feature][High/Med/Low][High/Med/Low][Context]
4[Feature][High/Med/Low][High/Med/Low][Context]
5[Feature][High/Med/Low][High/Med/Low][Context]
#FeatureUser ValueEffortNotes
1[Feature][High/Med/Low][High/Med/Low][Context]
2[Feature][High/Med/Low][High/Med/Low][Context]
3[Feature][High/Med/Low][High/Med/Low][Context]
4[Feature][High/Med/Low][High/Med/Low][Context]
5[Feature][High/Med/Low][High/Med/Low][Context]

Prioritization

Prioritization

Must Have (MVP)

Must Have (MVP)

Product doesn't work without these
FeatureRationale
[Feature][Why it's essential]
[Feature][Why it's essential]
[Feature][Why it's essential]
Product doesn't work without these
FeatureRationale
[Feature][Why it's essential]
[Feature][Why it's essential]
[Feature][Why it's essential]

Should Have (v1.1)

Should Have (v1.1)

Important, but MVP can ship without them
FeatureRationaleDependency
[Feature][Why it's important][What it needs first]
[Feature][Why it's important][What it needs first]
Important, but MVP can ship without them
FeatureRationaleDependency
[Feature][Why it's important][What it needs first]
[Feature][Why it's important][What it needs first]

Could Have (Future)

Could Have (Future)

Nice to have, low priority
FeatureRationale
[Feature][Why it's deferred]
[Feature][Why it's deferred]
Nice to have, low priority
FeatureRationale
[Feature][Why it's deferred]
[Feature][Why it's deferred]

Won't Have (Cut)

Won't Have (Cut)

Explicitly out of scope
FeatureReason for Cut
[Feature][Why we're not building this]
[Feature][Why we're not building this]
Explicitly out of scope
FeatureReason for Cut
[Feature][Why we're not building this]
[Feature][Why we're not building this]

MVP Definition

MVP Definition

What We're Building

What We're Building

[2-3 sentence description of the MVP]
[2-3 sentence description of the MVP]

Core User Flow

Core User Flow

[The one primary flow the MVP enables]
  1. User [action]
  2. System [response]
  3. User [achieves goal]
[The one primary flow the MVP enables]
  1. User [action]
  2. System [response]
  3. User [achieves goal]

What Success Looks Like

What Success Looks Like

  • [Metric or outcome 1]
  • [Metric or outcome 2]
  • [Metric or outcome 1]
  • [Metric or outcome 2]

What We're NOT Building (Yet)

What We're NOT Building (Yet)

  • [Explicit cut 1]
  • [Explicit cut 2]
  • [Explicit cut 3]
  • [Explicit cut 1]
  • [Explicit cut 2]
  • [Explicit cut 3]

Risk Check

Risk Check

Cuts That Might Hurt

Cuts That Might Hurt

CutRiskMitigation
[Feature we cut][What could go wrong][How we'll handle it]
CutRiskMitigation
[Feature we cut][What could go wrong][How we'll handle it]

Scope Creep Triggers

Scope Creep Triggers

Watch out for these during development
  • [Temptation 1]
  • [Temptation 2]
Watch out for these during development
  • [Temptation 1]
  • [Temptation 2]

Open Questions

Open Questions

  • [Decision still needed]
  • [Assumption to validate before committing]
undefined
  • [Decision still needed]
  • [Assumption to validate before committing]
undefined

Prioritization Tips

优先级排序技巧

When everything feels "Must Have":
  • Ask: "Would users pay for this feature alone?"
  • Ask: "Can users accomplish their goal without it?"
  • Ask: "What's the workaround if we don't build it?"
When you can't decide:
  • Default to smaller scope
  • Ship, learn, then add
  • A shipped MVP beats a perfect spec
When stakeholders push back on cuts:
  • Frame as "not yet" not "never"
  • Show the dependency chain
  • Remind: we can add, but we can't un-ship
当所有功能都看似“必须有”时：
  • 问自己：“用户会为单独这个功能付费吗？”
  • 问自己：“没有这个功能，用户还能达成目标吗？”
  • 问自己：“如果不开发这个功能，有什么替代方案？”
当你无法做出决定时：
  • 默认选择更小的范围
  • 先发布，学习反馈，再添加功能
  • 已发布的MVP胜过完美的规格文档
当利益相关者反对裁剪时：
  • 将其表述为“暂不开发”而非“永远不做”
  • 展示依赖关系链
  • 提醒：我们可以后续添加功能，但无法撤回已发布的内容

Anti-Patterns to Avoid

需避免的反模式

  • The Feature Buffet — "Let's just add one more thing"
  • The Safety Blanket — Keeping features because cutting feels scary
  • The Competitor Copy — Including features just because others have them
  • The Premature Scale — Building for 10,000 users when you have 10
  • 功能自助餐——“我们再多加一个功能吧”
  • 安全毯式保留——因为害怕裁剪而保留功能
  • 盲目抄袭竞品——只因竞品有某功能就照搬
  • 过早规模化——只有10个用户却为10000个用户做开发

Handoff

交接环节

After presenting the scoped MVP, ask:
"Ready to generate the PRD with 
/prd-generation
, or want to adjust priorities first?"
Note: File is automatically saved to 
design/04-solution-scoping.md
. This feeds into PRD generation (Must Have → MVP features, Should Have → v1.1 roadmap, Won't Have → Out of Scope).
在展示界定好范围的MVP后，询问：
“是否准备好使用
/prd-generation
生成PRD，还是先调整优先级？”
注意： 文件会自动保存至
design/04-solution-scoping.md
。该文件将用于PRD生成（必须有功能→MVP功能，应该有功能→v1.1路线图，不会有功能→范围外内容）。