B端产品，如何做好业务调研？
众所周知，B端产品和C端产品所提及到的用户，是不一样的群体。首先从目标群体看，C端产品是面向广大消费者，用户对于产品的需求是一致的，因此C端产品的用户往往都是个人；而B端产品，面向的群体可以是外部用户（采购SaaS软件），也可以是企业的内部用户，并且用户群体还会区分多角色，不同的角色的需求也是不一致的，因此在调研方式上，B端和C端也会有很大的区别。
因此，笔者将根据过往的工作经历，总结了一下B端产品的调研方法。
一、明确调研的目的
在开始调研之前，需要明确此次调研的目的及目标，因为明确调研的目的，才能找到合适的调研角色。B端的需求、工程量都很大，一旦方向搞错，将会浪费很多的人力、物力。
那调研的目的有哪些呢？我认为可以拆解为这三个部分：战略目标、业务策略、落地执行。
- 战略目标：指的是公司层面的目标，可以通过公司的愿景、品牌发展方向、企业文化等多个方面去分析公司想要达成什么样的结果。
- 业务策略：当总的战略目标制定后，往往会拆分成一个个小的战略目标到不同的事业部，事业部就会根据公司战略目标去制定自己的落地策略，例如要做的项目是什么、涉及到哪些团队、绩效目标/制度是什么、总流程是什么。
- 落地执行：当业务策略明确后，需要根据每一个策略去拆解一线的任务，并完成执行，这个阶段，就需要去明确每一个人需要去做什么事情，每一件事情，都能落地到系统中的细节。
二、明确B端业务有哪些类型的角色
- 战略提出者：一个项目的落地，往往是从上往下去贯彻公司的战略来执行，而提出战略的人，往往是公司的最高管理者——老板，一般老板会针对自身/集团的期望，提出具体的战略方向，再将战略的方向，拆解到不同事业部、部门中去，一般产品经理很难直接调研到老板，因此能够去理解战略的目的，就已经很好了。
- 业务负责人：指对某一种业务负责的人，例如客服业务，对客服业务负责一般是客服总监、客服经理。业务负责人一般是B端产品的终极用户，因为B端产品核心的价值就是帮助业务管理者达成业务目标。因此一般产品经理会与业务负责人调研业务的目标、产品的方向。
- 一线执行者：具体实操系统的用户，保障业务的日常开展，是B端产品的直接用户，也以客服业务举例，一线执行者往往指的是一线客服、客服组长。因此一般产品经理会跟一线执行者调研具体的执行细节，了解详细的业务流程、业务规则。
- 协同方：这里指的是企业内部配合主业务部门开展项目的协同同事，例如客服部门在搭建售后流程时，往往需要供应链、销售的同事一起配合。因此一般产品经理也是了解具体的执行细节即可。
为什么要明确不同的角色，是因为在B端业务中，不同的角色产生的需求侧重点都有可能不一样，例如客服部门需要做一个工单系统：
- 客服经理：期望实现工单数据的监控，能够实时看到每一条工单的处理时效，能够看到不同部门、不同人员的处理情况。
- 客服组长：不同客服组所负责的工单类型往往是不一样的，因此客服组长会期望能够实现工单信息的配置，能够个性化配置工单填写的字段、工单分配的规则、工单的处理提醒内容。
- 客服人员：期望工单的处理流程、交互能够更加简单，在处理工单时系统能够自动填写一些重复的信息，在处理工单时能够提供更多的参考信息辅助，减少页面的跳转。
三、明确调研的方法
在调研时，如果能够掌握恰当的方法，能使调研更加高效、高质量。
- 提前准备调研提纲：当明确好调研对象后，可以提前根据不同的调研对象，准备不同的调研提纲，在调研开始前，提前发给调研对象。调研的提纲中需要包含调研的时间、调研的地点、调研的目的及背景、调研的问题。如果不提前准备，就很容易导致调研过程非常的发散，无法获取到有价值的信息。
- 明确调研顺序：一般调研的顺序，都会从高职级的人员开始，例如客服经理——客服组长——客服人员，按照这样的顺序去调研，好处是能够从上往下去理解“战略-策略-执行”的信息，而如果一开始就找客服人员调研，会很容易就陷入细节中去，导致找不到核心问题。
- 提前研究需求的价值：在一些场景下，产品经理做的需求有可能满足了战略的目标，但损害了一线人员的效益，如果不提前研究好这些信息，这样在调研的时候，调研对象的负面反馈就会成为你的干扰信息。
- 与调研对象保持良好的沟通关系：通过调研，能够使我们跟业务人员的关系拉近，正式的调研结束后，往往后续还会存在很多的小问题需要持续保持沟通。
上述所提到的方法，通常是线下/线上直接跟调研对象进行沟通，但调研的渠道还有很多种，例如：
- 轮岗实习：轮岗是指产品经理深入到一线，直接去上手业务人员的工作，这种方式其实是了解业务的最好方法，很多时候我们只做了设计，但却没有真正去使用系统，这就会导致我们无法很好去理解业务的痛点，都是在凭自己的主观感觉在设计，被动地去接收需求。
- 发放调研问卷：这种方式虽然调研质量没有直接沟通高，但是一种比较高效的手段，比较适合调研对象较多、需要收集大量用户反馈的场景。
在设计问卷问题时，有几个注意事项：
- 控制问卷的长度：如果问卷问题太多、太长，用户填到一半就不想填了，尽管强制他们填写，往往收回来的问卷参考质量都不高，因此需要控制好问卷内容不能太多，并且最好提前告知用户问卷调研的目的，预计填写所需要的时间，让用户能有一定的预期。
- 控制开放性问题：开放性问题不能太多，因为很少人愿意花时间去写一大段的文字。
- 避免诱导性提问：例如不要问“如果上线之后，您会使用吗？”，而是要多用选项去帮助用户答题，例如“XXX功能使用后，您的体验是（a.非常满意 b.满意 c.一般 d.不满意 e.非常不满意）。
四、输出调研报告
完成了调研工作后，我们对业务的整体流程、现状、痛点都有一定的了解，此时就需要输出一份调研报告，并提供给我们的核心调研对象进行查看，目的是为了保证调研过程中双方的理解是没有偏差的，并且一旦发现调研报告有问题，业务同事也可以及时提出，避免在后续的产品设计过程中再出现问题。
调研报告的结构如下：
- 调研的对象：列出调研的对象分别有谁。
- 调研问题及结论：列出每一条调研的问题及调研结论。
- 业务诉求：针对每一条问题，业务是否有对应的诉求，若有，诉求是什么。
- 解决方案：针对业务的诉求，商讨的解决方案是什么。
- 优先级：该问题解决的优先级。
五、总结
以上就是B端产品业务调研的一些技巧及方法，虽然调研的方法有很多，但归根结底的核心还是——产品经理不能脱离业务去做设计，业务是需求的根源，产品经理要通过自己的专业力去贴近业务、熟悉业务，只有这样，我们做出来的东西，才能更符合业务的期望，解决核心的痛点。
本文作者 @Silence 。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
