产品设计 · 第 3 篇

需求优先级：什么先做，什么不做

做产品最怕什么？不是没有想法，而是想法太多、资源太少。你手里可能同时有 20 个需求，但这个版本只能做 5 个。先做哪个？不做哪个？这个决策，直接决定了产品的成败。

今天我们聊三种最实用的需求优先级排序方法：KANO 模型、RICE 评分、四象限法。每种方法适合不同的场景，学完你就能在实际工作中灵活运用。

为什么优先级是 PM 最重要的能力之一

很多新人觉得 PM 的核心能力是“想出好功能”。但实际上，决定不做什么，往往比决定做什么更重要。

原因很简单：

• 资源永远是有限的。 开发时间、设计资源、测试人力，没有哪个团队是“要多少有多少”的。一个需求排上去，意味着另一个需求被推迟。
• 不是功能多就好。 微信早期只做聊天和朋友圈，没有小程序、没有视频号，但它已经是最好的社交产品。产品好坏不取决于你做了多少功能，而取决于你先做对了哪几个。
• 说“不做”比说“做”更难。 每个人都会提需求——老板、运营、客服、用户。PM 如果来者不拒，最终的结果就是版本塞满、质量失控、什么都做不好。

所以，排优先级不是一个“锦上添花”的技能，它是 PM 的核心生存能力。

方法一：KANO 模型

KANO 模型是日本学者狩野纪昭提出的，核心思路是：不同类型的需求，对用户满意度的影响方式是不同的。

五种需求类型

用一个外卖 App 来举例：

• 必备型（Must-be）：没有的话用户直接走人，有了也不觉得多好。比如“能正常下单、能查看订单状态”。这就像餐厅有干净的桌子——没有你转身就走，有了你也不会专门夸。
• 期望型（One-dimensional）：做得越好，用户越满意；做得越差，用户越不满。比如“配送速度”——30 分钟送到还行，20 分钟送到就开心，50 分钟还没到就想给差评。
• 兴奋型（Attractive）：用户压根没想到，但你做了他会惊喜。比如“年度外卖账单”、“AI 根据你口味推荐餐厅”。这类需求是拉开产品差距的杀手锏。
• 无差异型（Indifferent）：做不做用户都无所谓。比如在外卖 App 里加一个“天气预报”功能，用户大概率不会用。
• 反向型（Reverse）：做了反而让用户反感。比如“每次打开 App 弹一个全屏广告”、“强制分享才能领红包”，这些功能做了是在赶用户走。

怎么用

KANO 模型的使用有一个经典方法——正反问卷法：

针对每个功能问两个问题：

1. 正向问：“如果有这个功能，你觉得怎么样？”
2. 反向问：“如果没有这个功能，你觉得怎么样？”

根据用户的回答组合，就能把需求归到五种类型里去。

排序原则也很清晰：

1. 先把必备型做到位（否则用户留不住）
2. 再持续优化期望型（这是竞争的主战场）
3. 最后用兴奋型点缀（制造口碑和传播）
4. 无差异型不做，反向型坚决砍掉

KANO 的局限： 它是定性的分类工具，能告诉你“这个需求属于哪一类”，但不能精确告诉你“A 需求和 B 需求到底谁先做”。需要更精确的排序时，就要用到下面的 RICE。

方法二：RICE 评分

RICE 是 Intercom（一家知名 SaaS 公司）提出的评分框架，最大的优势是把主观判断变成可量化的分数，特别适合在版本规划时对一堆需求做排序。

四个维度

• Reach（覆盖面）：这个需求在一定周期内能影响多少用户？比如“每月能触达 5000 个用户”。
• Impact（影响度）：对被触达的用户，影响有多大？通常用分级：3 = 巨大影响，2 = 较大影响，1 = 中等影响，0.5 = 较小影响，0.25 = 微小影响。
• Confidence（信心度）：我们对以上判断有多大把握？有数据支撑给 100%，有部分依据给 80%，纯粹猜测给 50%。
• Effort（工作量）：需要多少人月？数字越大说明投入越大。

计算公式

RICE 分数 = (Reach x Impact x Confidence) / Effort

分数越高，说明“性价比”越高，应该优先做。

实际案例

假设你是一个电商 App 的 PM，手里有 5 个待排需求，团队本月只能做 2 个。我们来走一遍 RICE 打分：

我们来算一下：

