需求调研 | PM_成长研究所

type

status

date

slug

summary

1、什么是需求调研

以识别需求根源、收集未经加工的原始需求为目标，一般通过访谈/问卷的形式，过程中明确调研需解决的业务问题、需求的真伪，并形录音/笔记的记录，完成需求池初稿或项目原始需求记录的过程。

2、需求调研的构成

3、需求调研的关键过程

3.1、明确需解决的业务问题

1】识别问题类型

0-1（未做需求）

1】目标聚焦（定位项目目标）

2】角色与动作（谁、他的工作职责与动作是什么）

3】场景与流程（谁、什么场景做什么，处在什么流程，结果是什么）

4】数据指标（如何定义功能上线的使用情况）

5】影响范围（有没有对现有功能造成影响）

6】需求范围（项目需求）

1-2（迭代需求）

1】目标聚焦（分析现状及产生原因，定位痛点）

2】角色与动作

3】场景与流程

4】数据指标

5】真伪判断（需求真实性分析）

6】影响范围

7】需求范围（需求池）

2】方法

五步访谈法：

目标聚焦：明确调研需解决的业务问题。

角色采样：按流程节点选择访谈对象。

场景化提问：采用“当前如何操作？遇到什么障碍？理想状态是什么？”的提问结构，避免引导性提问。

5Why追问：针对用户提出的解决方案（如“需要增加筛选字段”），连续追问底层原因，直至触及核心痛点。

全场景建模：输出“谁在何时何地，通过何途径，完成何目标”的场景卡片，形成需求矩阵。

5W2H分析法

通过七个问题全面思考需求的各个方面

What：用户遇到的具体问题

Why：需求背后的根本原因

Who：目标用户及其特征

Where：需求产生的场景

When：需求频率和时间节点

How：解决方案构想

How much：成本效益分析

3.2、需求真伪的判断

1】真需求的三重验证标准

行为一致性：用户操作路径与表述需求匹配度>80%

价值可持续性：解决方案在18个月内仍产生净收益

系统适应性：不破坏现有架构核心原则（如安全/性能）

2】伪需求的6大典型特征

特征类型	案例表现	根因剖析
解决方案绑架	“我要更快的马” → 实际需要高效交通工具	用户混淆需求与解决方案
场景缺失	企业用户要求区块链溯源，但实际无假货风险	跟风技术而未验证业务必要性
个体偏好泛化	1个用户投诉按钮颜色 → 要求全局修改	将特殊个案误判为普适需求
补偿性诉求	因加载慢要求删功能 → 实际需优化性能	用户将系统缺陷归因于功能设计
理想化幻想	“希望自动生成完美方案” → 无视现实约束	脱离技术可行性或商业成本
路径依赖陷阱	财务坚持Excel报表 → 拒绝系统自动化	旧习惯阻碍更优解决方案实施

其中，解决方案绑架、个体偏好泛化、路径依赖陷阱在实际调研中出现的频次相对较多，在需求调用过程中可通过伪需求的典型特征，判断需求的真实性。

3】真伪验证方法论

方法1、场景还原法

方法2. 行为数据交叉验证

通过用户表述与实际功能数据分析结果进行对比，进而分析需求的真伪。

方法3. 需求真实性指数参考测试

计算公式：

需求真实性指数 = 问题频率 × 影响程度 / 解决成本

指数>1：优先解决（真需求）
指数<0.5：暂缓（可能伪需求）

案例：

问题：销售抱怨合同审批慢（日均发生5次）
影响：每次延误导致丢单风险15%
解决成本：需投入20人日开发
指数 = 5×15% / (20/30) = 11.25 → 强真需求

方法4. 反向压力测试

三连击追问法：

问题1：需求不存在会怎样？（判断用户对需求的程度）

问题2：其他方案是否更优？（发现更优的解决方案）

问题3：半年后该需求是否仍有价值？（预判需求）

方法5、防误判三重机制

黑暗效应分析法

强制思考：如果此需求失败，根本原因会是什么？

例：智能客服项目预判失败原因：

→ 用户习惯人工服务（需设计强制引导）

→ 知识库覆盖率不足（需分阶段上线）

2、反共识决策原则

当出现以下信号时需启动二次验证：

✅ 所有干系人一致赞同的需求

✅ 零成本零阻力的“完美需求”

✅ 竞品全部具备的功能

3、过程动态追踪

✅ 上线前需求验证

✅ 上线后A/B测试

✅ 上线后相关数据指标监控及分析，报表输出

3.3、需求池

90%以上的需求池

需求名称	需求描述	需求提出人	提出时间	需求优先级	需求计划排期	需求状态
ㅤ	ㅤ	ㅤ	ㅤ	ㅤ	ㅤ	ㅤ

记录需求池的目的：

1】需求调研的目标之一是记录需求方的原始需求，所以不能单单有需求名称、还要有需求方的原始需求说明。

2】需求调研的目标之二是识别需求根源，但如果没有记录需求调研的过程，容易出现需求一直沉积在需求池或对当时沟通内容、想法有遗忘的问题

3】任何事情都要有结果，需求也如此，需求的结果是形成解决方案，并开发测试验收上线，以及上线后的分析，进一步优化，如果有多次改动的解决方案，往往回顾的时候是不记得为什么要改的，会增加需求或版本的复盘难度。

优化后的需求池

需求名称	原始说明	需求调研	需求分析	优先级	需求计划排期	提出人	提出时间	需求状态
xxxxx（明确表达需求含义）	目标：逻辑：预期：	1】需求类型 2】需求目标 3】需求真伪 4】角色与动作 5】场景与流程 6】数据指标 7】影响范围 8】需求范围形成需求清单输出或识别伪需求	1】流程：影响的用户主核心流程 2】设计：页面交互与内容展示 3】逻辑：详细功能逻辑说明（前端交互与后端逻辑）形成解决方案输出	P0 P1 P2 P3	25-07第三周迭代版本2.8.0（上线时间：xx）	部门-xxx	25-07-22 07:56	待评审已下发开发中测试中验收中已上线

4、需求调研的工具

4.1、调研模版

✅ 明确调研的目标

✅ 明确调研的维度与分类

✅ 明确调研的结果

5、差异化补充

saas产品在需求调研时，需着重考虑的一点是：调研的角色与动作、场景与流程与公司的标准化产品的相似或差异程度： 相似：延用标准化产品 差异：如何个性化/是否可转化为标品

6、需求调研的结果

为需求分析服务，形成需求清单输出、以及识别出伪需求，调研要完成这两项，形成调研结果输出，并记录到需求池或项目需求内。

1】形成需求清单输出

2】识别伪需求

7、读完本篇文章的结果

需牢记需求调研方法论，真实需求调研时，业务方提出一个需求，你应能够通过这套方法论快速响应并把需求确认清楚，而不是沟通后再分析，会增加沟通成本及不必要的时间损耗，同时这也是展示一名产品经理专业程度的第一环，尽量不要给对方留下不专业的印象。