编辑导语：不管是新业务，还是已经成熟的业务，一般都需要进行需求调研。那么，需求调研该怎么做呢？本文作者从需求调研的准备工作、目的分析以及调研方式这三个方面，探讨分析怎么才能快速开展需求调研，希望能给你带来帮助。

文章将从需求调研的准备工作、需求调研的目的分析、需求调研的方式选择三个部分出发，探讨我们应该如何准备才能快速开展需求调研。

一、需求调研的准备工作

1. 基础功，提升沟通能力

需求调研的准备工作，第一项我认为是“沟通能力”，这也是平日需要磨炼的基本功。

我曾经自诩沟通能力很强，直到有一次和同事共同进行业务调研，同事给我的反馈是：沟通的目的性太强了，容易引导用户。他说产品经理是一群逻辑思维突出，目的性很明确的人，但是在和用户沟通的时候，应该多倾听用户的声音，挖掘背后的问题。而不是利用逻辑，引导他们去回答指定的问题，否则都没办法去发散思维，发现更多的可能性。

刚开始，我还不太理解，觉得调研不就是了解问题之后，验证这些问题是否真实嘛，内心有过一丝委屈和不解。直到后来仔细观察他和业务人员的沟通氛围、提问的技巧才发现，自己有些时候确实不是在做沟通，而是在表达（如果要正名，我应该说自己“表达能力”很强，而不是“沟通能力”很强）。

“表达”和“沟通”的区别在哪里呢？

表达是单向输出的状态，将自己的想法“灌输”给对方。而沟通则是双向的交流的过程，双方能换位思考，使用相同的“语言体系”，在洞察对方的语言表达习惯、思维方式上进行你来我往的交流。

而实际的调研中对产品经理提出了更高的要求，通常需要产品经理调整自己的表达方式，让被调研的用户觉得这个人和我在一个层次上，我能轻松理解他说的内容，我们能顺利地沟通，并且聊得很开心。说难听一些，产品经理们在调研的过程中，应该少一些自我，多一些谦卑与倾听，就能有意想不到的收获。

一个简单的例子，我司业务人员在称呼销售人员的时候，经常使用“小助理”一词，那么在调研的时候，就不要将“小助理”改为“销售助理”“销售人员”“销售”等词汇。而是应该和业务统一步调，避免无意制造沟通的障碍和增加思维切换的成本。

除了要注意双向信息的交流，还应该有敏锐的观察力，能识别用户是否在撒谎或者隐瞒什么事情。因为人都是趋利性的，会潜意识美化自己的行为，如果发现用户在沟通的过程中有以上行为，需要有适度的引导或者话题铺垫，卸下用户的戒备心，发现事情的真相。

在需求结果的实地调研中，有一件印象很深刻的事情。

当时团队上线了客户的余额管理体系，能帮助小助理从手工登记客户余额的繁琐工作中脱离出来。UI 小姐姐站在一位小助理的身后（想观察交互体验来着），看着她用Excel表格一个一个地登记客户的名称、充值的金额、订单消费的金额、剩余的余额……UI 小姐姐问：“你为什么为什么自己做表格，不用导出功能啊？”结果小助理没好气地瞪了她一眼，说了句大区经理需要，就继续制作Excel表格了。

我了解情况后，先和小助理解释了一下我们是产品团队的（消除戒备，她以为我们来是盯工作进度的），最近上线了一个客户余额明细导出的功能，她制作的表格，可以通过系统10秒钟就导出指定客户的余额信息（提供帮助，获得信任）。

然后小助理情绪明显转变，毕竟要 1-2 个小时才能做完的工作，10 秒钟就能搞定了。接下来深入沟通后才发现，这是完全不必要的工作——原因在于产品上线后的系统培训和功能同步做的不到位，也由于人员对的互联网认知层次问题，大区经理并不知道自己可以通过查询+导出拉取客户的余额数据。

为了分解自己的工作，大区经理转而让每个小助理上交客户的余额表，而小助理们的信息系统的操作经验更不足，就懂得一个一个的查询客户名称后登记到表格，再提交给大区经理。

这对人力是多么可怕的消耗啊！

2. 开始准备，善用工具

