在没有或有少量市场竞品可参考的情况下，只有挖掘业务本质，才能确保需求逻辑不跑偏。那么如何调研需求背景、业务现状、明确需求便尤为重要。本文作者对此进行了分析，一起来看一下吧。
万事开头难，尤其是针对B端产品，在特殊业务场景下，没有或有少量市场竞品可参考的情况，只有挖掘业务本质，才能确保需求逻辑不跑偏。那么如何调研需求背景、业务现状、明确需求显得尤为重要。
如果未充分调研需求，就启动开发，开发过程中突然发现调研需求有偏差，导致产品方案方向错误、未涵盖主要功能等情况，再纠错产品，则开发成本和时间成本将非常大。究其原因，主要是因为未知，产品经理做的都是没有的功能或产品，无论是从0到1，还是1到N的优化，都是新的。尝试新的就意味着将来所做的产品有可能是对的（符合需求），也有可能是错的（不符合需求）。如何降低产品错误风险呢？就需要产品设计前，尽可能不断挖掘需求，尽量保证产品方向契合真实需求，方向不跑偏。
所以，有经验的产品经理都知道，拿到需求，不着急写方案，而是花大量时间投入到产品方案定制前的阶段。如调研相关用户工作流程，反复确认用户痛点、评估需求是否合理、挖掘背后的深层次需求等。
常见的方式有用户访谈、调研问卷、轮岗等等，形式有很多种，关键是通过上面的方式，带着同理心，访谈收集一手资料后，再梳理清楚复杂的业务流程，了解对应的背景，提炼痛点难点。那么，具体怎么做呢？
第一类是核心业务线上的相关人员，最直接的是实际使用产品用户，一般为业务执行人员。间接还会有业务人员的领导，一般是部门负责人。B端产品的提出、落地，一般是自上而下，所以也会有领导的领导，一般为公司负责人，真正的决策者。值得注意的是，领导们的目标和能提供的支持是什么也要搞清楚，没有领导们的支持，项目将很难落地，所以争取支持也很重要。为了获取支持，这里也会涉及BRD、MRD，或是内部立项汇报等，后续会开专题来深入探讨，此处不做过多分析。
有的大型公司，除了一线业务人员，还会有集团相关业务线的人员，负责集团统一规划。比如某公司营销业务线分为一线和集团，一线有销售员、销售助理、部门销售经理、公司销售负责人等，集团有销售对接人、销售领导等。
除了业务线的人员，还会有其他相关利益方。
第二类是业务闭环的其他节点。比如为完成业财一体化目标，即业务数据与财务数据互通，完成财务实时做账，无需线下再问业务人员询问业务数据，那么财务线就很重要。比如销售人员卖完货，涉及交易金额、交易时间、商品数量、商品货号等等，财务会根据交易数据进行计入成本、收入等做账操作，另外为了预估未来发生成本或收入，基于以往实际销售数据，也会有财务的预估逻辑，这些都是离不来业务线、财务线的交相呼应。而找到对应的财务人员了解财务需求就很重要，因为销售逻辑和财务逻辑并不相同，前者给与后者提供数据来源，后者则可高效降低人工沟通成本的完成成本、收入、利润的财务专业分析。
那么财务线人员如何确认呢，一般公司会和业务线相互对应设置岗位，比如上述案例中的一线/集团业务人员，财务也会对应一线/集团财务人员。如果实际产品范围还涉及第三类人员，比如下游资金线、上游广告渠道线的话，那就可以以此类推，进行寻找相关利益人。
总结：找到对的人进行需求调研，核心是梳理公司的组织架构，人物关系了解清楚，对后续需求调研、推广落地就非常有帮助。
找到相关人员之后，就可以针对性开启需求调研之路了。
1）用户访谈
用户访谈是需求调研的常用方式，简单来说就是找到目标用户进行沟通，达到了解业务现状、困难点、诉求的目的。
上面讲过如何找到关键的人，但是如果全量人太多，无法每个都访谈，则需要找到典型的关键用户。比如一线业务营销很多，按照区域、公司、岗位可以选出一定比例的用户进行访谈。用户的意愿度和专业程度也会决定访谈的质量，但是访谈前一般产品经理如果是首次接触业务，则在有限时间和资源下，尽量选择多一些用户进行沟通，防止只听几个用户意见导致方向走偏。
沟通前也需要充分准备，负责的项目看是已有业务则需线下业务转变为线上化、数据化、智能化，还是全新业务，比如为满足上游C端用户需求则需B端后台支持业务运转。
如果是前者，已有业务的话，则更多的是找到多个负责某业务的操作人员、业务专家进行沟通，从不同人口中拼凑出业务现状的全貌。当然，相同的目标也会有不同的做事风格，导致业务操作流程也会有些许差异，这些都需记录下来，和收集的上下游业务流程进行重新整合，完成全套业务串联或并联。
如果是后者，全新业务，则有两种方式入手。一是找到全新业务的关系方，比如资金系统原来都是外包给别的公司进行付款、收款，但是目前因为业务发展，需自建资金系统，而资金业务上后续会归属于财务部门，则可请教财务相关同事了解入手。
B端产品很多时候并不是纯线上，大概率是线上+线下相互配合才能完成的业务工作，所以找到未来负责全新业务方，可融合业务员的实际情况，更能促进产品从0到1的落地。
二是找到行业竞品进行参考，如上述案例的外包供应商，或是行业内相似公司的对应产品，或是不同行业的相似业务。比如目前电商行业的信息化是非常靠前的，而B端产品服务于广大的传统行业，则都可以学习相关的模式。
比如电商交易环节，从获客、商品浏览、下单、支付、发货、收货、评价整体流程，也可运用于房地产销售环节，或许有的部分并不能像电商全部线上化，但也可根据实际情况进行调整，贝壳的交易流程就和上述逻辑相似，获客、看房、线下带看、签合同、面签、批贷、网签、过户、领房本、抵押、房款、完结。
线上记录交易进度+线下流程跟进，很清晰地供买卖双方及内部工作人员跟进，是非常好的一个业务线上化呈现。
综上，用户访谈是一种形式，但是背后其实需要产品经理信息获取和分析能力，比如收集所在行业、竞品、其他行业相似业务流程优秀线上化案例、公司内部业务背景、从上而下决定最终操作用户业务录错等等，还需要沟通能力，如何揣摩访谈用户心理，更快的打开对方话匣子，引导对方来表达工作的流程、业务难点痛点等。
小小tips，每次访谈尽量不超过30分钟，而且开始前简单叙述下自己背景，希望得到对方支持，每次访谈可针对一个部门或公司的一条业务线进行沟通，人数控制在3人以内，可以进行多次的沟通。如果对方不配合，也可释放出来其他部门提供了什么支持、XX领导很关注这次项目、这次项目我们初步的设想是在哪个方面提升你的工作效率等。
2）调研问卷
调研问卷，笔者做了几个项目后发现，和用户访谈的方式相辅相成。先用户访谈，了解下基本情况，对大概业务清楚了之后，就可以针对大量用户出调研问卷的问题了。调研问卷的形式有内部邮件、微信的调研问卷小程序、内部共享文档等等，可以根据实际情况来定，比如公司信息安全要求较高，则使用内部办公软件，如果对实时性要求就高，则可使用共享类文档。
调研问卷编写也值得考察，首先是背景阐述，告知大家为什么需要填写这份问卷。问题也需清晰明了，站在用户的角度，专注业务节点上的不同规则，问题无疑义，如果担心用户难理解，也可举一些案例供用户参考，引出用户实际答案。答案也可设定为选择题、填空题、判断题等，根据问题性质，是否全量答案已有，需要用户选择等。
调研问卷发出去后，也需及时收回来，未答题的用户也需想办法找到对应人、相关领导进行协调。调研问卷的问题是否高质量决定分析结果，结果获取后，会对前面用户访谈内容有一些补充，也会有另一个完全不同的业务模式存在，这就需要再分类进行针对性，更进一步的访谈了。
所以调研问卷主要是针对全量或大量用户，但获取内容较有限，用户访谈虽然无法针对大批量用户，但是结合调研问卷可迅速分类，找出不同的典型用户。所以两种方式相辅相成，缺一不可。
3）轮岗
轮岗的机制一般是针对校招生，或是公司主推关键业务，需要相关产品经理、项目人员去实际的业务一线进行亲身体验。轮岗的优势非常明显，实操获取的经验比听人诉说、收集网上资料要靠谱很多。但是弊端也很明显，轮岗需要花费大量人力，而且有的专业岗位也不适合轮岗，接受部门担心影响部门kpi，也不会让轮岗人员承接主要业务，所以轮岗的效果并没有在短时间内呈现出来。
当然，对于校招生或内部孵化项目，轮岗还是很有必要的，或是轮岗也不必拘泥于必须干这个岗位的事儿，也可换种思路，为了达到某个业务节点的目标，换种方式完成岗位的业务工作，也是一种方式。
实践经验中，笔者也是刚毕业校招生，前半年的轮岗，从营销、制造、开发的各个公司、部门的基础工种，从实践角度了解了公司的整体构成。后来的社会招聘中，就没有类似机会了，除了上面说的用户访谈，项目启动和落地推广时候经常出差，在实操用户旁边模拟工作流程，只能算作浅轮岗，其他也没有轮岗机会。
经历了一遍上述的需求调研流程以外，基本是你就能获得一手的调研资料。而调研资料的全面与真实，直接决定需求的质量。面对这些资料，我们将如何分析呢？
因为分析后就要决定产品规划、产品设计、上线推广工作，那么以下这些问题可参考：
这些都需要产品经理，依赖缜密的分析逻辑、全面的行业知识进行判断的，如果以上问题能有一个深思熟虑后的结论，基本后续的产品方向就不会偏。
综上，就是B端产品实际需求调研的经验总结。需求调研个人认为是产品工作的重中之重，对产品获取内外部支持非常重要，也对后续实际开发、推广上线至关重要。比如需求调研出实际现状，推理运用信息化产品解决的价值点，以及每个结论都会影响产品的实际设计。
仔细想想，需求调研本质是融入业务现状，逻辑推演解决痛点，推进业务发展。结合最近看的一本《价值》讲投资的书，发现产品经理和投资经理有异曲同工之妙，都需深入一线，发现改善点，只不过产品经理运用信息化产品，帮助解决问题，而投资经理是运用金融产品来推动行业发展。以上的经验，希望对大家实操中有所帮助。
本文由@元方 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。