年薪30万的B端产品经理，是如何做需求调研的？

编者按：本文来自微信公众号“三节课”（ID:sanjieke01），作者：王志剑，编辑：王小疼，36氪经授权发布。

大家好，我是三节课合作讲师、资深B端产品专家王志剑，拥有超过12年的软件产品经验，对企业信息化规划、需求开发、需求管理具有深度研究。

众所周知，在C端流量争夺成为红海的背景下，B端市场无疑是充满机遇的蓝海，并已成为近年来的风口。互联网巨头和新新玩家纷纷进入这个市场，希望借此挖掘最大的市场价值。

实际上，不论是B端还是C端，在产品定位方面，对于提供服务的组织来说，目的都是降本增效。相较于C端，在产品设计方面，B端产品对业务知识和经验有更高要求，在产品交付方面，B端产品在朝C端的更易交付、使用靠拢。所以，对于原来从事C端的产品同学来说，想转向B端的话，需要在产品设计这块有所补强。

今天，我也想从自己多年2B业务工作实践经验出发，同大家一起一步一个脚印，探寻2B产品设计的核心环节——需求调研的破局之道。以下是自己的一些经验心得，希望可以为你带来启发：

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

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

要回答好这些问题，我们需要做需求调研，这一2B产品设计的核心环节

2B产品的需求调研方式，我个人首推通过面对面访谈+现场走访。就像之前我们说的2B产品注重流程，2B产品经理要了解企业业务需求，最好的方式就是通过客户（买单的人）/用户（实际操作系统的人）访谈，面对面地和用户沟通、倾听、交流。部分复杂业务最好能到现场看看实际作业过程，这能让产品经理更具象化了解业务细节。

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

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

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

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

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

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

产品定位：回答在客户/用户心中，产品有什么价值？

例如，某OA产品定位为协同办公，采用轻前台，重后台的设计模式。

关于协同办公，我们讲过企业存在的意义是在当今的工作中，企业组织一群人能创造出比一个个独立的个体更大的价值。一群人聚集在一起，就需要协同配合，协同办公这个理念就源于此。

关于轻前台、重后台，是指用户在前台，系统能根据用户所需，提供易用、够用的功能。但2B产品要满足不同企业的个性化管理、业务需求。这就要为系统管理员提供灵活的后台来响应前台的需求。

这样我们就能理解这个OA产品的产品定位：是面向企业用户的协同办公，前端很易用，后端很灵活。

向用户了解应用需求

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

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

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

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

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

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

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

上图我提到了几个常见的非功能性需求：

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

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

3.稳定性：2B产品在设计时一定要尽量做到全面规划。前面说到产品定位要回答产品做什么？做给哪些人用？做成啥样？回答清楚这3个问题，2B产品的设计就不会随波逐流。我们日常的2C产品比较喜欢刷存在感，时不时喜欢更新个版本，很多改版只是做些小调整，比如做个页面改版。目的是让用户有新鲜感。相反，2B产品因更注重用户的操作习惯，所以应更注重稳定性，能不改则不改。

白鸦之前在内部分享会上说，有赞的产品自从推出第一个版本后，就没对导航、页面布局、交互做过调整。我对这句话的理解是：2B产品的每一个设计都要想清楚，不要来来回回不断调整。每一个大调整，都增加了用户的学习成本，稳定性是衡量一款2B产品设计好坏的关键指标。

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

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

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

和用户了解应用需求有2个注意点：

1、需求调研是基于对用户过往的行为、想法的提问，间接洞察真实的需求

2、需求的解决方案应该是产品经理提供，而不是用户告诉产品经理怎么做

有一次我和一个同事A在食堂吃饭，看到前面女生裤子后口袋露出手机的大半截。我打趣地对A说：手机屏幕大是个问题吗？A说现在的女生喜欢追剧、玩游戏、刷短视频，手机屏幕大是刚需。到这里，我们可以挖掘用户的需求是：可以在手机上愉快地追剧、玩游戏、刷短视频。

如果继续问A应该怎么解决，大概率是得不到什么理想的答案。因为A不是手机从业者，他不知道目前屏幕技术发展到什么阶段。如果你是一名手机硬件产品经理，你了解目前屏幕技术发展到什么阶段，你就知道什么方案可行，什么方案是天方夜谭。

所以说，用户是了解自己的业务，能讲清楚业务需求的人。而产品经理是清楚技术发展，提供解决方案的人。

提供、确认需求调研报告

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

需求调研报告的内容需包含前面的2类需求调研内容。需求调研报告的模板可以参照上面的思维导图。需求调研报告这类动则几十、上百页的文档，如果直接发给客户确认，往往会石沉大海。

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

建议解决方案如下：

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

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

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

主业务流程图如下 ：

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

2、将报告化整为零地确认。

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

我的看法是：按业务流程来划分。因为任何一个用户在一条业务流程中，都只参与其中一部分。

以业务流程为对象来划分，一方面可保持业务流程完整性。所有与该业务流程相关的人，可看到整条业务流程的完整信息，不会出现疏漏。另一方面可减少文档内容的冗余。如果以用户为对象，不同用户在一条业务流程中存在上、下游关系，描述业务时既得先说明TA的上游用户需做完什么（类似前置条件），又得说明TA做完后的后续流程是什么？导致描述不同用户的流程内容时，会出现很多重复内容。

比如，一条业务流程由A、B 两个用户按顺序来一起完成。

在描述A用户负责的业务内容时，需要说明A用户的后续流程内容。这个刚好就是B用户负责内容的前置条件。

小结

做完上面的3步，2B产品的需求调研就算完成了。今天我们讲了2B产品设计的核心环节——需求调研时要做的3件事：

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

雷军有句话：别用战术上的勤奋，掩盖战略上的懒惰。如果战略上的确定性不解决，那么战术上再努力也是低效努力。用在产品设计上，就能更好理解需求调研、分析与需求实现的关系：需求调研、分析是战略方向；需求实现是具体落地的战术。

你也可以上手去试试。希望在未来，会有更多的产品同行在B端赛道上一起发光发亮。