中后台产品与业务紧密相连，产品经理需要熟知业务架构和逻辑。其中，业务调研是一个熟悉业务的重要方法。
所谓C端，即围绕个体用户衣食住行、吃喝玩乐的产品。与之对应的，B端用户则面向企业，比如CRM、OA系统，这些产品更注重解决企业用户在业务和内部协同中遇到的问题。
与C端产品不同的是，B端产品有更稳定的需求、更注重解决实际矛盾和需求，围绕提升利益与效率的目的进行规划。
初做B端、尤其是中后台产品，相信大多数产品小白会遇到这样的场景：
经理让我去找业务调研，但我并不知道问哪些问题；在与业务方的沟通过程中经常会被抢去主导权，在对方说完“我需要在这里加一个XXX的功能”后，扔下一个冷风中凌乱的我。
上一段中提到，B端产品的本质是为了更好地解决业务问题、为企业赋能，所以是本质决定了产品经理要熟练后台架构和业务逻辑 ，每一个功能对应的工作流都有可能对该功能上下游的逻辑产生影响。
产品经理在做规划时，不能仅在自己的角度判断逻辑是否合理，还要站在业务的角度考虑需求背后的价值。
下面我们分别从调研前、调研中、和调研后三个阶段分别展开讲解：
1. 熟悉业务
1）调研之前
产品经理需要主动了解业务背景、对公司业务做初步判断，带着对业务的疑问更有针对性的与业务方进行沟通。
2）调研开始
我们可以围绕以下几个问题进行提问：
a. 询问调研对象在这家公司工作了多久、处于怎样的职位
可以通过工作经验初步判断对方的业务能力，形成颗粒度较大的用户画像，在后期需求分析和工作场景拆解中可以更直接地进行分类。
比如我在调研销售人员时，会对“业绩较好的销售人员”、“业绩较差的销售人员”、“销售组长”、“销售经理”分别写一份调研报告，分析不同类型用户的痛点、爽点、痒点。
b. 基于业务方目前的工作流
产品经理需要了解调研对象日常的工作流程，比如销售人员在联系客户前需要做什么准备工作、一般在什么渠道联系到客户、在联系客户的时候都会准备哪些话术、沟通时客户会经常问到哪类问题、跟进意向客户时会遇到哪些问题以及成单后如何继续维护客户关系。
c. 我们的优势是什么
这一点中需要了解整体背景下公司的业务解决了客户的什么问题、客户要解决这些问题能不能通过别的渠道。
横向对比后，我们可以更清楚地了解到我们公司业务的优劣势。
d. 业务方面对的客户有何共性
了解业务方面对的都是什么类型的客户，这对熟悉业务来说至关重要。
拿CRM中的销售漏斗来说，产品经理要对公司的潜在客户、意向客户、成单签约客户及复购客户进行分析，赋能销售人员提高对不同客户的跟进效率。
2. 收集需求
1）收集线下表格
收集需求阶段，实际上是对工作流中的痛点进行拆解，产品经理要了解业务方的工作哪些是在系统中进行的、哪些是在线下进行的。
有些销售团队仍使用Excel做日报、组长每天在表格中统计组内工作量，这种方法效率低、数据安全无法保障。
既然线下统计的方式效率低且对管理不利，那我们能不能将这部分工作转移到系统中沉淀下来呢？
产品经理在调研时可以收集他们正在使用的线下统计表格，根据他们的统计需求来设计具体的解决方案。
2）了解人效的考核指标
不同销售团队会对人效的计算有不同要求，挖掘线索、跟进线索、转化客户等不同环节都在激励着销售人员。
产品经理可以考虑，能否将这些指标沉淀到系统中的数据看板；这样做既能协助他们量化日常工作完成情况，也能减少手动统计的低效劳动和错误率。
3）跨部门协作中遇到的异常问题如何处理
协作是个永久的话题，组织通过部门分工与团队协作完成业务流程的闭环。然而，实际团队协作中常常会出现各类问题影响整体进度。
产品经理在调研中需要了解业务方在跨部门协作的过程中信息流是否通畅、任务分工是否明确，具体表现为遇到问题能否直接找到相关责任人、能否高效快速解决协作问题。
三、调研产出
调研结束后，除了需要将调研总结同步给业务方确认，产品经理还需要产出用户画像、业务流程图及工作场景分析，这些产出都是为了即将到来的需求分析环节。
用户画像怎么画？业务流程图是什么？调研时业务方表达出的需求就是真正的需求吗？我们应该如何通过调研结论挖掘出需求的真容呢？
在之后的文章中，我会将自己遇到过的“坑”为你总结出来，共勉。
