prioritization-advisor

用途

通过针对产品阶段、团队背景、决策需求和利益相关方关系提出自适应问题，指导产品经理选择合适的优先级排序框架。借此避免“框架摇摆”（不断切换框架）或误用框架（例如，针对战略性押注使用 RICE，或针对数据驱动决策使用 ICE）。输出会根据你的具体情况推荐框架，并提供实施指导。

这不是评分计算器，而是一个决策指南，可将优先级排序框架与你的具体情况相匹配。

输入

最适合提供的信息： 你要对什么事项排定优先级，以及为什么现在要处理（迭代规划、路线图、利益相关方争论）。 也有帮助的信息： 产品阶段、团队规模、数据可用性，以及你试过但效果不佳的框架。

随调用一并提供的任何内容——技能名称后面的文本、粘贴的上下文，或附加的 ARGUMENTS: 行——都视为已给出的答案。使用这些信息，并跳过已涵盖的问题；不要重复询问。

空手而来也没关系。 顾问会先询问你的产品阶段，以及你需要这个框架帮助做出的决策。

调用示例： 帮我选择一个框架：种子阶段的 B2B 初创公司，40 项待办事项，没有使用数据，有一位要求强烈的企业潜在客户。

核心概念

优先级排序框架概览

常见框架及其适用场景：

评分框架：

• RICE（触达范围、影响力、信心、投入）——数据驱动，需要指标
• ICE（影响力、信心、易行性）——轻量级，基于直觉评分
• 价值与投入（2x2 矩阵）——快速见效的事项与战略性押注
• 加权评分——结合利益相关方意见，采用自定义标准

战略框架：

• Kano 模型——按客户满意度影响对功能分类（基本型、期望型、魅力型）
• 机会评分——评估重要性与满意度之间的差距
• 买个功能——客户预算分配练习
• Moscow（必须做、应该做、可以做、不做）——推动艰难取舍的机制

情境框架：

• 延迟成本——基于紧迫性（时间敏感型功能）
• 影响力映射——目标驱动（将功能与结果关联）
• 故事地图——基于用户旅程（叙事流程）

为什么有效

• 考虑上下文： 根据产品阶段、团队成熟度和数据可用性匹配框架
• 不拘泥于教条： 没有唯一的“最佳”框架——要视具体情况而定
• 可付诸行动： 提供实施步骤，而不只是列出框架名称

反模式（本工具不是什么）

• 不是通用排名： 框架没有“好坏”之分——它们适用于不同情境
• 不是战略的替代品： 框架用于执行战略，而不是制定战略
• 不是一劳永逸： 随着产品成熟，重新评估框架

适用场景

• 首次选择优先级排序框架
• 切换框架（当前框架不起作用）
• 让利益相关方在优先级排序流程上达成一致
• 帮助新任 PM 熟悉团队实践

不适用场景

• 已有行之有效的框架时（不要修复没坏的东西）
• 一次性决策（框架适用于重复性的优先级排序）
• 作为战略愿景的替代品（框架无法告诉你应该构建什么）

---

引导流程的权威指南

将 workshop-facilitation 作为本技能的默认交互协议。

其中定义了：

• 会话提示与进入模式（引导式、上下文倾倒、最佳猜测）
• 每轮一个问题，并使用通俗易懂的提示
• 进度标签（例如 Context Qx/8 和 Scoring Qx/5）
• 中断处理以及暂停／恢复行为
• 决策节点处提供编号建议
• 常规问题提供编号快速选择选项（适用时包含 Other (specify)）

本文件定义了领域特定的评估内容。如有冲突，以本文件的领域逻辑为准。

应用场景

此交互式技能会提出最多 4 个自适应问题，每一步提供3-4 个编号选项。

---

问题 1：产品阶段

Agent 提问： “你的产品处于什么阶段？”

提供 4 个编号选项：

