1.1 RICE模型：用数据为需求排序

产品经理每天面对大量需求：功能迭代、体验优化、技术债、运营工具……哪个先做？拍脑袋决策往往导致资源浪费。RICE 模型提供了一个量化框架，将优先级从“谁嗓门大”变成“哪个分数高”。

1.1.1 四要素定义与计算公式

1.1.2 业务问题：为什么需要 RICE？

你负责一款社交产品的“评论功能优化”。运营提出“增加评论表情包”、用户研究员反馈“评论排序不合理”、技术团队提议“重构评论数据存储”。三个需求同时排入 backlog，如果凭直觉决策，结果往往是——

• 塞罗效应：谁的汇报能力强、谁的情绪最迫切，谁的需求先上。
• 资源黑洞：一个“感觉很重要”的大需求做完，发现只影响5%的用户。
• 无法复盘：没有量化依据，“为什么做这个”变成死无对证。

RICE 提供了一套可复现的决策逻辑：同一个需求，不同 PM 评估出的分数虽有差异，但对话从“我觉得”变成了“你的 Reach 数据从哪来？”。

1.1.3 用户场景：从访谈数据到量化评估

以“评论表情包”需求为例。通过用户访谈，你发现：

• 用户A（重度评论用户）：“每次打字回复太慢，有表情包我能多回5条。”
• 用户B（偶尔评论用户）：“看到别人用表情包，我也更想评论了。”

这意味着：Reach 覆盖所有评论用户（假设月活跃评论用户 80 万），Impact 可能提升评论转化率 15%（参考其他产品的经验值）。但 Confidence 只有 50%，因为样本量小、没有 AB 测试数据。Effort 估算：前端 + 后端 + 设计 ≈ 1.5 人·月。

将定性访谈转化为定量输入，是 RICE 模型的第一步——需求拆解。

1.1.4 方案表达：RICE 全景流程图

下面的 SVG 展示了 RICE 四要素如何汇聚为优先级分数，以及 PM 在每个环节应交付的关键输出。

1.1.5 本章交付物模板

第 1 章结束前，你应产出以下交付物雏形（后续章节会逐步完善）：

📋 需求 RICE 评估卡片（模板）
━━━━━━━━━━━━━━━━━━━━━━━
需求名称：评论表情包功能  
产品经理：张三  
日期：2025-07-14  

| 要素       | 评分 | 数据来源/依据                     |
|------------|------|-----------------------------------|
| Reach      | 80万 | 月活跃评论用户数（MAU评论模块）   |
| Impact     | 0.5  | 参考竞品评论转化提升15%（0.5倍）  |
| Confidence | 50%  | 仅用户访谈，无AB测试数据           |
| Effort     | 1.5  | 前端0.8 + 后端0.5 + 设计0.2人·月 |

RICE 分数 = (800,000 × 0.5 × 50%) / 1.5 ≈ 133,333  
优先级：P1（待与积分系统需求对比后确认）

1.1.6 指标验证与验收标准

在产品上线前，需要提前定义“如何验证 Impact 评估是否正确”：

• 数据埋点方案：在评论发送按钮旁埋入“表情包使用次数”事件，属性包括表情包 ID、用户 ID、评论内容是否带表情。
• 验收门槛：上线后 2 周内，评论转化率（发起评论用户/浏览用户）提升 ≥ 10%，且表情包使用占比 ≥ 评论总量的 5%。
• 有效性检查：如果实际 Impact 低于预估，需复盘 Confidence 评估环节——是用户访谈有偏差，还是 Reach 估算虚高？