prioritization-advisor

目的

通过针对产品阶段、团队背景、决策需求和利益相关者关系提出自适应问题，指导产品经理选择合适的优先级排序框架。借此避免“框架摇摆”（不断切换框架）或套用错误的框架（例如，用 RICE 处理战略性押注，或用 ICE 做数据驱动的决策）。输出内容包括推荐的框架，以及根据你的背景量身定制的实施指导。

这不是评分计算器，而是一个决策指南，帮助你根据具体情况选择优先级排序框架。

核心概念

优先级排序框架概览

常见框架及其适用场景：

评分框架：

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

战略框架：

• Kano 模型——按客户带来的惊喜程度对功能分类（基本型、绩效型、魅力型）
• 机会评分——评估重要性与满意度之间的差距
• Buy-a-Feature——客户预算分配练习
• MoSCoW（必须有、应该有、可以有、不会有）——推动艰难抉择

情境框架：

• 延迟成本——基于紧迫性（适用于有时效性的功能）
• 影响力映射——以目标为导向（将功能与成果关联起来）
• 故事地图——基于用户旅程（叙事流程）

此方法的优势

• **因情境而异：**根据产品阶段、团队成熟度和数据可用性匹配框架
• **避免教条：**没有唯一的“最佳”框架，选择取决于你的具体情况
• **可付诸行动：**提供实施步骤，而不只是框架名称

反模式（本指南不是什么）

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

适用场景

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

不适用场景

• 已有可行的框架时（没坏就别修）
• 一次性决策（框架适用于反复进行的优先级排序）
• 替代战略愿景（框架无法告诉你应该构建什么）

---

引导流程

按照以下互动流程，以引导式对话的方式运行此技能：

• 先用一句话提示用户，然后提供进入方式：引导模式（每次一个问题）、一次性提供背景（用户预先粘贴所有信息）或最佳猜测（仅根据主题继续）。
• 使用通俗语言，每轮只问一个问题；等用户回答后再问下一个。切勿一次提出多个问题。
• 为每个问题标注进度（例如，Context Qx/8 和 Scoring Qx/5）。
• 每个问题都提供编号选项和推荐的默认选项；适用时加入 Other (specify)。
• 妥善处理中断，并允许用户暂停后继续。
• 在决策节点提供编号建议，而不是只给出一个结论。

此文件定义了领域专属的评估内容。如有冲突，请遵循此文件中的领域逻辑。

应用

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

---

问题 1：产品阶段

Agent 提问： “您的产品处于哪个阶段？”

提供 4 个编号选项：

1. 产品与市场契合前 — “正在寻找产品与市场契合点（PMF）；快速试验；不清楚客户想要什么”（不确定性高，需要速度）
2. 初步实现产品与市场契合，正在扩大规模 — “初步实现 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：框架不匹配（Pre-PMF + RICE = 错误选择）

Q1 回答：“尚未达到产品/市场契合度 — 正在寻找 PMF；快速进行实验”

Q2 回答：“团队规模小、资源有限 — 3 名工程师，1 名 PM”

Q3 回答：“想法太多，不清楚该推进哪个”

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

---

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

为什么不选 RICE：

• 你没有使用数据来估算触达人数
• Pre-PMF 阶段需要速度，而不是严谨评分
• 团队规模小，RICE 评分的开销过大

为什么选择 ICE：

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

或者选择价值/投入矩阵：

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

---

常见陷阱

陷阱 1：在不同阶段使用了错误的框架

**症状：**尚未达到 PMF 的初创公司使用包含 10 项标准的加权评分

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

**解决方法：**根据阶段选择框架。Pre-PMF = ICE 或价值/投入。扩展阶段 = RICE。成熟阶段 = 机会评分或 Kano。

---

陷阱 2：框架反复摇摆

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

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

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

---

陷阱 3：把分数奉为金科玉律

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

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

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

---

陷阱 4：PM 独自评分

**症状：**PM 独自为功能评分，然后向团队展示

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

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

---

陷阱 5：完全没有框架

症状：“谁喊得最大声，我们就优先考虑谁”

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

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

---

参考资料

相关技能

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

外部框架

• Intercom，《RICE 优先级排序》（2016）— RICE 框架的起源
• Sean McBride，《ICE 评分》（2012）— 轻量级优先级排序
• Luke Hohmann，《创新游戏》（2006）— Buy-a-Feature 和其他协作方法
• Noriaki Kano，《Kano 模型》（1984）— 客户满意度框架 **依赖项：**无（独立使用，但可为路线图和待办事项决策提供依据）