2B产品经理要深入了解、挖掘出客户/用户的真实需求，需要先具备一定的企业业务常识+良好的沟通引导技巧。本文作者给大家提供了三个步骤，来做用户访谈，希望能够对你有所帮助。

当你打开一款2B产品的工作台时，是不是会有个困惑：

• 工作台上一堆的功能列表，到底是从哪来的？
• 哪个产品大神能突发奇想，设计出这么一大堆功能？
• 这些功能到底解决了用户的哪些需求？

上一篇文章《2B产品经理如何快速准确了解一家企业业务》，我们讲了如何对一家企业有个基本的了解，现在我们就可以开始对客户（买单的人）、用户（实际操作系统的人）做需求调研了。

小白可能会问，为什么要大费周章地先对企业业务做一番了解？直接做需求调研不就好了吗？

如果一名2B产品经理真的这么做，大概率会在调研过程中，被调研对象在心中贴上：外行领导内行的标签。

一个2B产品经理不懂业务，却要去做一款2B产品，如果你是用户，是不是会心里发毛？

所以，2B产品经理在需求调研前，一定要对调研内容做到心中有数。这完全不同于2C产品是为了满足个人日常生活相关的需求，只要你有点生活常识，人人都是产品经理，张口就能和用户聊需求。

今天我们继续2B产品设计的第二个环节：需求调研。

2B产品的需求调研方式，我个人首推通过用户访谈。就像之前我们说的2B产品注重流程，2B产品经理要了解企业业务需求，最好的方式就是通过客户/用户访谈，面对面地和用户沟通、倾听、交流。

魔鬼藏在细节里。2B产品经理要深入了解、挖掘出客户/用户的真实需求，需要先具备一定的企业业务常识+良好的沟通引导技巧。

你可以参考下面的步骤来做客户/用户访谈：

1. 向客户（买单人）了解产品定位？

为什么特意把客户和用户分开来说？

2B产品的选型过程更长、更复杂，往往是先在企业内部有过多番讨论的结果。2B产品的客户和用户常常不是同一类人（这里说的客户指为产品买单的人，用户指未来产品的使用人）。客户的需求一般侧重企业战略如何落地，管理制度如何落地，产品能带来哪些额外价值？

因此，2B产品经理在与客户沟通时，要有CEO思维，多从商业（通俗点就是：做生意，你关注什么）的视角去理解对方的意图。

与客户访谈，有利于产品经理站在更宏观视角去理解未来产品的定位。

郝志忠在《用户力》一书中提出，产品设计要先回答产品定位的问题，而产品定位从通俗上来说，要回答：做什么？做给哪些人用？做成啥样？这3个问题。

2. 向用户了解应用需求

与客户（买单人）了解清楚产品定义后，就可以带上准备好的调研问卷，结合上一个环节了解的企业业务信息，找到企业通讯录上的核心用户，来和用户沟通具体的应用需求了。

注意：事先准备好调研问卷，能让你更从容、有针对性地进行用户访谈。

调研问卷，可参照下面的思维导图作为框架：

调研对象、业务角色：相当于我们在招聘网站上看到的招聘岗位、岗位职责。

背景说明：让调研对象先热热身，可以让TA先比较宽泛地聊聊自己当前工作中遇到了什么问题？哪些问题希望通过产品来解决？之前是不是有使用其他产品？对新产品有什么期望？

需求描述、业务过程：引导调研对象结合自己的实际工作场景，描述具体工作细节。产品经理可以初步判断哪些是产品能解决的问题？一般来说，现有单据（如在用的出差申请单）、审批流程（如根据申请人岗位判断需哪些领导审批）、业务规则（如根据申请人岗位对应差旅标准）这类可明确、有逻辑、可结构化的的内容都是产品要解决的范畴。这些都属于功能性需求。

非功能性需求：2B产品用于企业生产经营活动，那么产品经理就需要多一步考虑：除了满足用户的功能性需求，是不是有哪些非功能性需求同样非常重要？

上图我提到了几个常见的：

（1）安全性：有的2B产品的数据就是企业的血液。对于数据泄露、丢失等问题，有的企业是零容忍。产品经理就要重视数据安全的相关方案。

（2）易用性：可参考之前写的2B产品经理的用户体验，都值得再做一遍