1. 尚未达到产品市场契合度 — “正在寻找产品市场契合度（PMF）；快速试验；不清楚客户想要什么”（不确定性高，需要速度）
2. 初步达到 PMF，正在扩张 — “已初步找到 PMF；快速增长；增加功能以留住客户并扩大业务”（不确定性中等，需要平衡速度与质量）
3. 成熟产品，正在优化 — “市场地位稳固；进行渐进式改进；以质量和功能竞争”（不确定性低，基于数据做决策）
4. 多款产品/平台 — “产品组合丰富；产品间存在依赖关系；利益相关者需求复杂”（协调复杂）

或者描述你的产品阶段（新想法、增长模式、已成熟等）。

用户回复： [选择或自定义]

---

问题 2：团队背景

Agent 提问： “你的团队和利益相关者环境是什么样的？”

提供 4 个编号选项：

1. 小团队，资源有限 — “3-5 名工程师、1 名产品经理，需要严格聚焦”（需要简单、快速的框架）
2. 跨职能团队，目标一致 — “产品、设计、工程团队目标一致；目标明确；协作良好”（可以使用数据驱动框架）
3. 多方利益相关者，目标不一致 — “高管、销售、客户各有看法；需要透明的流程”（需要建立共识的框架）
4. 大型组织，依赖关系复杂 — “多个团队、共享路线图、跨团队依赖关系”（需要协调框架）

或者描述你的团队/利益相关者背景。

用户回复： [选择或自定义]

---

问题 3：决策需求

Agent 提问： “你希望通过优先级排序解决的主要挑战是什么？”

提供 4 个编号选项：

1. 想法太多，不清楚该选择哪些 — “待办列表有 100+ 项；需要筛选出前 10 项”（需要筛选框架）
2. 利益相关者对优先级意见不一 — “销售想要功能，高管想要战略举措，工程团队想处理技术债务”（需要协调一致的框架）
3. 决策缺乏数据驱动 — “凭直觉排优先级；希望建立基于指标的流程”（需要评分框架）
4. 难以权衡战略举措与快速见效的项目 — “需要平衡长期愿景与短期客户需求”（需要价值/工作量框架）

或者描述你的具体挑战。

用户回复： [选择或自定义]

---

问题 4：数据可用性

Agent 提问： “你有多少数据可以用于制定优先级？”

提供 3 个编号选项：

1. 数据很少 — “新产品，没有使用指标，可供调研的客户也很少”（基于直觉的框架）
2. 有一些数据 — “有基础分析数据和客户反馈，但没有严谨的数据收集”（轻量级评分框架）
3. 数据丰富 — “有使用指标、A/B 测试、客户调研和明确的成功指标”（数据驱动框架）

或者描述你的数据情况。

用户回复： [选择或自定义]

---

输出：推荐优先级排序框架

收集完回复后，Agent 会推荐一个框架：

# Prioritization Framework Recommendation

**Based on your context:**
- **Product Stage:** [From Q1]
- **Team Context:** [From Q2]
- **Decision-Making Need:** [From Q3]
- **Data Availability:** [From Q4]

---

## Recommended Framework: [Framework Name]

**Why this framework fits:**
- [Rationale 1 based on Q1-Q4]
- [Rationale 2]
- [Rationale 3]

**When to use it:**
- [Context where this framework excels]

**When NOT to use it:**
- [Limitations or contexts where it fails]

---

## How to Implement

### Step 1: [First implementation step]
- [Detailed guidance]
- [Example: "Define scoring criteria: Reach, Impact, Confidence, Effort"]

### Step 2: [Second step]
- [Detailed guidance]
- [Example: "Score each feature on 1-10 scale"]

### Step 3: [Third step]
- [Detailed guidance]
- [Example: "Calculate RICE score: (Reach × Impact × Confidence) / Effort"]

### Step 4: [Fourth step]
- [Detailed guidance]
- [Example: "Rank by score; review top 10 with stakeholders"]

---

## Example Scoring Template

[Provide a concrete example of how to use the framework]

**Example (if RICE):**