聊完虚的但重要的事情，现在正式开始实际的准备工作吧，工欲善其事必先利其器。

李诞在他的《李诞脱口秀工作手册》中提出过：我们怎么提高读稿会（所有涉及创作的会都适用）的效率？带东西来。不要空手踏入任何一个会议室，把稿子写好了再来，哪怕是你们创作小组开会，也该写好了初稿再聊，哪怕只写几个想法，也得有东西再开会。还是那句话，写不好你还写不坏吗？

挺有意思的观点，产品的需求调研也是一样的，不要贸贸然就跑去找业务聊，时间也是成本。提前准备一份调研大纲，工具可以是思维导图或者Word文档，甚至Excel表格。形式不重要，重要的是能够达成调研的目标。

在调研开始之前，我们最好可以编写一份调研清单，设定好数据分析的计划，然后再根据目标去拆解，设定调研的内容大纲。没有提前规划好要什么数据、数据怎么用，就设计了调研内容的坑，我是踩过的，看看这篇帮你避坑：《案例实战|我在产品MVP中，踩到的调研问卷坑》。

如果你是通过调研问卷来获取用户需求，公开的免费软件有问卷网（更专业）、腾讯问卷（轻量化），链接的文章中略微讲解了两者之间的差异，酌情选择吧~

另外我自己还常用UML 工具梳理核心的业务流程，然后单独列出要重点了解的问题点，比较不容易遗漏。

PS：Mac用户可以使用 Process on 的在线流程、思维工具，Windows 用户可以下载 Visio，功能基本差异不大，体验感也差不多。

这里有一个小技能点，需求调研并不都是以慎重约定、正儿八经的会议形式发生，甚至只是在偶然的谈话间完成的。和几个核心的业务人员保持好联系，及时提供帮助，在平日里就可以无压力和他们请教一些问题啦。

如下图，就是在正式的业务调研开始前整理出来的流程，对接下来的具体问题调研有很大的帮助（当然，你也可以用称这种方式为一对一的业务访谈）。

△某MCN机构的核心业务流程

二、明确需求调研的目的

明确需求调研的目的，也是调研的准备工作的一部分。这里基于笔者自己的项目经验，将调研的目的分为两种。

1. 新业务调研，主要在于

• 市场洞察
• 创意验证
• 了解用户痛点
• 渠道信息搜集

《案例实战|我在产品 MVP 中，踩到的调研问卷坑》，这一篇文章就是针对新业务的调研发起的，附带着了市场洞察、创意验证、了解用户痛点的目的，不再赘述。

渠道信息搜集不属于严格意义上的新业务调研的形式，成熟业务中也会用到，只是一般发生在获客的环节，所以我放在了新业务调研的维度。

大家在注册、首次登录一些产品的时候（特别是 SaaS 产品）应该有遇到过，网站会弹出页面，问“你是在哪个渠道了解到我们的产品的 ?”这种调研的形式，我理解的是：要么是产品获客的链路不畅通，无法通过线上数据标记自动化识别用户的来源；要么是为了做客户线索的分层、清洗，设想如果是哪个渠道来的都不愿意填，体验产品的意愿度就非常低了。

2. B端成熟业务的调研

以前写过一篇总结《B端需求调研，善用“人、场、文”三字诀》，内容虽然比较单薄，但是框架性的思维依然有效。接下来做一些补充。

1）了解企业未来发展方向，制定部门级的 OKR

这一项比较特殊，主要是面向企业的管理层级别的。OKR 是互联网大厂们比较常用的“绩效、激励”工具，一般是由上至下制定战略，由下自上承诺结果。

作为产品线的管理者，我经历过研发部OKR制定和落实的全过程。当时还在公告上书写：我们基于公司的战略方向，一起自发设定了技术部门的目标。这些目标有挑战难度，往往需要你付出很多额外的时间和精力，如果 KR 证明无效，会被快速调整、重设。

2）了解业务流程、难点，获取需求优先级判断依据

最常见的就是针对业务做的需求调研，主要是为了确定业务流程、难点以及排需求的优先级。

