名称: 优先级排序顾问 描述: 通过询问自适应的问题关于产品阶段、团队上下文、决策需求和利益相关者动态，指导产品经理选择正确的优先级排序框架。使用此来避免“框架反复切换”（频繁更换框架）或应用错误框架（例如，使用RICE进行战略性赌注或ICE进行数据驱动决策）。输出一个推荐的框架，带有根据您上下文定制的实施指导。 类型: 交互式
目的
指导产品经理选择正确的优先级排序框架，通过询问自适应的问题关于产品阶段、团队上下文、决策需求和利益相关者动态。使用此来避免“框架反复切换”或应用错误框架。输出一个推荐的框架，带有实施指导，根据您的上下文定制。
这不是一个评分计算器——它是一个决策指南，将优先级排序框架匹配到您的具体情况。
关键概念
优先级排序框架景观
常见框架及其使用时机：
评分框架：
- RICE（覆盖范围、影响、信心、努力）——数据驱动，需要指标
- ICE（影响、信心、容易度）——轻量级，直觉评分
- 价值 vs. 努力（2x2矩阵）——快速获胜 vs. 战略性赌注
- 加权评分——自定义标准与利益相关者输入
战略框架：
- Kano模型——通过客户愉悦分类功能（基本、性能、愉悦）
- 机会评分——评估重要性 vs. 满意度差距
- 购买功能——客户预算分配练习
- Moscow（必须、应该、可以、不会）——强制选择的函数
上下文框架：
- 延迟成本——基于紧急性（时间敏感功能）
- 影响映射——目标驱动（将功能绑定到结果）
- 故事映射——用户旅程为基础（叙事流程）
为什么这有效
- 上下文感知： 将框架匹配到产品阶段、团队成熟度、数据可用性
- 反教条： 没有单一的“最佳”框架——取决于您的情况
- 可操作： 提供实施步骤，不仅仅是框架名称
反模式（这不是什么）
- 不是通用排名： 框架不是“更好”或“更差”——它们适合不同上下文
- 不是策略替代： 框架执行策略；它们不创建策略
- 不是设定后忘记： 随着产品成熟，重新评估框架
何时使用此
- 第一次选择优先级排序框架
- 更换框架（当前框架不工作）
- 对齐利益相关者关于优先级排序过程
- 将新PM引入团队实践
何时不使用此
- 当您已经有工作框架时（不要修复未破坏的东西）
- 用于一次性决策（框架用于重复优先级排序）
- 作为战略愿景替代（框架无法告诉您构建什么）
促进源真相
使用工作坊促进作为此技能的默认交互协议。
它定义：
- 会话提醒 + 进入模式（引导式、上下文转储、最佳猜测）
- 一个问题的回合，带有普通语言提示
- 进度标签（例如，上下文 Qx/8 和评分 Qx/5）
- 中断处理和暂停/恢复行为
- 在决策点编号推荐
- 常规问题快速选择编号响应选项（当有用时包括
其他（指定））
此文件定义领域特定评估内容。如果有冲突，遵循此文件的领域逻辑。
应用
此交互技能询问最多4个自适应问题，在每一步提供3-4个枚举选项。
问题1：产品阶段
代理问： “您的产品处于什么阶段？”
提供4个枚举选项：
- 预产品/市场适应 —— “搜索PMF；快速实验；不清楚客户想要什么”（高不确定性，需要速度）
- 早期PMF，扩展 —— “找到初步PMF；快速增长；添加功能以保留/扩展”（中等不确定性，平衡速度 + 质量）
- 成熟产品，优化 —— “确立市场；增量改进；在质量/功能上竞争”（低不确定性，数据驱动决策）
- 多产品/平台 —— “产品组合；跨产品依赖；复杂利益相关者需求”（协调复杂性）
或描述您的产品阶段（新想法、增长模式、已确立等）。
用户响应： [选择或自定义]
问题2：团队上下文
代理问： “您的团队和利益相关者环境如何？”
提供4个枚举选项：
- 小团队，有限资源 —— “3-5名工程师，1名PM，需要无情聚焦”（需要简单、快速框架）
- 跨职能团队，对齐 —— “产品、设计、工程对齐；明确目标；良好协作”（可以使用数据驱动框架）
- 多利益相关者，不对齐 —— “高管、销售、客户都有意见；需要透明过程”（需要共识构建框架）
- 大型组织，复杂依赖 —— “多个团队、共享路线图、跨团队依赖”（需要协调框架）
或描述您的团队/利益相关者上下文。
用户响应： [选择或自定义]
问题3：决策需求
代理问： “您希望通过优先级排序解决的主要挑战是什么？”
提供4个枚举选项：
- 太多想法，不清楚追求哪个 —— “积压100+项；需要缩小到前10”（需要过滤框架）
- 利益相关者不同意优先级 —— “销售想要功能，高管想要战略性赌注，工程想要技术债务”（需要对齐框架）
- 缺乏数据驱动决策 —— “凭直觉优先；想要基于指标的进程”（需要评分框架）
- 战略性赌注与快速获胜之间的硬权衡 —— “平衡长期愿景与短期客户需求”（需要价值/努力框架）
或描述您的具体挑战。
用户响应： [选择或自定义]
问题4：数据可用性
代理问： “您有多少数据来通知优先级排序？”
提供3个枚举选项：
- 最小数据 —— “新产品，没有使用指标，少有客户调查”（基于直觉框架）
- 一些数据 —— “基本分析、客户反馈，但没有严格数据收集”（轻量级评分框架）
- 丰富数据 —— “使用指标、A/B测试、客户调查、明确成功指标”（数据驱动框架）
或描述您的数据情况。
用户响应： [选择或自定义]
输出：推荐优先级排序框架
收集响应后，代理推荐一个框架：
# 优先级排序框架推荐
**基于您的上下文：**
- **产品阶段：** [来自Q1]
- **团队上下文：** [来自Q2]
- **决策需求：** [来自Q3]
- **数据可用性：** [来自Q4]
---
## 推荐框架： [框架名称]
**为什么此框架适合：**
- [基于Q1-Q4的合理性1]
- [合理性2]
- [合理性3]
**何时使用它：**
- [此框架擅长的上下文]
**何时不使用它：**
- [限制或它失败的上下文]
---
## 如何实施
### 步骤1： [第一实施步骤]
- [详细指导]
- [示例：“定义评分标准：覆盖范围、影响、信心、努力”]
### 步骤2： [第二步骤]
- [详细指导]
- [示例：“为每个功能在1-10尺度上评分”]
### 步骤3： [第三步骤]
- [详细指导]
- [示例：“计算RICE分数：(覆盖范围 × 影响 × 信心) / 努力”]
### 步骤4： [第四步骤]
- [详细指导]
- [示例：“按分数排名；与利益相关者审查前10”]
---
## 示例评分模板
[提供一个如何使用框架的具体示例]
**示例（如果是RICE）：**
| 功能 | 覆盖范围（用户/月） | 影响（1-3） | 信心（%） | 努力（人月） | RICE分数 |
|---------|---------------------|--------------|----------------|------------------------|------------|
| 功能A | 10,000 | 3（巨大） | 80% | 2 | 12,000 |
| 功能B | 5,000 | 2（高） | 70% | 1 | 7,000 |
| 功能C | 2,000 | 1（中等） | 50% | 0.5 | 2,000 |
**优先级：** 功能A > 功能B > 功能C
---
## 替代框架（第二选择）
**如果推荐框架不适合，考虑：** [替代框架名称]
**为什么这可能工作：**
- [合理性]
**权衡：**
- [您获得什么 vs. 失去什么]
---
## 常见陷阱与此框架
1. **[陷阱1]** — [描述和如何避免]
2. **[陷阱2]** — [描述和如何避免]
3. **[陷阱3]** — [描述和如何避免]
---
## 重新评估时机
- 产品阶段变化（例如，PMF → 扩展）
- 团队增长或重组
- 利益相关者动态变化
- 当前框架感觉破裂（例如，太慢，忽略重要因素）
---
**您想要此框架的实施模板或示例吗？**
示例
示例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
- 涉及PM、设计、工程在评分中（不仅仅是PM单独）
- 诚实关于信心（不要夸大分数）
步骤3：计算RICE分数
- 公式：
(覆盖范围 × 影响 × 信心) / 努力 - 更高分数 = 更高优先级
步骤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更简单（无覆盖范围计算）
- 更快评分（如果您需要快速决策）
权衡：
- 较少数据驱动（无覆盖范围指标 = 无法比较影响不同用户群的功能）
- 更主观（影响/容易度是直觉，非指标）
常见陷阱：
- 过高权重努力 —— 不要仅仅因为分数低而避免困难问题。一些战略性赌注需要高努力。
- 夸大信心 —— 诚实。50%信心是可以的如果数据稀缺。
- 忽略策略 —— RICE不捕获战略重要性。为愿景/目标调整。
示例2：坏框架匹配（预PMF + RICE = 错误适合）
Q1响应： “预产品/市场适应 —— 搜索PMF；快速实验”
Q2响应： “小团队，有限资源 —— 3名工程师，1名PM”
Q3响应： “太多想法，不清楚追求哪个”
Q4响应： “最小数据 —— 新产品，没有使用指标”
推荐框架： ICE（影响、信心、容易度）或价值/努力矩阵
为什么不是RICE：
- 您没有使用数据来估计覆盖范围
- 预PMF = 您需要速度，不是严格评分
- 小团队 = RICE评分开销太重
为什么ICE代替：
- 轻量级，直觉检查框架
- 可以在30分钟内评分20个想法
- 适合快速实验阶段
或价值/努力矩阵：
- 视觉2x2矩阵（高价值/低努力 = 快速获胜）
- 甚至比ICE更快
- 适合利益相关者对齐（视觉、直观）
常见陷阱
陷阱1：使用错误框架为您的阶段
症状： 预PMF创业公司使用加权评分与10个标准
后果： 开销杀死速度。您需要实验，不是严格评分。
修复： 匹配框架到阶段。预PMF = ICE或价值/努力。扩展 = RICE。成熟 = 机会评分或Kano。
陷阱2：框架反复切换
症状： 每季度更换框架
后果： 团队混淆、失去时间、无一致性。
修复： 坚持一个框架6-12个月。仅在阶段/上下文变化时重新评估。
陷阱3：将分数视为福音
症状： “功能A评分8,000，功能B评分7,999，所以A赢”
后果： 忽略战略上下文、判断和愿景。
修复： 使用框架作为输入，不是自动化。PM判断在需要时覆盖分数。
陷阱4：单独PM评分
症状： PM单独评分功能，呈现给团队
后果： 缺乏买进、工程/设计不相信分数。
修复： 协作评分会话。PM、设计、工程一起评分。
陷阱5：无框架
症状： “我们优先通过谁喊得最大声”
后果： HiPPO（最高薪人员意见）赢，不是数据或策略。
修复： 选择任何框架。即使不完美结构击败混乱。
参考
相关技能
用户故事.md—— 优先级功能成为用户故事史诗假设.md—— 优先级史诗通过实验验证推荐画布.md—— 业务结果通知优先级
外部框架
- Intercom, RICE优先级排序 (2016) —— RICE框架起源
- Sean McBride, ICE评分 (2012) —— 轻量级优先级排序
- Luke Hohmann, 创新游戏 (2006) —— 购买功能和其他协作方法
- Noriaki Kano, Kano模型 (1984) —— 客户满意度框架
Dean的工作
- [如果Dean有优先级排序资源，链接这里]
技能类型： 交互式
建议文件名： prioritization-advisor.md
建议放置： /skills/interactive/
依赖： 无（独立，但通知路线图和积压决策）