收集了一堆反馈后，如何判断先做哪个？影响范围和严重程度是两个关键维度。
反馈五花八门，但归纳起来无非几种类型。Bug 报告是功能错误或异常，比如"登录按钮没反应"。功能请求是希望新增功能，比如"能否加入导出功能"。体验问题是使用不顺畅，比如"找不到设置在哪里"。性能问题是速度或卡顿，比如"页面加载太慢"。还有内容相关的，比如"这个词用错了"。剩下的归为其他。
分类的目的不是为了好看，而是为了下一步——判断优先级。Bug 和性能问题通常比功能请求更紧急，因为它们影响的是"能不能用"，而不是"好不好用"。
矩阵能快速分出大类，但如果有好几个 P1 怎么办？老师傅教了小明一个更精确的方法——RICE 评分模型。
RICE 由四个维度组成。Reach（触达）是多少用户受影响，用每月用户数来衡量。Impact（影响）是对用户的影响程度，用 1-3 分来打。Confidence（信心）是你对这个评估有多大把握，用百分比表示。Effort（工作量）是需要多少时间和资源，用人月来算。
计算公式很简单：
RICE = (Reach × Impact × Confidence) / Effort小明试着给三个功能打分：
| 功能 | Reach | Impact | Confidence | Effort | RICE |
|---|---|---|---|---|---|
| 导出功能 | 100 | 3 | 80% | 2 | 120 |
| 深色模式 | 500 | 1 | 100% | 3 | 167 |
| 修复登录 Bug | 1000 | 3 | 100% | 1 | 3000 |
结果一目了然：修复登录 Bug 的 RICE 分数是深色模式的 18 倍。直觉可能觉得"500 人想要深色模式，应该先做"，但 RICE 告诉你，修复一个影响 1000 人的严重 Bug 远比满足 500 人的"想要"更重要。
RICE 不是为了精确计算，而是为了让你把假设和数据摆到台面上。当你纠结"先做哪个"时，把数字列出来，答案往往就清楚了。
如果觉得 RICE 太重，还有一个简化版叫 ICE：Impact（影响，1-10 分）、Confidence（信心，1-10 分）、Ease（容易度，1-10 分），三者取平均。ICE 适合快速决策，RICE 适合需要更严谨评估的场景。
小明最难学会的一课是拒绝。
有人说"能不能加个聊天功能"，有人说"能不能支持 Markdown"，有人说"能不能做个手机 App"。每个建议听起来都不错，但你的时间和精力是有限的。
核心功能优先于边缘功能，修复 Bug 优先于新功能，小投入大回报的事优先于大投入小回报的事，与产品方向一致的需求优先于偏离方向的需求。
当你需要拒绝时，不要冷冰冰地说"不做"。如果不是目标用户的需求，可以说"这不在当前计划内，但感谢建议"。如果与产品方向不符，可以说"我们的重点是 X，暂时不会做 Y"。如果只是资源有限，可以说"这个建议很好，已记录，会在后续考虑"。
说"不"不是忽视用户，而是对产品方向负责。你是产品的负责人，不是所有反馈都要采纳。老师傅说："好的产品不是功能最多的，而是最专注的。"
小明学会了给反馈排优先级，但有些反馈太模糊了——"不好用"到底是哪里不好用？"体验差"差在哪里？
下一节，我们来学怎么真正理解用户。