• 需求 E（加载提速）：12000 x 1 x 100% / 0.5 = 24000，遥遥领先。触达用户最多、工作量最小、信心也足，这种“低成本高覆盖”的优化类需求往往分数很高。
• 需求 A（搜索优化）：10000 x 2 x 80% / 2 = 8000，排第二。
• 需求 C（购物车改版）：8000 x 1 x 100% / 1 = 8000，和 A 并列。
• 需求 B（直播带货）：3000 x 3 x 50% / 5 = 900，虽然影响度高但信心不足、投入大，分数一般。
• 需求 D（积分系统）：2000 x 2 x 50% / 4 = 500，各项指标都不突出。

结论：本月优先做 E（加载提速）和 A 或 C（搜索优化或购物车改版）。 直播带货虽然听起来“很有想象空间”，但信心度只有 50%，投入又大，不如先做确定性高的需求。

这就是 RICE 的价值——它让你在一堆“好像都重要”的需求里，用数据说话，做出更理性的选择。

方法三：四象限法（紧急-重要矩阵）

这是最简单也最经典的方法，来自时间管理大师史蒂芬·柯维的理论。把所有需求按“紧急程度”和“重要程度”两个维度分成四个象限：

• 重要且紧急（第一象限）：立刻做。线上严重 Bug、安全漏洞、核心功能崩溃。这类事情不做，损失是即时的、巨大的。
• 重要不紧急（第二象限）：排入版本计划，持续投入。核心体验优化、架构升级、用户增长策略。这类事情决定产品的长期竞争力。
• 紧急不重要（第三象限）：能委托就委托，能简化就简化。比如临时运营活动的配置需求、一次性的数据导出。
• 不紧急不重要（第四象限）：暂时不做，放到需求池里等着。

这个方法最大的洞察是：大多数 PM 的时间都陷在第三象限——紧急但不重要的事情里。 老板突然说“明天要一个数据报表”，运营说“这个活动页今天能上吗”，客服说“这个用户投诉了能不能今天修”……这些事看起来都很“急”，但对产品长期价值的贡献其实有限。

真正应该多花时间的是第二象限——重要但不紧急的事。比如“搜索体验怎么从 70 分做到 90 分”、“新用户留存为什么低”、“技术架构能不能支撑未来半年的增长”。这些事没人催你，但做好了价值巨大。

实际工作中怎么选方法

三种方法不是互相替代的，它们适合不同场景：

• 日常快速判断：用四象限法。两分钟就能把手头的事情分个类，先做什么后做什么心里就有数了。
• 版本规划：用 RICE 评分。当你需要在 10 个需求里选 3 个放进下个版本，RICE 能帮你做出更理性的排序。
• 战略方向判断：用 KANO 模型。当你需要思考“产品接下来半年的重心放在哪类需求上”，KANO 的分类视角非常有用。

当然，不需要每次都用完整的流程。很多时候，经验丰富的 PM 只是在脑子里快速过一遍这些框架的逻辑，就能做出判断。方法是辅助工具，不是标准答案——最终还是要靠 PM 的判断力。

排优先级时的常见陷阱

即使掌握了方法，实际工作中还是很容易踩坑。以下五个陷阱要特别注意：

• 老板说的优先级最高。 老板的意见当然要重视，但不代表不需要追问理由。“老板说做”不是需求文档，你应该搞清楚背后的逻辑——也许老板想解决的问题，有更好的实现方式。
• 声音最大的用户优先。 在论坛里发帖抱怨的、在客服那里反复投诉的用户，往往只是少数人。声音大不等于代表多数用户，做决策前要看数据，别被情绪带着走。
• 技术说好做的先做。 “这个需求只要两天就能上”——容易做和应该做是两回事。如果一个功能对用户没什么价值，开发再快也是浪费。
• 新功能优先于优化。 很多团队迷恋“做新东西”，觉得优化老功能不够酷。但现实是，80% 的价值在于把已有功能做好。搜索快 0.5 秒带来的留存提升，可能比一个全新功能大得多。
• 每次都加需求不砍需求。 需求评审的时候，大家都在说“这个也加上吧”。但如果只加不砍，版本越来越膨胀，最终什么都做不好、什么都上不了线。好的 PM 敢砍需求。

一句话建议

最后送一个练习方法：

如果你只能做一个功能，做哪个？ 想好了？好，现在再砍掉一个——如果只剩两个功能必须砍掉一个，砍哪个？

这个反复追问自己的过程，就是在训练优先级判断力。它没有标准答案，但每多做一次，你的判断就会更准一分。

优先级排序不是科学，是手艺。方法给你框架，经验给你直觉，而最终让你做出好决策的，是你对用户、对业务、对资源的深刻理解。