主题
03 - 需求收集、筛选与优先级排序
"产品经理的核心能力不是想到更多需求，而是决定不做什么。"
一、需求从哪里来？
需求的来源是多元的，一个优秀的产品经理需要建立全方位的需求收集网络。
┌──────────┐
│ 需求池 │
└────┬─────┘
┌──────────────┼──────────────┐
| | |
┌─────┴─────┐ ┌─────┴─────┐ ┌─────┴─────┐
│ 外部来源 │ │ 内部来源 │ │ 数据来源 │
└─────┬─────┘ └─────┬─────┘ └─────┬─────┘
| | |
用户反馈 老板/管理层 行为数据
客服工单 销售/客户成功 转化漏斗
竞品动态 运营团队 搜索日志
市场趋势 技术团队 A/B 测试
行业报告 战略规划 用户画像数据各来源特点对比
| 来源 | 可信度 | 紧迫感 | 数量 | 需要注意的问题 |
|---|---|---|---|---|
| 用户直接反馈 | 中高 | 中 | 多 | 用户说的 ≠ 用户要的，需要深挖真实需求 |
| 客服/工单 | 高 | 高 | 多 | 只代表遇到问题的用户，沉默的大多数被忽略 |
| 数据分析 | 高 | 中 | 中 | 只看到 What，看不到 Why |
| 竞品调研 | 中 | 低 | 中 | 竞品做的不一定适合我们 |
| 老板/管理层 | 中 | 高 | 少 | 可能基于个人直觉而非用户数据 |
| 销售团队 | 中高 | 高 | 中 | 容易被大客户的个性化需求带偏 |
| 市场趋势 | 中 | 低 | 少 | 趋势不等于当前用户的刚需 |
| 技术团队 | 高 | 低 | 少 | 通常是技术优化类，对用户不可见但有长期价值 |
关键提醒：不论需求来自谁，都要追问三个问题：
- 这是谁的需求？（哪类用户）
- 在什么场景下产生的？（上下文）
- 底层的真实诉求是什么？（本质）
二、需求池管理
收集到的需求需要统一管理，否则会散落在各处，最终被遗忘。
需求池模板
╔═══════════════════════════════════════════════════════════════════════════════╗
║ 需求池 · [产品名称] ║
╠════╦═══════════╦════════╦══════╦════════╦═══════╦════════╦═════════╦════════╣
║ ID ║ 需求描述 ║ 来源 ║ 用户 ║ 优先级 ║ 状态 ║ 负责人 ║ 提出日期 ║ 备注 ║
╠════╬═══════════╬════════╬══════╬════════╬═══════╬════════╬═════════╬════════╣
║ 01 ║ 增加比价 ║ 用户 ║ 宝妈 ║ P1 ║ 排期中║ 小王 ║ 03-15 ║ ║
║ ║ 功能 ║ 反馈 ║ 型 ║ ║ ║ ║ ║ ║
╠════╬═══════════╬════════╬══════╬════════╬═══════╬════════╬═════════╬════════╣
║ 02 ║ 搜索结果 ║ 数据 ║ 效率 ║ P0 ║ 开发中║ 小李 ║ 03-10 ║ 转化 ║
║ ║ 优化 ║ 分析 ║ 型 ║ ║ ║ ║ ║ 率低 ║
╠════╬═══════════╬════════╬══════╬════════╬═══════╬════════╬═════════╬════════╣
║ 03 ║ AR 试穿 ║ 竞品 ║ 时尚 ║ P2 ║ 待评估║ 小张 ║ 03-20 ║ ║
║ ║ 功能 ║ 调研 ║ 型 ║ ║ ║ ║ ║ ║
╠════╬═══════════╬════════╬══════╬════════╬═══════╬════════╬═════════╬════════╣
║ 04 ║ 优化退款 ║ 客服 ║ 全部 ║ P1 ║ 待排期║ 小刘 ║ 03-18 ║ 投诉 ║
║ ║ 流程 ║ 工单 ║ ║ ║ ║ ║ ║ 热点 ║
╚════╩═══════════╩════════╩══════╩════════╩═══════╩════════╩═════════╩════════╝
状态流转：待评估 -> 待排期 -> 排期中 -> 开发中 -> 测试中 -> 已上线 -> 已关闭需求状态管理
┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
│ 待评估 │──>│ 待排期 │──>│ 开发中 │──>│ 测试中 │──>│ 已上线 │
└────────┘ └────────┘ └────────┘ └────────┘ └────────┘
| |
v v
┌────────┐ ┌────────┐
│ 已拒绝 │ │ 已暂缓 │ (需要记录拒绝/暂缓的原因)
└────────┘ └────────┘常用工具
| 工具 | 适合场景 | 特点 |
|---|---|---|
| Excel/飞书表格 | 小团队/早期阶段 | 灵活、免费、门槛低 |
| Jira | 中大团队/敏捷开发 | 功能强大、与开发流程打通 |
| Tapd | 腾讯系/中小团队 | 国内体验好，免费版够用 |
| Notion | 小团队/灵活管理 | 可自定义、视图多样 |
| 飞书项目 | 字节系/中大团队 | 与飞书生态打通 |
| Trello | 小团队/看板管理 | 简单直观、上手快 |
三、KANO 模型详解
KANO 模型是日本教授狩野纪昭提出的产品质量模型，用来对需求进行分类， 帮助产品经理理解不同类型的需求对用户满意度的影响。
KANO 模型图解
用户满意度
^
| / 魅力型需求 (Attractive)
| / "有了会惊喜，没有也不会不满"
| /
| / ___--- 期望型需求 (One-dimensional)
| / __-- "做得越好越满意"
| / __--
| / __--
----+--*----- ---- ---- ---- ---- -----> 需求实现程度
| /--
|/__----___
| ---___ 基本型需求 (Must-be)
| ---___ "没有会很不满，有了觉得理所当然"
|
|
v
用户不满意
另外两种：
● 无差异型需求 (Indifferent)：有没有都无所谓
● 反向型需求 (Reverse)：有了反而不满意五种需求类型详解
| 类型 | 英文 | 描述 | 示例（电商） | 策略 |
|---|---|---|---|---|
| 基本型需求 (M) | Must-be | 用户默认应该有的，没有会很不满，做好了觉得理所当然 | 商品能正常下单支付 | 必须做好，不能出问题 |
| 期望型需求 (O) | One-dimensional | 做得越好用户越满意，与满意度线性相关 | 搜索结果越精准越好 | 尽量做好，做多少得多少 |
| 魅力型需求 (A) | Attractive | 用户没想到会有，有了会惊喜 | AI 根据穿搭风格推荐搭配 | 差异化竞争，超出预期 |
| 无差异型需求 (I) | Indifferent | 做不做用户都无所谓 | 修改 App 图标颜色 | 不用投入资源 |
| 反向型需求 (R) | Reverse | 做了反而引起用户反感 | 过于频繁的推送通知 | 绝对避免 |
如何做 KANO 问卷
对每个功能问两个问题（正向 + 反向）：
正向问题：如果 App 增加了"智能比价"功能，你觉得如何？
1. 我很喜欢
2. 理应如此
3. 无所谓
4. 勉强接受
5. 我不喜欢
反向问题：如果 App 没有"智能比价"功能，你觉得如何？
1. 我很喜欢
2. 理应如此
3. 无所谓
4. 勉强接受
5. 我不喜欢
根据两个回答的组合，查表确定需求类型：
│ 反向问题 │
│ 喜欢 理应 无所谓 勉强 不喜欢 │
─────────┼───────────────────────────────────────┤
正 喜欢 │ Q A A A O │
向 理应 │ R I I I M │
问 无所谓│ R I I I M │
题 勉强 │ R I I I M │
不喜欢│ R R R R Q │
A=魅力型 O=期望型 M=基本型 I=无差异 R=反向 Q=可疑(矛盾)四、RICE 评分法详解
RICE 是一个量化的需求优先级评估框架，由 Intercom 提出。
RICE 公式
Reach x Impact x Confidence
RICE Score = ─────────────────────────────────
Effort
R - Reach (触达范围)：这个需求影响多少用户？(人数/季度)
I - Impact (影响程度)：对每个用户的影响有多大？(0.25/0.5/1/2/3)
C - Confidence (信心度)：对以上估算有多大把握？(100%/80%/50%)
E - Effort (工作量)：需要多少人月的工作量？(人月)Impact 评分标准
| 分值 | 含义 | 说明 |
|---|---|---|
| 3 | 巨大影响 | 完全改变用户体验，显著提升核心指标 |
| 2 | 高影响 | 明显改善用户体验 |
| 1 | 中等影响 | 有一定改善 |
| 0.5 | 低影响 | 轻微改善 |
| 0.25 | 极低影响 | 几乎感知不到 |
Confidence 评分标准
| 分值 | 含义 | 依据 |
|---|---|---|
| 100% | 高信心 | 有充分的数据和用户调研支持 |
| 80% | 中高信心 | 有一些数据支持，但不完全确定 |
| 50% | 中低信心 | 主要基于直觉或少量数据 |
实际示例计算
假设我们有以下三个需求待排序：
┌──────────────────────────────────────────────────────────────────────┐
│ RICE 评分计算示例 │
├────────────────┬───────┬────────┬────────┬───────┬────────┬────────┤
│ 需求 │ Reach │ Impact │ Confid.│ Effort│ RICE │ 排名 │
│ │ (人/季)│ (0-3) │ (%) │ (人月) │ Score │ │
├────────────────┼───────┼────────┼────────┼───────┼────────┼────────┤
│ A. 搜索优化 │ 5000 │ 2 │ 80% │ 3 │ 2667 │ 1 │
│ │ │ │ │ │ │ │
│ 计算过程: │ 5000 x 2 x 0.8 / 3 = 2666.7 │
├────────────────┼───────┼────────┼────────┼───────┼────────┼────────┤
│ B. AR 试穿 │ 1000 │ 2 │ 50% │ 8 │ 125 │ 3 │
│ │ │ │ │ │ │ │
│ 计算过程: │ 1000 x 2 x 0.5 / 8 = 125 │
├────────────────┼───────┼────────┼────────┼───────┼────────┼────────┤
│ C. 比价工具 │ 3000 │ 1 │ 80% │ 2 │ 1200 │ 2 │
│ │ │ │ │ │ │ │
│ 计算过程: │ 3000 x 1 x 0.8 / 2 = 1200 │
└────────────────┴───────┴────────┴────────┴───────┴────────┴────────┘
结论：优先做搜索优化(2667) > 比价工具(1200) > AR 试穿(125)RICE 的优缺点
| 优点 | 缺点 |
|---|---|
| 量化评估，减少主观争论 | 各参数的估算本身也带有主观性 |
| 公式简单，团队容易理解和使用 | 没有考虑战略价值、技术债等因素 |
| 强制考虑 Effort（不只看价值） | Reach 和 Impact 有时很难准确估计 |
| Confidence 提醒你审视数据的可靠性 | 容易过度依赖分数，忽略定性判断 |
五、MoSCoW 方法
MoSCoW 是一种更简洁的优先级分类方法，将需求分为四个等级。
┌─────────────────────────────────────────────────────────────────┐
│ MoSCoW 优先级分类 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌───────────────────────────────────────────────────────────┐ │
│ │ Mo - Must Have (必须有) │ │
│ │ 没有就不能发布的功能。如果缺失，产品不可用或不合规。 │ │
│ │ 例：用户登录、下单支付、商品搜索 │ │
│ └───────────────────────────────────────────────────────────┘ │
│ | │
│ ┌───────────────────────────────────────────────────────────┐ │
│ │ S - Should Have (应该有) │ │
│ │ 很重要但不是致命的。可以后续迭代补充。 │ │
│ │ 例：订单追踪、收藏夹、商品筛选 │ │
│ └───────────────────────────────────────────────────────────┘ │
│ | │
│ ┌───────────────────────────────────────────────────────────┐ │
│ │ Co - Could Have (可以有) │ │
│ │ 锦上添花的功能。资源充裕时可以做。 │ │
│ │ 例：深色模式、社交分享、个性化主题 │ │
│ └───────────────────────────────────────────────────────────┘ │
│ | │
│ ┌───────────────────────────────────────────────────────────┐ │
│ │ W - Won't Have (这次不做) │ │
│ │ 明确拒绝的需求（至少本次迭代不做）。 │ │
│ │ 例：VR 购物体验、区块链溯源 │ │
│ └───────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘MoSCoW 与 KANO 的对应关系
| MoSCoW | 对应 KANO 类型 | 说明 |
|---|---|---|
| Must Have | 基本型需求 (Must-be) | 没有就不行 |
| Should | 期望型需求 (One-dimensional) | 做了会加分 |
| Could | 魅力型需求 (Attractive) | 做了会惊喜 |
| Won't | 无差异型/反向型 | 不做或明确不做 |
六、价值 vs 成本四象限图
这是一个简单直观的需求排序方法：把需求按"用户/业务价值"和"实现成本" 两个维度画在四象限图上。
高价值
^
|
II | I
战略储备区 | 优先做！
(高价值 | (高价值
高成本) | 低成本)
|
| Quick Wins!
──────────+──────────────────> 低成本
|
IV | III
直接放弃 | 谨慎评估
(低价值 | (低价值
高成本) | 低成本)
|
低价值 高成本
优先级排序：I > II > III > IV
I 象限 (高价值 + 低成本)：毫不犹豫，立即动手！这就是 Quick Wins
II 象限 (高价值 + 高成本)：值得做但需要规划资源和排期
III象限 (低价值 + 低成本)：如果开发有空闲时间可以顺手做
IV 象限 (低价值 + 高成本)：果断放弃，不要浪费资源四象限的实际运用示例
高价值
^
|
| [搜索算法重构] [一键比价功能]
| 投入大但长期价值高 开发量小且用户需求强
|
| [推荐系统升级] [优惠券叠加计算器]
| 需要 ML 团队支持 前端即可实现
──────────+──────────────────────────────────> 低成本
|
| [VR 购物体验] [App图标换色]
| 技术不成熟成本极高 简单但没人关心
| 用户价值存疑
| [区块链溯源] [启动页动画优化]
| 概念>实际 感知不明显
低价值 高成本七、实际工作中如何综合使用这些框架
在真实工作场景中，没有一个框架是万能的。成熟的产品经理通常会组合使用 多个框架，形成自己的决策体系。
推荐的综合决策流程
Step 1 Step 2 Step 3 Step 4
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ 收集需求 │──────>│ 初步分类 │──────>│ 量化评估 │──────>│ 综合决策 │
│ │ │ │ │ │ │ │
│ 建立需求池│ │ 用 KANO │ │ 用 RICE │ │ 四象限图 │
│ 多渠道收集│ │ 分类需求 │ │ 打分排序 │ │ 最终排序 │
│ 记录上下文│ │ 类型 │ │ 量化对比 │ │ 团队对齐 │
└──────────┘ └──────────┘ └──────────┘ └──────────┘
| | |
过滤掉无差异 确定优先顺序 考虑战略因素
和反向需求 (数据驱动) (人为判断)综合决策示例
假设我们面临以下 6 个需求：
| 需求 | KANO 类型 | RICE 分数 | 四象限位置 | 最终优先级 | 决策说明 |
|---|---|---|---|---|---|
| 修复支付 Bug | 基本型 M | 5000 | I (高价值/低成本) | P0 | 基本功能缺陷，必须立即修复 |
| 搜索优化 | 期望型 O | 2667 | I (高价值/低成本) | P1 | RICE 分数高，性价比高 |
| 比价工具 | 魅力型 A | 1200 | I (高价值/低成本) | P1 | 差异化亮点，成本不高 |
| 推荐系统升级 | 期望型 O | 800 | II (高价值/高成本) | P2 | 价值大但需要较多资源，排下个迭代 |
| AR 试穿 | 魅力型 A | 125 | II (高价值/高成本) | P3 | 创新但技术风险大，待验证 |
| App 换图标 | 无差异 I | 30 | III (低价值/低成本) | P4 | 无差异需求，最低优先级 |
几个实用建议
不要被分数"绑架"：RICE 分数是参考，不是圣旨。战略性需求即使分数不高也可能要做。
考虑依赖关系：有些需求之间有先后依赖（如必须先做 A 才能做 B），排序时要考虑。
预留 buffer：不要把迭代排满，留 20% 的空间给突发需求和技术债。
定期回顾：每个迭代结束后回顾需求池，已上线的需求效果如何？暂缓的需求还需要做吗？
沟通比排序更重要：优先级排序的目的不是得到一个"完美的排名"，而是让团队对"先做什么"达成共识。
┌─────────────────────────────────────────────────────────────┐
│ 需求排序黄金法则 │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 1. 基本型需求 (Bug/合规) 永远最优先 │ │
│ │ 2. 用 RICE 量化排序期望型和魅力型需求 │ │
│ │ 3. 用四象限找出 Quick Wins 优先执行 │ │
│ │ 4. 用 MoSCoW 在版本内做最终取舍 │ │
│ │ 5. 考虑战略价值对排序做人工调整 │ │
│ │ 6. 与团队对齐后才是最终的优先级 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘八、实践练习
练习 1：建立你的需求池
选择一个你熟悉的 App，从以下渠道收集 10 个需求：
- 应用商店差评（3 个）
- 你自己使用中发现的问题（3 个）
- 与朋友讨论得到的建议（2 个）
- 竞品有但该 App 没有的功能（2 个）
用需求池模板管理这些需求。
练习 2：KANO 分类
将练习 1 收集的 10 个需求用 KANO 模型分类。
练习 3：RICE 评分
选择其中 5 个需求，用 RICE 公式计算分数并排序。 对比你的直觉排序和 RICE 排序，有什么差异？为什么？
练习 4：综合排序
结合 KANO 分类、RICE 分数和四象限分析，给出最终的优先级排序。 写出你的决策理由。
本节小结
┌──────────────────────────────────────────────────────────┐
│ 本节核心要点 │
├──────────────────────────────────────────────────────────┤
│ │
│ 1. 需求来源多元：用户、数据、内部、竞品，多渠道收集 │
│ │
│ 2. 建立需求池进行统一管理，记录来源和上下文 │
│ │
│ 3. KANO 模型将需求分为 5 类，帮助理解需求本质 │
│ │
│ 4. RICE 公式量化评估优先级：R x I x C / E │
│ │
│ 5. MoSCoW 用于版本内的最终取舍 │
│ │
│ 6. 四象限图直观展示价值与成本的关系 │
│ │
│ 7. 实际工作中综合使用多个框架，没有银弹 │
│ │
│ 8. 沟通对齐比排序本身更重要 │
│ │
└──────────────────────────────────────────────────────────┘上一节：02 - 用户调研方法 | 下一节：04 - 用户旅程地图