编辑导语:做好实际业务调研，一定程度上有助于产品经理更好地了解客户需求，进而推动产品功能的合理迭代，提高产品优化效率。需要注意的是，在不同的业务阶段，产品经理的业务研究方向可能有所不同。在这篇文章中，作者阐述了如何对B端产品进行商业调研，我们一起来看看。

B端产品业务调研体验有三个层次，第一阶段是售前，第二阶段是售中，第三阶段是售后。这里定义的售前是指合同未签或项目未立项，售中定义为合同已签或项目已立项，需要做更详细的业务调研，售后定义为线上交付。

每个人都讲究一个过程。有了好的流程，更容易一步步成功。对于B端业务研究，也要有其流程。

研究流程可以制定为:确立各阶段的研究目标，根据研究目标沟通选择各阶段的研究人员，根据研究目标和人员选择各阶段的研究形式，然后制定研究计划行程，记录研究结果，最后分析总结输出。

记录工作行动的产出是一个好的工作习惯。将上述过程用模块记录下来，其实就是一份业务调研分析报告。

如果产品已经非常成熟，产品经理可能就没必要频繁参与售前了。如果产品还在建设阶段，产品经理有必要参与售前。有了足够的接触，才能更加了解B端市场和痛点现状，对产品规划很有帮助。

下面是产品经理参与售前需要做的一些事情。

如果产品经理要参与售前，就要知道产品经理在这个行动中想要达到什么目的。

销售B端产品，需要根据客户目前的业务情况提供解决方案，对于产品经理来说，需要提供解决方案。

要达到提供解决方案的水平，需要了解当前的业务情况和客户的普遍期望，能够提供的解决方案范围在产品经理所在公司的产品范围内。

在调查之前，你必须熟悉你负责的产品范围和未来趋势，甚至公司的其他产品也需要熟悉。只有供需双方匹配，才有机会达成合作。如果发现预售后没有下一步，就不需要导出方案了。

要提供一个计划，至少要有一个计划模板(没有网上搜索，毕竟模板是经过一定的经验形成，然后根据公司的实际情况进行调整)。如果你熟悉计划模板里每个模块都要写什么，你心里自然就知道你知道什么，你还需要知道什么，你需要知道谁。

售前阶段的业务调研通常是第二次会议。第一次见面往往是业务人员或营销人员与甲方有过初步接触，更新或更换一款B端产品的目的是提高管理效率，降本增效，涉及面广，需要高层人员推动决策。因此，一般情况下，甲方的高级管理人员和业务负责人会参加售前业务调研行程，这往往是深入的现场访谈(由于疫情原因，电话会议访谈是必要的)。

在现场深度访谈中，甲方高管或乙方业务人员会先做开场白，要特别注意甲方开场白的记录，这往往是指战略层面的大局，极有可能在撰写方案的背景总结中引用，提出的方案要有回应。

深入现场采访，开场白后可能会有产品演示(如果有现成产品的话)。无论是演示详细还是只讲演示过程，都可以在演示前询问客户的意见，如果已经知道客户在演示过程中需要解决或注意的点，就可以重点讲解。

然后是沟通业务需求的步骤，这是调查业务需求的主要场所。产品经理要注意控制市场，引导业务人员沟通重点。如果研究达不到目标，方案输出不了，产品经理以后还得继续再了解，效率低下。

为什么要控制市场？如果你有更多的售前参与，你会发现会有什么现状。有的业务人员目标明确，有的业务人员稍微马虎一点容易聊天然后去外地，然后时间过去了就下班了。现场业务人员可能经常会谈一点业务，谈一点业务，或者不谈业务，也会影响后续方案的产出。

作为产品经理，需要指导业务人员，逐模块沟通对应的当前流程和每个模块关键点的现状，也要知道每个流程和关键点的问题和期望。良好的现场控制和指导，即使在现场，记录的业务调研内容也会向相关业务人员再次确认，做好这一点后才能做出分析和输出方案。

在售前业务调研阶段，可能需要产品经理将需求转化为脑海中的功能，并结合现有产品的迭代来回答甲方业务人员的问题。如果不确定，不要轻易承诺，做好记录就好。