| Feature | Reach (users/month) | Impact (1-3) | Confidence (%) | Effort (person-months) | RICE Score |
|---------|---------------------|--------------|----------------|------------------------|------------|
| Feature A | 10,000 | 3 (massive) | 80% | 2 | 12,000 |
| Feature B | 5,000 | 2 (high) | 70% | 1 | 7,000 |
| Feature C | 2,000 | 1 (medium) | 50% | 0.5 | 2,000 |

**Priority:** Feature A > Feature B > Feature C

---

## Alternative Framework (Second Choice)

**If the recommended framework doesn't fit, consider:** [Alternative framework name]

**Why this might work:**
- [Rationale]

**Tradeoffs:**
- [What you gain vs. what you lose]

---

## Common Pitfalls with This Framework

1. **[Pitfall 1]** — [Description and how to avoid]
2. **[Pitfall 2]** — [Description and how to avoid]
3. **[Pitfall 3]** — [Description and how to avoid]

---

## Reassess When

- Product stage changes (e.g., PMF → scaling)
- Team grows or reorganizes
- Stakeholder dynamics shift
- Current framework feels broken (e.g., too slow, ignoring important factors)

---

**Would you like implementation templates or examples for this framework?**

---

示例

示例 1：框架匹配良好（早期 PMF、RICE）

Q1 回答：“早期 PMF，正在扩张——已找到初步的 PMF；增长迅速；正在添加功能以留住用户并扩大用户群”

Q2 回答：“跨职能团队，目标一致——产品、设计、工程团队目标一致；目标明确”

Q3 回答：“缺乏数据驱动的决策——依靠直觉确定优先级；希望采用基于指标的流程”

Q4 回答：“有一些数据——有基础分析和客户反馈，但没有严格的数据收集流程”

---

推荐框架：RICE（触达范围、影响力、信心、投入）

适用原因：

• 你有一些数据（分析、客户反馈），可用于估算触达范围和影响力
• 跨职能团队目标一致，因此可以就评分标准达成共识
• 从依靠直觉转向数据驱动 = RICE 能提供结构化方法，同时又不会过于复杂
• 处于早期 PMF 阶段 = 需要快速行动，同时也需要优先开发对留存和用户扩展影响大的功能

适用场景：

• 按季度或按月规划路线图
• 待办事项超过 20-30 项时
• 利益相关者对优先级存在争议时

不适用场景：

• 制定跨多个季度的战略性决策时（RICE 倾向于优先选择渐进式成果）
• 缺少基础指标时（触达范围需要使用数据）
• 只需针对单个功能做决策时（杀鸡用牛刀）

---

实施步骤：

第 1 步：定义评分标准

• **触达范围：**这项功能每月/每季度会影响多少用户？
• **影响力：**这项功能能在多大程度上改善用户体验？（1 = 影响最小，2 = 影响较大，3 = 影响巨大）
• **信心：**你对触达范围/影响力估算有多大把握？（50% = 数据较少，80% = 数据充分，100% = 确定）
• **投入：**开发需要多少人月？（包括设计、工程、QA）

第 2 步：为每项功能评分

• 使用电子表格或 Airtable
• 邀请产品经理、设计和工程团队共同评分（而不只是产品经理独自评分）
• 如实评估信心（不要虚报分数）

第 3 步：计算 RICE 分数

• 公式：(Reach × Impact × Confidence) / Effort
• 分数越高 = 优先级越高

第 4 步：审核并调整

• 按 RICE 分数排序
• 与利益相关者审核排名前 10-20 的项目
• 根据战略优先事项进行调整（RICE 无法涵盖所有因素）

---

评分示例：

功能	触达范围	影响力	信心	投入	RICE 分数
邮件提醒	5,000	2	70%	1	7,000
移动应用	10,000	3	60%	6	3,000
深色模式	8,000	1	90%	0.5	14,400

**优先级：**深色模式 > 邮件提醒 > 移动应用（尽管移动应用的触达范围/影响力较高，但投入过大）

---

替代框架：ICE（影响力、信心、易实施度）

可能适用的原因：

