#01 判断B端客户需求的真实性
#02 需求调研要重视客户业务流程
#03 需求场景调研尽量细化
#04对客户需求进行可行性分析
作者|柿子姐 第80期原创内容
大家好，我是柿子姐。
需求管理是产品经理工作的核心，也是考核我们工作能力的重要指标。
这两期文章柿子姐将近几年做B端产品时，在需求管理方面的心得与大家分享，希望帮助正在做B端的产品经理们。
01
判断B端客户需求的真实性
作为产品经理最重要的能力是对需求的判断力，特别是B端客户的需求。如果需求判断不准备，不但浪费开发资源，会影响公司的营收。
如何判断客户需求的真实性呢，可以从考虑如下几点：
1.了解客户的OKR或绩效
在规划B端客户需求时，我们要先了解目标客户的OKR或者绩效指标是什么，根据他们的目标来定产品方案。
比如客户的主要目标是降低成本，如何规划产品能够帮助客户降低成本作为我们的目标。
如果有客户提出的需求与考核指标不符，我们要放弃与目标无关的需求。
2.根据干系人角色识别需求
收集客户需求时，要听明白是客户随口说的一句话，还是真的有痛点，如果问题不解决会对客户是否有影响。
因为客户方在交流需求时，商务、运营、产品等角色都会在现场，每个角色对产品的了解情况也不一样。
我们要根据角色识别需求的真实性。切记不要将客户的一句话就当做新需求，回来就和开发提需求。
其次可以询问需求具体的时间计划，通过询问具体的时间计划能够初步判断客户需求是否紧急，是否考虑清楚。
3.需求是否具备普适性
客户在提需求时都是以自己的痛点为中心，不会考虑是否符合我们产品的规划战略。
而我们要考虑需求是否我们目标用户相关，还需要分析该需求是否与产品定位相符合。
如果需求不具备普适性，就谨慎做抉择。
02
重视客户业务流程
根据客户的业务画一张泳道图来描述客户的业务流程，在画泳道图的过程中能够对客户的业务重新梳理，进而知道哪些需求可以纳入到我们的产品规划中。
在泳道图中要包含三个要素：角色、活动、条件，将每个角色要做的事项及前提条件在图中表示出来。
这样方便我们了解客户各干系人的职责，帮助我们做需求可行性分析及产品设计。
例如，政府即将做一个问卷调研需要的流程如下，角色包含政府教育部管理人员、问卷设计人员、问卷发布人员、待问卷人员、问卷分析人员。
每个角色都有相应的活动，并且要将活动的前提条件做说明。这张泳道图画出来就能够对XXX政府教育研问卷的流程有全面的了解。
03
需求场景调研尽量细化
在做B端客户需求时，尽量要做到细化，不但将客户的正常流程梳理出来，也要将异常情况做梳理。这样在做产品规划时才会更全面b端客户，不会遗漏需求点。
可以从以下三个方面来检查需求是否全面：
1.关键要素
梳理客户业务场景下的关键要素，也是我们常说的时间、地点、人物、事件、目标，按照这样维度梳理客户的业务流程，能够快速了解客户业务。
2.外部依赖
一般公司的业务会由多个系统承接，有CRM系统、有订单系统、运营管理系统等，每个系统间看似独立且有依赖关系。
我们要清楚规划的功能是否依赖外部系统、是否依赖外部数据、硬件或者网络等。
如果有依赖，需要考虑可获取性，是否方便获取外部的信息，需要我们提前想解决方案。
3.周围影响
除了考虑客户的需求的要素及外部依赖，还要考虑客户需求对周围的影响，对公司的哪类人群会有影响，为了推进需求落地各个角色需要如何配合。
很多企业投入做系统建设，花费时间和精力研发出来，最后实施落地困难，甚至系统根本没有应用起来。
像B端客户的需求很多业务已经存在，将线下业务做到线上，这样就会对现有的流程有影响。
比如开发一套针对财务的系统，财务已经习惯excel表格，但因为上线了新系统b端客户，财务的工作习惯要改变。
如果自上而下没有做统一，系统功能设计不全面，很难推动系统的正常使用。
04
对客户需求进行可行性分析
需求收集阶段告一段落以后，我们要对需求进行可行性分析。
可行性分析可以从技术、时间、经济、组织、社会环境、实施环境等几个方面来考虑。
1.技术
判断技术是否可实现。一般由技术负责人参与沟通，给出建议，在与技术沟通时尽量让负责人了解为什么要做这个需求，可以拿出相应的数据做支撑。
只要将为什么做需求表达清楚，一般技术都会支持。
如果超出目前技术团队的能力范围，可以给他们时间做技术预研。
2.时间
是否能在指定的时间实现。
时间是需求可行性分析时重要的一个因素，一般的需求都能够通过技术实现，但有的需求实现起来时间会超出我们的预期。
这时可以根据优先级来确定是否要在此次版本中实现。
如果优先级不高，且开发时长比较长可以放在后续版本或者寻找其他解决方案代替。
3.成本与收益分析
考虑需求可行性时，我们要明确投入的人力及其他成本有哪些，能够获得哪些收益。
最好将所有的成本列出来，包括上线后客户为了适应新系统所需要的培训成本等。
如果投入成本较大，但收益不可观，需要考虑需求是否继续。
4.是否有合适的团队资源
有些公司的销售团队不区分产品线，公司所有的产品都会售卖。
因为B端客户的需求很多非标准化，会出现销售谈了一个大单，但没有产品或解决方案可承接的情况。
或者有的项目明确是哪个团队支持，但没有时间排期，这时也需要根据现实资源情况考虑。
5.市场与政策法规
在做B端客户需求时，重点还要关注市场与政策法规是否有限制，不能做与政策背离的需求，需要我们随时了解所在行业的相关政策。
养成看新闻和行业报告的习惯，要有风险意识。如果公司有专门的风控部门， 可以针对需求询问风控部门同事是否有风险。
6.依赖条件是否可具备
我们在梳理客户的业务场景时要考虑系统的依赖条件，比如规划订单系统时要依赖客户信息、商品信息等基础数据。
那我们要知道从哪个部门获取相关数据，是否有现成的接口支持。如果没有现成的接口，需要开发时间多久。
除了数据的依赖，还有对制度的依赖。
如何让相关干系人都主动使用系统，如果上线后公司统一推行使用，是否需要公司领导自上而下宣导。
例如，我们现在的产品是云服务，如果客户购买我们服务，对他们的部署方式都会有改动，客户的网络环境是否符合，是否有专人负责云部署等都要提前做考虑。
总结：
在梳理B端客户需求时，我们要根据客户业务分析需求，提升自己判别需求真实性的能力，并通过尽量多的维度分析需求的可行性。
下一期继续为大家分享需求管理的干货。
END
“Where the productthinkinghappen
Meetdifferentexperiences”
产品思维的发生地
扫描下方二维码免费加入“产品运营社群”，结识同领域伙伴及答疑解惑~
— 往期回顾 —
点击文字进入原文
↓ ↓ ↓ ↓
做视频号的伙伴，
欢迎下单购买 柿子姐新书，
看过的都说好~
1、本站资源针对会员完全免费，站点中所有资源大部分为投稿作者付费教程，切勿轻易添加教程上除本站信息外的任何联系方式，谨防被割，如有疑问请随时联系客服。
2、本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。
×