MVP功能优先级模板
功能优先级排序是 MVP 设计中最关键的决策。每个产品团队在规划 MVP 时，都会面对一个共同的困境：想做的功能有 30 个，但资源和时间只够做 5 到 8 个。选哪些做、哪些不做，直接决定了 MVP 能否验证核心假设、能否给用户传递价值、能否为后续迭代提供有效数据。
凭直觉排序是最常见的做法，也是最容易出错的做法。创始人倾向于优先做「自己觉得酷」的功能，工程师倾向于优先做「技术上有趣」的功能，设计师倾向于优先做「体验上出彩」的功能。每个人都有合理的理由，但每个人的理由都带有偏见。
功能优先级框架的作用不是取代判断，而是提供一个结构化的评估过程——让团队用同一套标准、同一种语言来讨论「先做什么、后做什么」。这篇文章介绍四种主流的排序框架（MoSCoW、Kano、RICE、ICE），提供可以直接套用的评分模板和决策矩阵，并说明如何将这些框架组合使用，得出可靠的优先级结论。
一、四种主流排序框架详解
每种框架解决不同的问题。选择框架之前，先理解它的设计目的和适用场景。
1.1 MoSCoW 方法
MoSCoW 是最简单直接的功能分类方法。名字来自四个类别的首字母：
| 类别 | 含义 | 判断标准 | MVP 中的角色 |
|---|---|---|---|
| Must have（必须有） | 没有它产品无法运作 | 去掉后 MVP 是否还能验证核心假设？不能去掉的就是 Must | 构成 MVP 的核心骨架 |
| Should have（应该有） | 重要但不致命 | 没有它产品能用，但体验明显受损 | 提升 MVP 的可用性和价值感 |
| Could have（可以有） | 锦上添花 | 有的话更好，没有也不影响核心体验 | 在资源充裕时补充 |
| Won't have（不会有） | 本期明确不做 | 与核心假设验证关系不大，或成本过高 | 明确排除，避免范围蔓延 |
MoSCoW 的核心价值在于「分类」而非「排序」。它帮你把功能分成四个桶，而不是给出一个精确的先后顺序。它的优势是简单，团队可以在 30 分钟内完成一轮分类；劣势是颗粒度粗，同一个 Must 类别内的功能仍然需要进一步排序。
1.2 Kano 模型
Kano 模型从用户满意度的角度来审视功能。它由日本学者狩野纪昭（Noriaki Kano）在 1980 年代提出，核心观点是：不同类型的功能对用户满意度的影响方式完全不同。
| 功能类型 | 定义 | 对用户满意度的影响 | MVP 策略 |
|---|---|---|---|
| Must-be（必备属性） | 用户认为理所当然应该有的功能 | 有→不增加满意度；没有→极度不满 | 必须全部实现，是产品的基本门槛 |
| One-dimensional（期望属性） | 用户明确表达想要的功能 | 有→满意度增加；没有→满意度下降 | 优先实现，直接影响用户评价 |
| Attractive（魅力属性） | 用户没有预期、但出现后会惊喜的功能 | 有→满意度大幅增加；没有→不会不满 | 选择 1 到 2 个作为差异化亮点 |
| Indifferent（无差异属性） | 用户不在乎的功能 | 有无都不影响满意度 | MVP 阶段不做 |
| Reverse（反向属性） | 出现后反而引起不满的功能 | 有→满意度下降 | 明确不做 |
Kano 模型需要通过用户调研来判定功能类型。标准做法是对每个功能提两个问题：
- 正向问题：如果有这个功能，你的感受是？（喜欢 / 理应如此 / 不在乎 / 能接受 / 不喜欢）
- 反向问题：如果没有这个功能，你的感受是？（喜欢 / 理应如此 / 不在乎 / 能接受 / 不喜欢）
将正向和反向的回答组合，就能确定该功能属于哪种类型。
1.3 RICE 评分模型
RICE 是一个量化评分框架，由 Intercom 的产品团队提出。它通过四个维度的数值计算得出每个功能的优先级得分：
RICE 得分 = (Reach × Impact × Confidence) ÷ Effort
| 维度 | 含义 | 评分范围 | 评分说明 |
|---|---|---|---|
| Reach（触达） | 这个功能在一个时间段内能影响多少用户 | 具体数字（如：500 用户/月） | 用实际数据或合理估算 |
| Impact（影响） | 对每个用户的影响程度 | 3 = 高, 2 = 中, 1 = 低, 0.5 = 极低 | 基于用户调研或业务判断 |
| Confidence（信心） | 对上述估算的确信程度 | 100% = 高, 80% = 中, 50% = 低 | 有数据支撑给高分，纯猜测给低分 |
| Effort（工作量） | 团队需要投入的人月数 | 具体数字（如：2 人月） | 由工程团队评估 |
RICE 的优势是把模糊的「这个功能很重要」转化为可比较的数字。它的局限在于评分依赖估算质量——如果 Reach 和 Impact 的估算不准确，算出来的得分也没有意义。
1.4 ICE 评分模型
ICE 是 RICE 的简化版本，同样由 Intercom 提出。它用三个维度来评估：
ICE 得分 = Impact × Confidence × Ease
| 维度 | 含义 | 评分范围 |
|---|---|---|
| Impact（影响） | 对核心指标的影响程度 | 1-10 分 |
| Confidence（信心） | 对评估的确信程度 | 1-10 分 |
| Ease（容易程度） | 实现的容易程度 | 1-10 分（10 = 非常容易，1 = 非常困难） |
ICE 比 RICE 更轻量：不需要估算具体用户数和工作量，所有维度都是 1-10 的主观评分。它特别适合早期团队——数据有限、时间紧迫、需要快速做出决策的场景。
注意 ICE 中的 Ease 和 RICE 中的 Effort 方向相反：ICE 中 Ease 越高越好（10 分表示非常容易），RICE 中 Effort 越低越好（作为除数）。
二、功能评估模板
以下是四种框架的评分模板，可以直接复制到电子表格或文档中使用。
2.1 MoSCoW 分类模板
| 序号 | 功能名称 | 功能描述 | 分类 | 分类理由 | 备注 |
|---|---|---|---|---|---|
| 1 | 用户注册/登录 | 支持邮箱和 Google OAuth 注册登录 | Must | 没有账户系统，用户无法使用任何功能 | 优先支持 Google OAuth |
| 2 | 核心功能 A | （描述产品核心价值的关键功能） | Must | 去掉后无法验证核心假设 | |
| 3 | 数据导出 | 用户可导出结果为 CSV/PDF | Should | 用户需要保存结果，但不影响核心体验 | 可先用截图替代 |
| 4 | 多语言支持 | 界面支持英语、西班牙语等 | Could | 提升覆盖面，但 MVP 可先做英语 | 根据用户数据决定优先级 |
| 5 | 社交分享 | 一键分享到社交媒体 | Won't | 与核心假设验证无关 | 后续版本考虑 |
填写说明：
- 先列出所有候选功能，不做任何筛选
- 逐个判断：如果去掉这个功能，MVP 是否还能验证核心假设？如果不能→Must；如果能但体验明显受损→Should；如果几乎无影响→Could
- Won't 类别要写明「为什么不做」，避免后续反复讨论
- Must 类别的功能数量建议控制在 5 到 8 个，超过说明 MVP 范围过大
2.2 Kano 调研评分模板
| 序号 | 功能名称 | 正向问题回答 | 反向问题回答 | Kano 分类 | Better 系数 | Worse 系数 | 优先级 |
|---|---|---|---|---|---|---|---|
| 1 | 功能 A | 喜欢 | 不喜欢 | Attractive | 1.00 | -1.00 | 高 |
| 2 | 功能 B | 理应如此 | 不喜欢 | One-dimensional | 1.00 | -1.00 | 高 |
| 3 | 功能 C | 理应如此 | 理应如此 | Must-be | 0.25 | -1.00 | 必须做 |
| 4 | 功能 D | 不在乎 | 不在乎 | Indifferent | 0.00 | 0.00 | 不做 |
Kano 分类判定表（正向 × 反向）：
| 正向＼反向 | 喜欢 | 理应如此 | 不在乎 | 能接受 | 不喜欢 |
|---|---|---|---|---|---|
| 喜欢 | 反向 | 反向 | 反向 | 反向 | 魅力 |
| 理应如此 | 反向 | 无差异 | 无差异 | 无差异 | 必备 |
| 不在乎 | 反向 | 无差异 | 无差异 | 无差异 | 必备 |
| 能接受 | 反向 | 无差异 | 无差异 | 无差异 | 必备 |
| 不喜欢 | 魅力 | 期望 | 期望 | 期望 | 反向 |
Better 系数 = （魅力 + 期望）数量 ÷ 总问卷数。值越高，该功能对满意度提升越大。
Worse 系数 = -（必备 + 期望）数量 ÷ 总问卷数。值越接近 -1，该功能缺失时不满越强烈。
2.3 RICE 评分模板
| 序号 | 功能名称 | Reach（用户数/季度） | Impact（0.5-3） | Confidence（50%-100%） | Effort（人月） | RICE 得分 | 排序 |
|---|---|---|---|---|---|---|---|
| 1 | 用户注册 | 1000 | 3（高） | 100% | 1 | 3000 | 1 |
| 2 | 核心功能 A | 800 | 3（高） | 80% | 2 | 960 | 2 |
| 3 | 数据导出 | 500 | 2（中） | 80% | 0.5 | 1600 | 3 |
| 4 | 多语言 | 300 | 1（低） | 50% | 1 | 150 | 5 |
| 5 | 社交分享 | 200 | 1（低） | 50% | 1.5 | 67 | 6 |
计算方式：RICE 得分 = (Reach × Impact × Confidence) ÷ Effort
评分参考：
- Reach：用目标市场的潜在用户数估算。如果不确定，取保守值并降低 Confidence
- Impact：3 = 这个功能会改变用户的使用行为；2 = 明显提升体验；1 = 有轻微改善；0.5 = 影响极小
- Confidence：100% = 有用户数据支撑；80% = 有类似产品参考；50% = 团队猜测
- Effort：由工程团队评估。1 人月 = 1 个工程师全职工作 1 个月
2.4 ICE 评分模板
| 序号 | 功能名称 | Impact（1-10） | Confidence（1-10） | Ease（1-10） | ICE 得分 | 排序 |
|---|---|---|---|---|---|---|
| 1 | 用户注册 | 10 | 10 | 8 | 800 | 1 |
| 2 | 核心功能 A | 9 | 8 | 5 | 360 | 3 |
| 3 | 数据导出 | 6 | 7 | 9 | 378 | 2 |
| 4 | 多语言 | 4 | 5 | 4 | 80 | 5 |
| 5 | 社交分享 | 3 | 5 | 6 | 90 | 4 |
计算方式：ICE 得分 = Impact × Confidence × Ease
评分参考：
- Impact：10 = 对核心指标有决定性影响；5 = 有一定影响；1 = 几乎没有影响
- Confidence：10 = 有直接数据支撑；5 = 有间接参考；1 = 纯直觉
- Ease：10 = 几天内可以完成；5 = 需要几周；1 = 需要数月
三、决策矩阵模板
单一框架可能给出有偏差的结论。决策矩阵的作用是用多个视角交叉验证，得出更可靠的优先级排序。
3.1 综合决策矩阵
| 功能名称 | MoSCoW 分类 | Kano 类型 | RICE 得分 | ICE 得分 | 综合优先级 | 最终决策 |
|---|---|---|---|---|---|---|
| 用户注册 | Must | Must-be | 3000 | 800 | P0 | ✅ 纳入 MVP |
| 核心功能 A | Must | One-dimensional | 960 | 360 | P0 | ✅ 纳入 MVP |
| 数据导出 | Should | Expectation | 1600 | 378 | P1 | ✅ 纳入 MVP（简化版） |
| 社交分享 | Won't | Indifferent | 67 | 90 | P3 | ❌ 不纳入 |
| 多语言 | Could | Indifferent | 150 | 80 | P2 | ⏸ 后续迭代 |
3.2 综合优先级判定规则
| 条件 | 综合优先级 | 说明 |
|---|---|---|
| MoSCoW = Must 且 Kano ∈ {Must-be, One-dimensional} | P0（必须做） | 核心功能，无条件纳入 MVP |
| MoSCoW = Must 且 Kano = Attractive | P0（必须做） | 核心功能 + 差异化亮点 |
| MoSCoW = Should 且 RICE/ICE 得分排名前 30% | P1（应该做） | 重要且性价比高，尽量纳入 MVP |
| MoSCoW = Should 且 RICE/ICE 得分排名后 50% | P2（可以做） | 重要但成本高，视资源决定 |
| MoSCoW = Could 且 Kano = Attractive | P1（应该做） | 用户感知价值高，值得投入 |
| MoSCoW = Could 且 Kano ∈ {Indifferent, Reverse} | P3（不做） | 投入产出比低 |
| MoSCoW = Won't | P3（不做） | 本期明确排除 |
3.3 加权评分决策矩阵
如果需要对齐多个框架的结论，可以给每个框架分配权重，计算加权总分：
| 功能名称 | MoSCoW 得分（40%） | RICE 得分（30%） | ICE 得分（30%） | 加权总分 | 排序 |
|---|---|---|---|---|---|
| 用户注册 | 4 × 0.4 = 1.6 | 归一化 × 0.3 | 归一化 × 0.3 | 3.40 | 1 |
| 核心功能 A | 4 × 0.4 = 1.6 | 归一化 × 0.3 | 归一化 × 0.3 | 2.85 | 2 |
| 数据导出 | 3 × 0.4 = 1.2 | 归一化 × 0.3 | 归一化 × 0.3 | 2.10 | 3 |
| 社交分享 | 1 × 0.4 = 0.4 | 归一化 × 0.3 | 归一化 × 0.3 | 0.75 | 5 |
| 多语言 | 2 × 0.4 = 0.8 | 归一化 × 0.3 | 归一化 × 0.3 | 1.20 | 4 |
MoSCoW 转换规则：Must = 4 分, Should = 3 分, Could = 2 分, Won't = 1 分。RICE 和 ICE 得分需要归一化到 0-4 的区间后再计算。
四、四种框架对比
| 维度 | MoSCoW | Kano | RICE | ICE |
|---|---|---|---|---|
| 核心逻辑 | 按必要性分类 | 按用户满意度分类 | 量化计算投入产出比 | 快速主观评分 |
| 输出结果 | 四个类别 | 五种功能类型 | 精确数值排序 | 数值排序 |
| 数据需求 | 低（团队讨论即可） | 高（需要用户调研） | 中（需要用户和工程数据） | 低（主观评估即可） |
| 适用阶段 | 早期（快速确定范围） | 中期（理解用户需求） | 中后期（精确排序） | 早期（快速决策） |
| 所需时间 | 30 分钟 - 2 小时 | 1-2 周（含调研） | 2-4 小时 | 30 分钟 - 1 小时 |
| 参与角色 | 产品 + 技术 + 业务 | 用户 + 产品 | 产品 + 技术 | 产品团队 |
| 优势 | 简单、快速、易理解 | 从用户视角出发 | 量化、可比较 | 轻量、灵活 |
| 劣势 | 颗粒度粗 | 调研成本高 | 依赖估算准确性 | 主观性强 |
| 最适合 | MVP 范围界定 | 用户体验优化 | 资源竞争排序 | 快速迭代决策 |
五、模板使用流程
以下是从零开始使用模板完成功能优先级排序的完整流程。
步骤一：收集功能（30 分钟）
从以下来源收集候选功能：
- 用户访谈和调研中用户明确表达的需求
- 竞品分析中发现的功能差距
- 团队内部讨论中产生的功能想法
- 业务目标推导出的必要功能
目标：列出 20-40 个候选功能，不做任何筛选。
步骤二：初筛（15 分钟）
去除：
- 重复或高度相似的功能（合并为一个）
- 与核心假设完全无关的功能
- 技术上明显不可行的功能（在当前时间和资源约束下）
目标：保留 15-25 个候选功能进入正式评估。
步骤三：选择并执行主框架（1-3 小时）
根据团队情况选择主框架：
| 团队情况 | 推荐主框架 | 理由 |
|---|---|---|
| 刚启动、数据有限 | ICE | 不需要数据，1 小时内可完成 |
| 有用户调研基础 | RICE | 利用已有数据做精确排序 |
| 需要快速对齐团队共识 | MoSCoW | 简单直接，适合快速讨论 |
| 需要深入理解用户需求 | Kano | 从用户满意度出发做决策 |
步骤四：交叉验证（可选但推荐）
用第二种框架对主框架的结果做交叉验证。推荐组合：
- MoSCoW + RICE：先用 MoSCoW 划定范围，再用 RICE 在 Must 和 Should 内部排序
- ICE + Kano：先用 ICE 快速排序，再用 Kano 验证高分功能是否真的是用户需要的
- MoSCoW + ICE：先用 MoSCoW 分类，再用 ICE 在 Should 类别中选出性价比最高的功能
步骤五：团队评审（1 小时）
将所有评分和分类结果展示给团队，重点讨论：
- 评分结果与团队直觉是否一致？不一致的原因是什么？
- 边界功能（如 MoSCoW 中 Must 和 Should 之间的功能）的最终归属
- 是否有新的信息需要调整评分
步骤六：确定 MVP 功能列表
根据评审结果，最终确定：
- P0（Must）：全部纳入 MVP，通常 5-8 个
- P1（Should 中的高分项）：尽量纳入 MVP，通常 3-5 个
- P2（Could / Should 中的低分项）：明确不纳入 MVP，但列入第一版迭代计划
- P3（Won't）：明确排除，记录原因
六、案例演示
案例一：AI 写作助手的 MVP 功能排序
一个团队要做面向海外市场的 AI 英文写作助手。收集到 10 个候选功能后，使用 MoSCoW + ICE 组合框架进行评估。
MoSCoW 分类结果：
| 功能 | MoSCoW 分类 | 分类理由 |
|---|---|---|
| AI 文本生成（输入主题生成文章） | Must | 核心假设验证的基础 |
| 文本编辑器（修改 AI 生成内容） | Must | 用户需要编辑才能使用生成结果 |
| 用户注册/登录 | Must | 需要保存用户历史记录 |
| 多语言支持（西班牙语、法语等） | Should | 扩展市场，但 MVP 先做英语 |
| 文章模板（邮件、博客、推文） | Should | 降低使用门槛，提升体验 |
| 历史记录查看 | Should | 用户需要找回之前的生成内容 |
| 导出为 PDF/Word | Could | 方便用户使用，但截图也能替代 |
| SEO 优化建议 | Could | 有差异化价值，但不是核心需求 |
| 团队协作（多人共享文档） | Won't | MVP 阶段面向个人用户 |
| AI 图片生成 | Won't | 与写作核心场景无关 |
ICE 评分结果（仅对 Must 和 Should 排序）：
| 功能 | Impact | Confidence | Ease | ICE 得分 | 排序 |
|---|---|---|---|---|---|
| AI 文本生成 | 10 | 9 | 6 | 540 | 1 |
| 文本编辑器 | 9 | 10 | 7 | 630 | 2 |
| 用户注册/登录 | 8 | 10 | 9 | 720 | 3 |
| 文章模板 | 7 | 7 | 7 | 343 | 4 |
| 历史记录查看 | 6 | 8 | 8 | 384 | 5 |
| 多语言支持 | 5 | 5 | 3 | 75 | 6 |
最终 MVP 功能列表：
- P0（Must）：AI 文本生成、文本编辑器、用户注册/登录
- P1（Should 高分）：文章模板、历史记录查看
- P2（推迟）：多语言支持、导出功能
- P3（不做）：团队协作、AI 图片生成
案例二：AI 设计工具的 MVP 功能排序
一个团队要做面向中小企业的 AI Logo 设计工具。使用 RICE 框架进行评估。
| 功能 | Reach（用户/季度） | Impact | Confidence | Effort（人月） | RICE 得分 | 排序 |
|---|---|---|---|---|---|---|
| AI Logo 生成（输入品牌名生成 Logo） | 2000 | 3 | 80% | 2 | 2400 | 1 |
| 在线编辑器（调整颜色、字体、布局） | 1800 | 3 | 90% | 3 | 1620 | 2 |
| 用户注册/登录 | 2000 | 2 | 100% | 1 | 4000 | 3 |
| 品牌色板推荐 | 1200 | 2 | 70% | 0.5 | 3360 | 4 |
| 高清 PNG/SVG 下载 | 1500 | 3 | 90% | 1 | 4050 | 5 |
| 多语言界面 | 800 | 1 | 50% | 1.5 | 267 | 7 |
| 名片设计 | 600 | 2 | 60% | 2 | 360 | 6 |
| 社交媒体模板 | 500 | 1 | 50% | 2 | 125 | 8 |
MVP 决策：
- 前 5 项纳入 MVP。核心逻辑是：用户注册 → AI 生成 Logo → 在线编辑 → 下载高清文件。这是一个完整的价值闭环。
- 多语言、名片设计、社交媒体模板推迟到 MVP 后。Reach 或 Impact 过低，投入产出比不划算。
七、常见使用误区
| 误区 | 正确做法 | 风险 |
|---|---|---|
| 只用一个框架，不做交叉验证 | 至少用两种框架对比验证 | 单一框架的盲区可能导致错误决策 |
| 把 RICE/ICE 得分当作绝对真理 | 得分是辅助决策的工具，不是决策本身 | 过度依赖数字会忽略无法量化的重要因素 |
| 让一个人独自完成所有评分 | 多角色参与（产品、技术、设计、业务） | 单人视角偏见会带入系统性偏差 |
| MoSCoW 的 Must 太多（超过 10 个） | 重新审视 Must 的判断标准，真正砍掉一些 | Must 太多等于没有优先级，MVP 范围失控 |
| Kano 调研样本太少（少于 20 份） | 至少收集 30-50 份有效问卷 | 样本不足时分类结果不可靠 |
| 评分一次定终身，不再调整 | 定期（每 2-4 周）重新评估，根据新信息调整 | 市场环境和用户认知会变化，评分也需要更新 |
| 忽略 Confidence 维度 | 对不确定的估算主动降低信心值 | 高估自己的判断准确性会导致资源错配 |
| Won't 的功能不记录原因 | 明确记录不做的原因和触发重新评估的条件 | 不记录会导致后续反复讨论同一个功能 |
| 用框架替代团队讨论 | 框架提供结构，但结论需要团队达成共识 | 纯机械化评分会忽略团队协作带来的认知价值 |
| 在框架选择上花太多时间 | 快速选定一个开始做，做的过程中调整 | 过度追求「最佳框架」本身就是一种浪费 |
八、框架选择的决策路径
| 场景 | 推荐组合 | 理由 |
|---|---|---|
| 零基础、无数据、时间紧 | ICE → MoSCoW 验证 | ICE 快速出结论，MoSCoW 验证范围是否合理 |
| 有用户数据、需要精确排序 | RICE → Kano 验证 | RICE 给出排序，Kano 检查用户满意度覆盖 |
| 团队对齐、快速达成共识 | MoSCoW → ICE 补充 | MoSCoW 分类快速，ICE 在 Should 内部排序 |
| 需要深入理解用户需求 | Kano → RICE 排序 | Kano 理解需求类型，RICE 在同类型中精确排序 |
九、综合检查清单
评估前准备
- 已明确 MVP 要验证的核心假设
- 已收集 20-40 个候选功能，来自用户调研、竞品分析和团队讨论
- 已完成初筛，保留 15-25 个候选功能进入正式评估
- 已确定使用的评估框架，团队成员理解框架的使用方式
评估过程
- 评分由多角色参与（产品、技术、设计至少各一人）
- 每个功能的评分都有明确依据（数据来源或推理逻辑）
- Confidence 评分诚实反映了团队对各功能估算的确信程度
- MoSCoW 的 Must 数量控制在 5-8 个（不超过 10 个）
- 如使用 Kano 调研，有效问卷数不少于 30 份
- 如使用 RICE，Effort 已由工程团队评估确认
- 已使用至少两种框架做交叉验证
评估结果
- 存在争议的边界功能已经过团队讨论并达成共识
- Won't / P3 的功能已记录不做的原因
- MVP 功能列表已确定，包含 P0（Must）和 P1（Should 高分项）
- 核心流程在 MVP 功能列表上可以完整闭环
- 评估结果已输出为文档，可供后续迭代时回溯和调整
十、写在最后
功能优先级模板不是万能药。它不能替你做决策，但它能让决策过程变得透明、可讨论、可追溯。一个好的优先级评估，结果可能不完美，但过程一定是结构化的、多视角的、有数据支撑的。
对做出海产品的团队来说，功能优先级排序还有一个特殊意义：资源有限时，你选择先做什么功能，本质上是在选择先服务哪类用户、先进入哪个市场、先验证哪个商业假设。这个选择比任何单个功能的实现都重要。
模板的价值在于降低决策成本。它让你不用每次都从零开始讨论「先做什么」，而是有一套公认的方法快速收敛到结论。结论可以调整，但调整的基础应该是新的信息和数据，而不是某个人更强烈的直觉。
参考资料
- Intercom.「RICE: A simple framework for prioritizing your product ideas」. intercom.com/blog/rice-simple-prioritization-product-manager
- Atlassian.「六个产品优先级排序框架和如何选择正确的框架」. atlassian.com/zh/agile/product-management/prioritization-framework
- Noriaki Kano, Nobuhiku Seraku, Fumio Takahashi, Shinichi Tsuji.「Attractive Quality and Must-be Quality」. Journal of the Japanese Society for Quality Control, 1984.
- Product School.「9 Prioritization Frameworks & Which to Use in 2025」. productschool.com/blog/product-fundamentals/ultimate-guide-product-prioritization
- ProductLift.「RICE vs ICE vs MoSCoW: Side-by-Side Comparison Table」. productlift.dev/blog/product-prioritization-framework-comparison
- 6sense.「MVP Feature Prioritization: MoSCoW vs RICE vs Kano Framework」. 6sensehq.com/blog/mvp-feature-prioritization
- Get Product People.「Prioritization Techniques: RICE, MoSCoW, ICE & Kano」. getproductpeople.com/blog/prioritization-techniques-rice-moscow-ice-kano
- 人人都是产品经理.「产品路线图中，如何对需求进行排序」. woshipm.com/pd/1887717