编辑导语：做好实际业务调研，将一定程度上帮助产品经理更好地了解客户需求，进而推动产品功能的合理迭代，提升产品优化效率。需要注意的是，在不同的业务阶段，可能产品经理的业务调研方向也会有所不同。本文作者就B端产品如何做业务调研一事做了解释，一起来看。
B端产品业务调研大体会有3个级阶，第1个阶段是售前，第2个阶段是售中，第3个阶段是售后，此处定义的售前是指还没有签合同或者还没有立项，售中定义为已经签订合同了或者已经立项了，要动手做更详细的业务调研了，售后定义为已经上线交付了。
做事都讲究一个流程，有了良好的流程，循序渐进，更容易取得成功。对于做B端业务调研，也需要有其流程。
调研流程可以这么制定：确立每一阶段的调研目标，根据调研目标去沟通选定每个阶段的调研人员，根据调研目标和人员选取每一个阶段的调研形式，然后制定调研计划行程 ，去执行记录调研结果，最后分析总结输出。
记录好工作行动有输出会是个良好的工作习惯，将上面这个流程分模块记录下来，其实就是一个业务调研分析报告了。
如果产品很成熟了，可能不太需要产品经理经常参与售前，如果产品还在建设阶段，产品经理参与售前太有必要了，只有接触得足够多，才会更清楚B端的市场以及痛点现状，对产品规划是很有帮助的。
下面就分享一些产品经理参与售前需要做的事项。
产品经理要参与售前，就要清楚此次行动产品经理要达到的目标是什么。
要将B端产品销售出去，那必然要根据客户的业务现状提供解决方案，对于产品经理来说那就需要提供方案。
要达到提供方案的程度，必然要知道客户的业务现状以及大体预期，能提供的方案的范围就在产品经理所在公司的产品范围内。
调研前肯定是要熟悉自己所负责产品的范围，以及未来走向，甚至公司其他产品也是需要熟悉的。供需双方相匹配才有机会达成合作，如果售前过后发现没有下一步就无需输出方案了。
要能提供方案，至少是有方案模板的（没有就网上找，毕竟模板是经过一定经验才形成的，再根据公司实际情况调整），熟悉方案模板里的每一个模块要写些什么内容，那自然就知道哪些自己心里大体清楚，哪些还需要了解，需要通过什么人来了解。
售前阶段的业务调研一般是第二次会面，第一次会面往往是商务人员或市场人员和甲方已经有了初步接触，上新或更换一个B端产品更多的目的是提高管理效率，降本增效，牵扯面广，需要高层人员去推动去做决策的，所以一般售前的业务调研行程甲方的高层和业务负责人会参加，往往都是现场深度访谈（疫情影响不得已就远程会议访谈了）。
在现场深度访谈时，甲方高层或乙方商务人员会先做开场白，对于甲方的开场白尤其要注意记录，那往往说的就是战略层面的总体现状，在写方案的背景概述里非常有可能要引用，提出的方案里要回应。
在现场深度访谈时开场白之后可能会有产品演示（假如有现成的产品的话），演示得详细还是只大概演示流程，可在演示前先询问客户的意见，在演示过程中假如已经知道客户要解决或者关注的点可以着重介绍。
接着会有沟通业务需求这一步，这一步就是调研业务需求的主场了，产品经理要注意控场和引导业务人员来沟通关键点，如果调研达不到目标输出不了方案回头还得产品经理继续再了解，会导致效率低下。
为何要控场，售前参与多了，就会发现什么现状都会有，有的业务人员目标明确，有的业务人员稍散漫容易聊着就聊到别的地方去了，然后时间又过去了就要下班啦。在现场业务人员也往往可能会在业务上这聊一点、那聊一点，有的又没有聊到，也会影响后续方案的输出。
做为产品经理就要引导业务人员，按模块来沟通一遍对应的现状流程以及每一个模块的关键点的现状，也了解好每个流程和关键点的问题和预期。控好场以及做好引导，甚至在现场就将所记录的业务调研内容给相关业务人员再确认一遍，做好这些回去就可以做分析输出方案了。
在售前的业务调研阶段可能就要产品经理脑子里将需求转化为功能以及结合现有产品的迭代来解答甲方业务人员的问题了，不确定的也不要轻易去承诺，做好记录即可。
售前阶段输出方案后，甲方对方案以及报价等各方面都合适的话，合同也签了也立项了，会有一个项目启动会，项目启动会上一般也会介绍项目计划。
大型项目往往会有项目经理来负责做项目相关的事情，小型项目可能是产品经理在做这些事情。无论项目大小，对于产品经理来说，依然还是要做业务调研，只不过此次调研要达到的目标是要能输出完整的需求说明文档交付给开发，也就是产品设计。
调研的人员主要是业务人员了，调研形式可能还是需要现场调研或远程共享会议来沟通详细业务需求。售中阶段的调研计划是包含在项目计划里的，就算有项目经理，产品经理也要参与这个计划的制定，因为先做哪一部分，除了考虑业务方的诉求还要考虑产品的最小闭环以及产品迭代的节奏。
根据售前阶段的业务调研是可以梳理出核心业务流程图的，也知道了大概是要做一个什么样的产品（为谁提供什么服务），有了项目计划，则根据项目计划内每个模块来再做详细的业务调研。在做每个模块的业务调研时，要了解清楚更详细的业务人员的使用场景，了解清楚谁在使用、为何要使用、是否是经常在使用，是怎么样使用的，不用会怎么样，用了会怎么样。
可能每个点都会有一个使用流程，都要记录好，如果可以的话（脑子里能在了解完之后就立马分析了该需求也转化为了功能），可当场就给出功能方案，告知业务人员提供某个功能来解决可不可以，也可以多提供几个功能方案，告知客户每个功能方案的优缺点，让业务人员心里有底，作为供方给出的建议是什么，业务人员又选择哪种功能方案。
在调研过程中可能会遇到以下一些情况：
现场就能分析出是前后矛盾的需求，可要和业务人员说清楚，矛盾的需求是做不出来的，业务人员也会理解的。
业务人员提出的需求在当场就能分析提出的需求没必要，可当场就和业务人员说清楚为何没必要。
业务人员提出的需求超出了项目范围，或者比较模糊界定不清楚到底是超出范围还是没有超出范围，千万不要轻易做出承诺，可做出提示或先记录好，内部沟通好再给出确定的说法（有几点衡量标准可供参考，是否不做提出的需求就不能最小闭环，不做提出的这个需求会带来什么影响，做了对业务方的价值是什么，对我们自己的价值是什么）。
可能有些业务人员会考虑比较多，提出的需求也给出了功能方案，这个时候就要考虑业务人员给出的功能方案和现在版本的产品功能是否吻合了，如果现有功能稍做转换也没造成什么麻烦、也能达到目的，可和业务人员沟通是否可以稍做转换。在本人接触过程中，只要说清楚，大多数的甲方业务人员都是可沟通的。
业务人员提出的需求，要满足这个需求，可能牵扯到影响现有产品的功能，多想想能否有第二种解决方案，如果实在没有可和客户讲清楚，这么做会有什么影响。如果是必做的需求了，还可以考虑做配置化看能否解决。
如果是做产品的，不是独立定制的，在调研时脑子就得考虑好业务人员提出的需求该如何迭代到产品上，影响到产品迭代的，在调研过程中就要提出来。
在此阶段的调研过程中，可能会遇到不只以上的问题，客户是上帝没有错，我们做到对待客户不卑不亢有理有据即可，可千万不要客户说啥就是啥，没了项目原则、产品原则，那会把项目搞得一塌糊涂的。
在此阶段，甚至更早或晚一点在测试走查时，要调研清楚产品上线是否存在数据迁移的需求，这个也有可能是实施人员在负责。
在售中阶段做业务调研，在现场如果可以就当场分析需求和将需求转化为功能，可提高效率。如果牵扯内容居多，那就先做好记录，调研结束后再将需求转化为功能，再和客户沟通。
产品已经上线了，此阶段的业务调研相对更轻松一些，目标性没那么强，调研人员一般是业务人员，一般是远程沟通。
如果是SaaS租赁制的，此阶段的业务调研更多是了解业务运营得怎么样，是否有存在什么问题需要怎么解决，产品提供的服务能满足可能后续就留存下来了；如果是独立部署的，了解客户使用产品的实际情况，也可以向客户介绍别的模块；如果是定制的，了解客户是否有新需求，是否在公司产品范围内，合适的话可能就有计划可以开展下一期的合同了。
此阶段的业务调研也可将结果记录到产品反馈中去，这样就有源头去持续不断地优化产品了。
本文由 @ARDL （微信公众号：产品记录站） 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。