在第一篇文章《4000 字总结 | B端产品规划和 roadmap 怎么做？》提过 RICE 原则，B 端需求的择取也是一个不小的话题，大家可以酌情选择 1-2 套好用的、证实有效的方法论（如 KANO 模型、四象限原则等）去使用。
方法不在多，重点在实践，都说产品是 10% 的学习 + 20% 方法论 + 70%的实践。

3）了解需求上线后的使用效果

上文讲述的一个案例，就是对需求上线后的使用效果做的实地观察和访谈，不再赘述，也有些产品会在网页中弹出功能的调研（如墨刀的功能 tips 调研）或者弹出 NPS 评分。

△墨刀的功能tips

三、选取合适的调研方式

絮絮叨叨说了不少，明确了需求调研的目标，就要选择具体的调研方式啦，我们以优势、不足和适用场景来抛砖引玉。

1. 调研问卷

1）优势

能快速的搜集大量的用户反馈。

2）不足

• 问卷发放的渠道成本高
• 搜集来的问卷有效性低于其他调研方式，需要进行多轮数据清洗、分析

3）适用场景

创意初步验证或者需要大量的结果反馈、大样本的数据分析时使用。

2. 焦点小组

1）定义

是收集信息和资料的一种重要方法，是通过召集一组与研究主题有关的同类人员对某一研究议题进行讨论，得出深入结论的定性研究方法（MBA智库）。

2）优势

与头脑风暴有异曲同工之妙，容易激发大量想法，能够短时间内快速搜集到大量信息。

3）不足

• 对主持人有很高的主导会议的要求，需要有结构性的提问，在有效的时间内讨论到所有的问题
• 选取的样本量小，讨论的结果有局限性

4）适用场景

有主题性的问题的自由讨论、测试新概念或者产品的可用性时可以使用，人员可来自于各个专业、业务方向。

3. 头脑风暴

1）定义

可分为直接头脑风暴法（通常简称为头脑风暴法）和质疑头脑风暴法（也称反头脑风暴法），前者是在专家群体决策尽可能激发创造性，产生尽可能多的设想的方法，后者则是对前者提出的设想、方案逐一质疑，分析其现实可行性的方法（MBA智库）。

2）优势

类似焦点小组，常有天马行空的想法和惊喜产生。

3）不足

对发言者的专业素质有一定的要求。

4）适用场景

• 个人理解头脑风暴和焦点小组的区别，主要在于聚焦于问题去发散还是天马行空的发散
• 我们在实践中会通过参与的人员来决定使用焦点小组或者头脑风暴。通常对于职级或者资质比较接近的专家，如产品小组，需要大量的想法和创意的时候，我们会采取头脑风暴。

焦点小组与头脑风暴都是比较成熟的定性研究方式，市面上有很多案例可以查询，笔者不敢自称专家，仅在此抛砖引玉。

4. 用户一对一访谈

1）优势

深度访谈效果明显，避免用户在群体讨论中被带偏，隐藏自己的真实想法。

2）不足

• 对产品经理的知识储备、业务认知深度要求较高
• 调研结果受被调研人员的表达能力、业务素质的影响

3）适用场景

适合对资深业务专家、中层管理者，在安静、隐私性相对较好的环境中使用。

5. 轮岗实习

1）优势

• 产品经理能深入到业务一线，发现实战中的业务痛点
• 和一线业务人员建立起良好的同事关系，有利于需求上线后的推广、运营

2）不足

调研成本高，人员紧张的小企业并不太支持这种方式。

3）适用场景

“激励相容”，支持产品经理深入一线的企业管理理念和愿意进入一线实习的产品经理，两者配合才能取到效果。

以上介绍的调研方式并非互相冲突的，有些场景下，比如从 0-1 的项目规划时，可能需要选择各个部门的业务代表做焦点小组访谈，然后就具体的业务问题做一对一的用户访谈，在有条件的情况下还需要产品轮岗、实地体验，需要根据场景灵活选择调研方式。

对于复杂度比较高的业务，还需要进行多轮调研、访谈才能梳理出完整的产品规划来。

最后总结一下，快速开启需求调研的方式：

• 有效沟通，对信息去伪存真
• 明确调研的目的，以及提前准备调研大纲
• 选择正确的调研方式

本文由@RaRa 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于 CC0 协议。