需求调研，是每个产品经理的重要工作之一，而需求调研的质量将直接影响到产品最终的价值。
对于B端产品而言，通常业务复杂度高，我们不仅仅要花大量的时间去学习业务基础知识，而且需要在有限的时间内，调研多个岗位的业务人员，提炼关键信息，做好产品的定位和规划。
疫情发生后，远程相关需求也日益增多，相关产品也在和时间赛跑。
老板说：“咱们客户要做一个在线培训系统，要求2个月内上线，你赶紧去调研一下。”
通过远程会议对客户单位进行初次需求摸底调研后，发现需求五花八门，无从下手。
客户老板：赶上疫情了，咱们现场培训都没法做了，我们的业务有培训的要求，我需要一个远程培训系统，必须保证培训效果，最好能监控培训……对了，2个月内要上线，否则直接影响我的业务开展。
培训部领导：每次组织培训都太难了，总是有人忘记，还得一个一个核对，讲师的考核也得一个一个去问，太麻烦了。
培训部小伙伴：每次组织培训难，培训后的档案太多了，每次统计存档更是痛苦了，还得统计课时，发放课时费给讲师，太费时了。
讲师：每次自带电脑去投影，有时候半天都调试不对格式，太浪费时间了，上课那么累，下课后还得自己去阅卷。
学员：这么多培训，隔三差五的，地点也不固定，又没有课表，经常还临时变动，一不留神就可能错过培训。
这么一看，看似简单的一场培训，其实中间的环节并不少。调研信息量那么大，作为产品经理要保证产品的规划尽可能完整，怎么规划设计呢？每个用户的诉求都那么多，而产品的定位是什么？核心功能该是哪一个？ 需求那么多，2个月上线，没有较大的资源投入，估计是不行了，每个需求听上去都非常急，那么优先级又该如何去排呢？基于这些多的信息又如何抓住重点信息，为客户及用户定制一个更为合理的方案呢？
有限的时间，如何在初次摸底访谈调研的过程中快速的抓住核心信息，不被业务的“诉苦”带偏，精准定位产品重点。这些信息，我想必不可少。
完整的业务流程
完整的业务流程，可以帮助我们梳理产品的信息流向，更重要的是将直接关系到我们产品的主要功能的提炼，让我们产品的规划有完整结构，不会缺胳膊少腿。完整业务流程对产品蓝图的规划提供重要的信息。
以培训这一场景为例，提到培训我们可能自然想到的就是授课及考试两大块功能。
如果我们去调研一下完整的线下流程，通常有这样一些环节：相关部门发起培训计划，讲师进行培训备课，培训现场签到，讲师现场授课、互动，学员考试，讲师阅卷，课堂反馈调查，课程记录存档，课时费发放等。（此处举例为截取部分环节非完整流程）
调研完完整的信息，如果我们再去规划这么一款培训产品，就自然可以对应到：培训计划、课程资料管理、线上签到、直播授课、在线互动、问卷调查、考试管理、档案管理、数据报表等这样的功能。
完整的业务流程，可以一一对应产品蓝图中的功能模块。而如果不梳理完整的业务流程，在规划产品蓝图的时候，很有可能会漏掉某一个关键功能的规划，影响产品的价值，甚至可能因无法完整的满足业务流程的闭环而夭折。
各业务环节优先级以及日常工作花费时长、频次
我们知道高价值的需求通常有几个特征：强烈、普遍、高频。
强烈：用户越愿意为之付出成本（经济、人力等）越高，通常对这一需求的渴望更为强烈。
人的欲望总是很多的，但是能够愿意让我们付出成本的，才是更强烈的需求。比如我们每个人想买的东西是不是很多？那我们最终买回家的，都是经过我们深思熟虑，真的特别想要的，或则买了后能带给我们强烈满足感的。这就是强烈的需求。
B端产品不同于C端产品，B端产品的价值直接体现在业务的降本增效。大部分B端产品都是将许多的纯人工操作进而由信息产品来替代，达到节省人力成本，提升效率的目的。
因此在调研B端产品需求的时候，往往用户会提到很多的述求，以希望减轻自己的工作量。每一个述求听上去都很有价值，也能解决某一类人的痛点，但在产品0-1的过程中并不可能都满足。只有抓住用户强烈的需求，才能让用户对产品的整体满意度提升，将产品的价值尽可能最大化。
在调研的过程中，我们可以尝试与客户及用户沟通其预算情况，并引导其在预算及时间的相对情况下，不能涵盖所有业务，倾听他们的优先级作为参考。往往其共同认为优先级较高的，即其更愿意为之付出成本的需求，其需求也往往越强烈。抓住这些需求，有利于在有限的资源及有限的时间下，让我们的产品满意度提升，产品价值最大化。
普遍：某一业务环节所花费时长占整个业务链条时长比例越大，通常该业务具有普遍性。
某个环节的花费时长=∑该环节各个相关角色花费时长，当某一个业务环节在整个业务链条里面花费的时间越长，通常说明投入的时间较长、或则投入的人力相对较多，那也代表其受众相对广泛，具有一些共同性，也就是该业务环节的需求，很有可能出现普遍性需求。
在整个业务链条上，花费时间占比较多的环节，那我们就值得倍加注意了。否则可能眉毛胡子一把抓，核心功能没调研好，而锦上添花的做了一大推，产品的定位完全偏离。
比如在培训这一业务场景下，我们可以注意到讲师进行培训备课以及现场授课的业务是花费时间较长的，备课的环节用户仅为讲师，而授课的环节用户是讲师及广大的学员，甚至培训组织者。
那么整体来说授课的环节的受众、耗时是更高的，同时授课也是培训的核心。授课环节需求其价值也可想而知更高。授课环节作为讲师、用户、管理者的愿景期望是什么，都将是我们需要重点去调研分析的需求。关心教学的质量，也许我们需要对学员的参与情况进行监控；担心上课的氛围，也许我们需要对课堂的互动需求花些心思。
高频：某一业务环节发生的频次越高，通常则对应高频这一特征。
某一业务环节发生的频次很高，用户经常使用到，其需求更加被重视，在高频的场景下，因为使用的频次高，用户的体验更为深刻，不合理的设计或则不好的体验等，则极可能带来用户的对产品整体影响的降低，以及使用的抵触心理，不利于后期产品的使用推广。同时，高频的业务也将作为我们需求优先级的一个重要依据。
在培训这一场景中，培训签到花费的时间很短，也许和课时统计补贴发放花费的累计时长相差不大。签到是每次培训必发生的，如果签到体验不友好，流程繁琐，或则极为不稳定，则会引起用户反感，甚至放弃使用。课时费发放，未必每次都会发生。
实际情况中，也许是一个月累计发一次，甚至更长时间。那我们的版本规划时，初期的版本则可以考虑先记录数据，缩小版本的边界，降低产品周期过长导致的风险，而随后的版本快速迭代中再进行优化。
现状所遇到的问题
业务环节中难免出现一些特殊情况，特殊情况往往对应了产品的边界。哪些需求是真实存在的，哪些需求又是产品经理自己虚构出来的？
了解业务环节中的特殊情况，首先是可以避免因为信息不全面而导致的产品设计的缺陷，也可以避免因过度追求完美，而使系统过于庞大。同时、业务所遇问题还可能是业务深层次痛点需求所在。
在培训中，当培训计划已发布通知到全员，有一种特殊情况当临时出现受到场地限制影响等情况下，培训需要更改时间或更改地点，同时需要确保通知到所有相关的人员。
那么我们产品的设计可能就会对应培训计划支持变更、支持变更后的信息通知推送、甚至还有可能需要支持信息推送的阅读统计等。而如果不知道这样的特殊情况，则很可能忽略通知推送这一功能，影响培训的参与程度。也许我们想画蛇添足，加一个消息收到回复功能，而实际上发现现状发出去的短信，回复的寥寥无几。其价值可想而知。
同时，现有业务现状最大的问题，疫情发生后，短期内面授培训不能开展，将影响到业务发展。这就是当前环境下，业务最大的痛点，也是现阶段我们产品的核心定位。
业务现状所遇到的问题，包含现状有解决方案的那是我们产品的边界，也包含现状没有解决的那是业务的痛点。
B端产品的信息都不脱离业务，那么业务信息的本身是调研的重点。调研信息那么多，这些我们不能忽视。这些信息，可以让我们对产品的定位更加清晰，对产品的价值更加明确，对产品的规划更加完整，对需求优先级的排序更有理有据。
希望这次的分享能对你有些作用。也欢迎大家一些交流探讨一些好的方法，共同成长进步。