• 比 RICE 更简单（无需计算触达范围）
• 评分更快（适合需要快速决策的情况）

权衡：

• 数据驱动程度较低（没有触达范围指标 = 无法比较影响不同用户群的功能）
• 主观性更强（影响力/易实施度凭直觉判断，而非依据指标）

---

常见误区：

1. 过度看重投入 — 不要仅仅因为难题得分低就回避它们。有些战略性投入需要较高成本。
2. 夸大信心 — 如实评估。数据有限时，50% 的信心也可以接受。
3. 忽视战略 — RICE 无法体现战略重要性。应根据愿景/目标进行调整。

---

示例 2：框架与阶段不匹配（产品市场契合前 + RICE = 错误选择）

Q1 回答：“尚未达到产品市场契合——正在寻找产品市场契合；快速开展实验”

Q2 回答：“团队规模小、资源有限——3 名工程师、1 名产品经理”

Q3 回答：“想法太多，不确定该推进哪一个”

Q4 回答：“数据极少——新产品，没有使用指标”

---

推荐框架：ICE（影响力、信心、易行性）或价值/投入矩阵

为什么不选 RICE：

• 没有使用数据，无法估算覆盖人数
• 产品市场契合前需要的是速度，而非严格评分
• 团队规模小，RICE 评分的额外开销太大

为什么改用 ICE：

• 轻量级的直觉检验框架
• 30 分钟内可为 20 个想法评分
• 适合快速实验阶段

或者使用价值/投入矩阵：

• 可视化的 2x2 矩阵（高价值/低投入 = 快速见效）
• 比 ICE 还快
• 有利于利益相关者达成共识（直观易懂）

---

常见陷阱

陷阱 1：所用框架不适合当前阶段

**症状：**产品市场契合前的初创公司使用包含 10 项标准的加权评分

**后果：**额外开销拖慢速度。你需要的是实验，而非严格评分。

**解决方法：**让框架与阶段匹配。产品市场契合前 = ICE 或价值/投入。规模化阶段 = RICE。成熟阶段 = 机会评分或 Kano。

---

陷阱 2：框架反复摇摆

**症状：**每个季度都更换框架

**后果：**团队困惑、时间浪费、缺乏一致性。

**解决方法：**坚持使用一个框架 6-12 个月。只有阶段或背景发生变化时才重新评估。

---

陷阱 3：把分数奉为圭臬

症状：“功能 A 得分 8,000，功能 B 得分 7,999，所以选 A”

**后果：**忽视战略背景、判断力和愿景。

**解决方法：**将框架作为参考，而非自动决策工具。必要时，产品经理的判断优先于分数。

---

陷阱 4：产品经理独自评分

**症状：**产品经理独自为功能评分，再向团队展示

**后果：**缺乏认同，工程和设计团队不信任这些分数。

**解决方法：**开展协作评分会议。产品经理、设计和工程团队共同评分。

---

陷阱 5：完全没有框架

症状：“谁喊得最响，我们就优先做谁的需求”

**后果：**获胜的是 HiPPO（薪酬最高者的意见），而非数据或战略。

**解决方法：**选用任何一种框架。即使结构不完美，也胜过一团混乱。

---

参考资料

相关技能

• user-story.md — 优先级已确定的功能可转化为用户故事
• epic-hypothesis.md — 通过实验验证优先级已确定的史诗任务
• recommendation-canvas.md — 业务成果为优先级排序提供依据

外部框架

• Intercom，《RICE 优先级排序》（2016）——RICE 框架的起源
• Sean McBride，《ICE 评分》（2012）——轻量级优先级排序
• Luke Hohmann，《创新游戏》（2006）——“购买功能”等协作方法
• Noriaki Kano，《Kano 模型》（1984）——客户满意度框架

Dean 的作品

• [如果 Dean 有优先级排序相关资源，请在此添加链接]

---

**技能类型：**交互式 建议文件名：prioritization-advisor.md 建议位置：/skills/interactive/ **依赖项：**无（独立使用，但可为路线图和待办事项决策提供依据）