（3）稳定性：2B产品在设计时一定要尽量做到全面规划。前面说到产品定位要回答产品做什么？做给哪些人用？做成啥样？回答清楚这3个问题，2B产品的设计就不会随波逐流。

这里插一句：我们日常的2C产品比较喜欢刷存在感，时不时喜欢更新个版本，很多改版只是做些小调整，比如做个页面改版。目的是让用户有新鲜感。相反，2B产品因更注重用户的操作习惯，所以应更注重稳定性，能不改则不改。

白鸦之前在内部分享会上说，有赞的产品自从推出第一个版本后，就没对导航、页面布局、交互做过调整。

个人认同：2B产品的每一个设计都要想清楚，不要来来回回不断调整。每一个大调整，都增加了用户的学习成本，稳定性是衡量一款2B产品设计好坏的关键指标。

（4）性能：这个对一般用户比较抽象，用户一般直观感受是操作时，产品反应速度怎么样（比如打开一个页面不能超过3秒）？翻译成专业术语就是响应时间、吞吐量、并发数这些指标。

（5）可扩展性：这个可理解为产品的灵活性。比如，产品是否需要为管理员提供参数配置、业务建模等高阶功能，满足业务变动、发展的需求，而不需要额外增加开发工作量。

需求优先级：访谈到最后，用户可能洋洋洒洒和产品经理讲了一大堆需求，这时产品经理应要先对用户的需求做一轮概括复述（目的是确认自己是不是有抓住用户需求的核心），然后可以适当引导用户说出其中哪些需求的优先级最高（这是在为后续的产品需求优先级做准备），适当地收敛、聚焦核心需求。

3. 提供、确认需求调研报告

前面我们和客户/用户斗智斗勇地展开了一场场的用户访谈，最终还要通过一个产出物-需求调研报告，让客户/用户了解我们对其需求的理解程度。大家互相做到知己知彼，才能在未来的产品设计、开发中不会出现需求理解错误的尴尬局面。

需求调研报告的内容需包含前面的2类需求调研内容，需求调研报告的模板可以参照上面的思维导图。

需求调研报告这类动则几十、上百页的文档，如果直接发给客户确认，往往会石沉大海。

这有两方面原因：

• 一方面，需求调研报告主要就是复述客户的实际业务和期望解决的问题，并无多少新意，难以引起客户仔细阅读的兴趣。
• 另一方面，人们对这种几十页的正式文本，往往拿起来就有恐惧感，文字阅读本身是反人性。

建议解决方案：

3.1 向调研对象现场讲解主业务流程

尽量用一幅流程图讲清楚被调用对象的主业务流程，个别需要特别说明的子流程，可以补充说明。

建议通过会议的方式，现场向用户演示、确认，因为这个过程可能会有不少思想碰撞，现场的效果最好。

主业务流程图如下：

主业务流程是后续产品设计的主轴，我们可以把它视为未来产品的框架，一旦理解有误，直接影响后续的产品设计、开发。

3.2 将报告化整为零地确认。

在工作中，我们会遇到一个棘手问题：文档到底应该按用户为对象来划分，还是应该按业务流程为对象来划分。我的看法是：按业务流程来划分。

因为任何一个用户在一条业务流程中，都只参与其中一部分。以业务流程为对象来划分，一方面可保持业务流程完整性。所有与该业务流程相关的人，可看到整条业务流程的完整信息，不会出现疏漏。

另一方面可减少文档内容的冗余。如果以用户为对象，不同用户在一条业务流程中存在上、下游关系，描述业务时既得先说明TA的上游用户需做完什么（类似前置条件），又得说明TA做完后的后续流程是什么？导致描述不同用户的流程内容时，会出现很多重复内容。

举例，一条业务流程有A,B 2个用户按顺序来一起完成。在描述A用户负责的业务内容时，需要说明A用户的后续流程内容。这个刚好就是B用户负责内容的前置条件。

通过分开确认不同的业务流程，可以降低确认难度。

做完上面的3步，2B产品的需求调研就算完成了。到这里，我们已经理解了调研对象的详细需求，接下来，我们就可以进入需求分析环节了。

小结

今天我们讲了需求调研时，要做的3件事：

1. 向客户（买单人）了解产品定位？
2. 向用户了解应用需求；
3. 提供、确认需求调研报告。

你也可以上手去试试，希望可以帮到你。

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

题图来自 Unsplash，基于CC0协议