功能优先级

用 RICE 或 MoSCoW 等框架按对核心假设的影响和工作量排功能。

为什么

MVP 上线后，用户要了 20 个功能你只能做 3 个。功能优先级框架防两种失败：建嗓门大的用户的功能（吱吱轮赢）和建最有趣的功能（工程师偏）。RICE（触达 × 影响 × 信心 / 工作量）给每个功能打四维分合起来估每单位工作量价值。MoSCoW（必须/应该/可以/不会）强制显式分类。框架不如先打分再建的纪律重要——排名的行为浮现你否则会默默据以行动的假设。

何时使用

MVP 上线后，当你有用户请求积压时。每轮半天。每 2-4 周重排。

如何做

1. 列所有候选功能
   - 来自用户请求、你愿景、分析观察
   - 每个一行："什么" + "哪用户" + "什么结果"

2. 选框架
   - RICE：定量，适合比不相似功能
   - MoSCoW：分类，适合发布!MoSCoW：分类，适合发布规划
   - 影响/工作量矩阵：可视，适合小集

3. 给每个功能打分（RICE 例）
   - 触达：多少用户受益？（1 = 少，5 = 全）
   - 影响：多帮助他们？（1 = 不错，5 = 解锁使用）
   - 信心：多确定？（1 = 猜，5 = 有数据）
   - 工作量：多少人周？（1 = 快，5 = 大）
   - RICE =（触达 × 影响 × 信心）/ 工作量

4. 排序并画线
   - 按分降序排
   - 在你产能处画线（如前 3 进下冲刺）
   - 线下都等

5. 合理性检查顶和底
   - 顶：最高分功能真服务核心假设吗？
   - 底：最低分功能在那是因你应尊重的原因吗？（战略，不只是分）

6. 沟通排名
   - 与团队和关键用户分享
   - 解释为何顶功能赢底功能等
   - 这建信任且防每冲刺重辩

示例

产品：AI changelog 生成器，上线 2 周后。
积压（12 个用户请求功能）：

  功能                             | 触 影 信 工 | RICE
  自定义模板                       | 2  4  4  2  | 16
  多仓支持                         | 3  5  4  3  | 20
  Slack 自动发布                   | 2  3  3  2  | 9
  语义版本                         | 4  4  5  1  | 80  ← #1
  自定义分组                       | 4  5  4  2  | 40  ← #2
  PDF 导出                         | 1  2  4  2  | 4
  API 访问                         | 1  4  3  4  | 3
  团队工作区                       | 2  3  2  5  | 2
  AI 语气调整                       | 3  2  2  2  | 6
  发布 webhook                     | 1  3  4  1  | 12
  Changelog 托管                   | 2  4  3  4  | 6

前 3（下冲刺）：
  1. 语义版本（80）— 高触达、高影响、低工作量、有数据
  2. 自定义分组（40）— 用户明确要，改善输出质量
  3. 多仓（20）— 重度用户碰 1 仓上限，阻留存

推迟：Slack 发布（9）、API（3）、团队工作区（2）— 对当前细分低触达或高工作量。

常见问题

⚠把信心全打 5——如果全"确定"，信心无意义；5 留给有数据，2-3 给猜。
⚠忽略工作量——RICE 40 工 4 周的功能堵管道一个月；产能规划中考虑工作量不只分。
⚠每冲刺重辩——如果排名每周变，你打分不一致；设标准并坚持 2-3 冲刺。
⚠优先嗓门大的用户——一个用户的紧急请求不是高触达；按多少用户真有需求打触达。

最佳实践

✓用 RICE 比不相似功能，MoSCoW 做发布规划——它们答不同问题且互补。
✓诚实打信心——5 给有数据（分析、A/B 测试），3 给强用户信号，1-2 给直觉；这防宠物项目超分。
✓每 2-4 周用新数据重排——低优先功能可能随用户需求演或你发高优先的而升。
✓与用户分享排名——"这是我们的优先及为何"把功能请求变成对你约束的理解，减重复要。