预售阶段输出方案后，如果甲方适合该方案并报价，则签订合同，项目成立。会有项目启动会，项目计划一般会在项目启动会上介绍。

大项目往往有项目经理做项目相关的事情，小项目可能有产品经理做这些事情。无论项目大小，产品经理做业务调研还是有必要的，但是这个调研的目标是能够输出一个完整的需求规格文档，交付给开发，也就是产品设计。

调研人员以业务人员为主，调研形式可能还需要现场调研或远程分享会，沟通详细的业务需求。销售中期的调研计划是包含在项目计划中的，即使有项目经理，产品经理也要参与这个计划的制定，因为先做哪个部分，除了考虑业务端的诉求，还要考虑产品的最小闭环和产品迭代的节奏。

根据售前阶段的业务调研，可以梳理出核心的业务流程图，也知道我们要做什么样的产品(我们会为谁提供什么服务)。有了项目计划书，我们会根据项目计划书中的各个模块做详细的业务调研。在做每个模块的业务调研时，要更详细的了解业务人员的使用场景，谁在用，为什么用，是否经常用，怎么用，不用时会怎样，用了又会怎样。

每个点可能都有一个使用过程，要记录好。如果可能的话(需求可以在脑海中理解后立即分析，转化为功能)，可以现场给出一个功能方案，告知业务人员是否有可能提供某个功能来解决问题，或者再提供几个功能方案，告知客户每个功能方案的优缺点，让业务人员对供应商给出的建议是什么，业务人员选择哪个功能方案有一个清晰的认识。

在研究过程中，你可能会遇到以下情况:

实地分析，有不一致的诉求，但要跟业务人员说清楚，矛盾的诉求不能提，业务人员会理解。

业务人员提出的需求可以当场分析。没必要，但可以当场向业务人员解释为什么没必要。

业务人员提出的需求超出项目范围，或者不清楚是否超出范围。不要轻易做出承诺，而是先给出提示或记录，内部沟通好之后再给出明确的说法(有几个衡量标准可以参考，是否提出需求最低不能成交，会带来什么影响，对业务方有什么价值，对自己有什么价值)。

可能有些业务人员会考虑很多，提出的需求也给出了功能方案。这时候就需要考虑业务人员给出的功能规划是否与当前版本的产品功能一致。如果现有的功能可以在不造成任何麻烦和达到目的的情况下稍微转换一下，可以和业务人员沟通一下是否有可能稍微转换一下。在我的接触过程中，只要我说清楚，大部分甲方的业务人员都可以沟通。

业务人员提出的需求可能会影响现有产品的功能来满足这种需求。多想想有没有第二种解决方案。如果真的没什么好跟客户解释的，会有什么影响？如果是必要的需求，也可以考虑配置一下，看看能不能解决。

如果产品是做出来的，不是独立定制的。大脑在研究的时候要考虑如何迭代业务人员对产品提出的需求，会影响产品的迭代，在研究的时候就要提出来。

在现阶段的研究过程中，我们可能遇到的问题不止上述几个。顾客是上帝没有错。我们可以合理的对待客户，但是不要说客户说的话。没有项目原则和产品原则，项目就会乱七八糟。

在这个阶段，甚至更早或更晚，需要调查产品上线时是否有数据迁移的需求，这也可能是实施者的责任。

做销售中期的业务调研，如果能现场分析需求，现场将需求转化为功能，可以提高效率。如果涉及的内容居多，那就先做个记录，调查完后再把需求转化为功能，然后再和客户沟通。

产品已经推出，这个阶段的业务调研相对容易一些，针对性也不强。研究人员通常是业务人员，通常进行远程交流。

如果是SaaS租赁系统，这一阶段的业务调研更多的是业务运行情况如何，有没有需要解决的问题，产品提供的服务是否能满足要求，可能会留在后续；如果是独立部署，在了解客户使用产品的实际情况下，也可以向客户介绍其他模块。如果是定制，了解客户是否有新的要求，是否在公司产品范围内。如果合适的话，可能会有开始下一个合同的计划。

这个阶段的业务调研也可以在产品反馈中记录结果，这样就有了持续优化产品的源头。

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

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