Jtti1.14

ToB领域,如何收集分析客户需求?

做B端产品的时候,重要而且不能忽略的一个步骤就是收集和分析客户的需求,并且根据需求来设计和改进产品。如果不了解客户需求,产品可能就会脱离客户,从而难以达成目标。由于To B 和 To C 有很大的不同,那么在ToB领域,应该如何收集和分析客户需求呢?
ToB领域,如何收集分析客户需求?

目前,C端产品的需求分析方法已经非常成熟,各位大佬已经提出了自己非常专业的视角。前文有提到,B端产品主要是面向企业的“组织欲望”,为企业“降本增效”(具体可见《To B 产品与 To C 产品的区别》)。

那么,B端产品需求,多数情况下不会像C端产品那样具有普遍性(saas类除外),更多的B端产品需求更加偏重个性化和定制化。

今天,猫爸就结合自己的个人经历,总结和分享一下,面对个性化、定制化的产品从0~1该如何进行用户的需求收集和分析。以供大家共同学习交流;由于专业及领域限制,难免存在认知限制,还请各位前辈指点一二,在下感激不尽。

在分析之前,我们先理解一下,什么是“用户需求”?

套用李叫兽《需求三角模型》模型,概括成一句话:用户需求,就是理想与现实之差。而对于企业客户来说,就是企业的理想与现实之差;即企业期望达到“降本增效”的理想,与现实工作中“高成本、低效率”的差别。

所以,当我们要做B端产品时,就必须要面向企业进行需求的收集和分析,了解清楚他们的理想与现实之间的差距究竟有哪些表现层面,落实到具体的工作中,又会有哪些流程需要梳理。

一、收集需求

1. 需求来源

无论是对内的产品还是对外的产品,在落地设计之前,都需要进行需求收集和整理,B端产品的需求的来源一般分为如下:

1)客户调研

B端产品的需求,最直接的来源即为企业客户;前文也提到B端产品的本质是满足企业的“组织欲望”,所以B端产品的需求,一般都会根据企业客户调研进行需求的收集分析。

针对企业的B端产品,可以大致分为内部产品和对外服务的产品,但无论是哪种,都需要找到对应的企业需求发出人,然后进行采集分析。

2)竞品分析

对于SaaS级产品或标准化服务的产品,我们也可以根据市场上已有的竞品情况,进行收集分析,具体的分析方法本文不做赘述,大家可以参考之前的文章《B端产品如何做竞品分析》。

当然,在做竞品分析之前,我们也会时刻关注市场的变化情况,进而自主判断需要增加哪方面的产品需求,这种方式一般会与竞品分析进行合并梳理。

3)其他渠道

其他的渠道包括不限于销售业务反馈、售前售后咨询、公司老板提需求等等;此处不过多赘述,我们根据实际情况来酌情判断即可。

2. 客户需求收集

记得曾经遇到过一个面试题:当我们接到任务,要对某一家客户进行需求收集,或者对公司的某一项内部流程进行产品化;这个时候,我们一般会怎么做呢?当然,那个时候的我,有点懵逼。

首先分析我们在实际工作中面临的问题:

ToB领域,如何收集分析客户需求?

其实我们做产品,最本质的是“如何系统的梳理复杂的业务流程”,只有复杂的业务流程搞透彻了,我们才知道该如何将其线上化,产品化。

而这个“复杂”不仅仅是纯业务流程的复杂,还有可能是客户之间的内部关系的复杂,利益链条的复杂等等。所以,我们需要有自己的节奏和标准,做到“心中有杆秤,遇事不慌张”。

1)建立调研标准

在开展调研之前,我们自己要要有一个评判标准,主要有两个目的:梳理可以产品化的业务形态、判断需求的优先级。

B端产品的建立,都是基于目前目标客户的业务形态来进行的,所以必要的了解目标客户的业务形态,是非常重要的,常见的客户业务形态分类如下:

ToB领域,如何收集分析客户需求?

在需求调研之前,另一件非常重要的事情就是有自己的优先级判断,对于优先级比较低的业务逻辑,不要花费过多的精力去研究。

优先级的判断方式有很多,例如C端经常用的KANO模型等等。对于B端定制化方面的需求,常见区分优先级的方式比较简单粗暴:

ToB领域,如何收集分析客户需求?

需求优先级比较难定义;所以按照职能级别,老板级别最高,中高层就低一些。

因为老板会去看这个系统,然后中高层会去点头,然后才能付款。有些公司可能老板是甩手掌柜,但是最终还是老板拍板付款,所以有时候如何抓住老板的认可也要一定的技巧。

在同一级别里面,也要区分子级别,例如都是中层管理者,哪个人的需求该优先,哪个该延后,这些也是需要评估的。

一般情况下,会根据需求实现难易程度,需求发出者对业务的帮助贡献度、多名同级人员在公司的重要程度等等来进行区分(此处有点“势利眼”的成分哈)。

2)把控调研的节奏

有了自己的调研标准,那么接下来就是实际的业务调研了,在调研的过程中,我们必须有一定的章法节奏。一般通过下面四个方法,可以有条不紊的开展工作。

方法一:提前了解行业知识

B端产品经理,大多面向的对象都是各行各业,在做需求收集之前,我们必须要提前了解行业概况,了解这个行业的一些常见的专业知识和专业术语,这样我们在收集需求时,才能够跟需求方有共同话题,对方说一些专业的流程,我们不至于发懵。

一般的,行业知识的了解渠道如下:

ToB领域,如何收集分析客户需求?

方法二:私下沟通调研

找到对应业务的业务接口人,私下了解业务的方向,涉及到的部门人员,关键节点等等;重点是对客户的项目进行一个全貌的了解。

其实是伴随着会议沟通同步进展的;甚至前期应该先进行一轮私下沟通。会议沟通,一般是了解对方的战略方向,期望等;而私下沟通,有些会议中不能提及的问题,消耗时间的业务细节,会更容易了解。私下沟通重点关注以下内容:

ToB领域,如何收集分析客户需求?

方法三:召开调研会议

熟悉了一些行业知识后,首要任务就是开始调研了解对方的诉求。

可能前期商务关系的介入,大概的客户诉求是明确的,但是为了保障后续方案落地顺利,产品经理需要再进行详细的调研和挖掘,深入分析和了解对方的业务流程和业务方式,此时召开会议是非常有效的手段之一。

ToB领域,如何收集分析客户需求?

方法四:排除调研干扰

有时候,我们在调研客户需求经常不是那么一帆风顺的,抛去客观因素,我们还会遇到例如业务流程遭遇非业务部门干预、两个部门对于流程的意见不相符、调研对象拒绝沟通等情况。

此时,我们要可以尝试通过以下方法来解决:

ToB领域,如何收集分析客户需求?

二、分析需求

业务流程了解清楚,需求收集完成后,我们就要开始进行业务需求的分析和梳理了。在分析梳理之前,我们需要了解到,关注这个产品的目标人群,他们的关注点有哪些:

ToB领域,如何收集分析客户需求?

想要满足这些,我们需要把用户需求进行梳理,形成可具象的落地方案。在梳理的时候,面对复杂多变的需求点,我们该如何做呢?

分析需求,本质上就是分析企业实际的业务场景,而任何的场景,都是由“人+事”组成,不同于C端产品的场景化思考,B端产品的场景化更加直接,我们可以直接面向目标对象来进行分析。

1. 需求分析方法

1)对人的分析

首先,我们分析需求时,需要了解到,这个需求到底是给谁用的?这个人在企业中扮演什么角色?他的这个角色是什么样的群体?这个群体在企业里面的组织架构是处于什么层级?这样我们可以获取到一个角色的图谱。

基于上述的角色图谱,这个角色有什么样的使用权限, 日常业务中能够访问哪些内容等等。

ToB领域,如何收集分析客户需求?

2)对事的分析

接下来,我们需要了解的是,假如我们完成了某个产品,那么这个产品能够帮助“人”做成什么事儿?“人”用这个产品可以做什么事情,角色的日程工作流程是什么样的?有些事儿的审批流程是如何的?每一个流程可能会涉及到的功能有哪些?哪些功能可以合并成一个大的功能模块?这些问题都需要分析了解。

ToB领域,如何收集分析客户需求?

2. 复杂流程梳理

无论是无论是对内的产品,还是为客户定制化的B端产品,一般的业务流程都相对复杂,该如何进行复杂业务流程的梳理呢?

1)step1:单一化业务流程

企业的复杂业务,一般都是由众多的角色一起参与完成的;但是常规情况下,都会有一个任务需求方发起任务,此时我们可以根据之前收集到的需求,通过初步的分析筛选,将业务流程单一化。

在单一化流程中,重点可以通过以下维度进行关注:

公司的产品线有哪些?这些产品线中,哪些是主流程?通过梳理,把众多主流程明确下来。

例如:虚拟物品下单流程中,浏览——下单——支付——发货——收货。这是一个主流程,我们可以基于这个主流程进行业务分析。

但是这个主流程里面,充满了多个分支流程;比如支付流程,就会衍生出第三方支付、银联支付等等,但是在进行业务分析下单流程时,将“支付”模块当做“黑盒”进行分析。如果是分析支付流程,那么就需要将对应的分支流程画出来,从而进行分析。

2)step2:定位关键角色

完成主流程的梳理后,每一条主流程,都会有一个需求角色,而其他角色均属于参与者。

例如:合同审批流程,需求方可能是业务方(销售、售前等),而参与的角色可能会有部门经理、分管副总、法务、财务、总经理等等,所以把这几个关键的角色找到,然后理清楚前后顺序,将他们的主流向图画出来。

需要注意的是,有时候,关键角色不一定是人,也有可能是系统,比如第一步的例子中,发放虚拟币可能就是系统自动发放,而不是某个人来发放。

3)step3:异常流程补充

主流程梳理完毕后,我们需要了解,对于单一化的业务中,有没有可能会出现异常的情况,如果是简单的异常逻辑,我们可以画在主流程中。

如果一个异常流程,需要处理和涉及的角色会更多,就会产生分支流程。此时我们把这条分支流程作为另外的一条单一的业务流程,重新进行step1、step2进行梳理。

在梳理流程的过程中,可以采用一个“台阶模型”的方式进行梳理(名字是我自己取的,勿喷),如下图:

ToB领域,如何收集分析客户需求?

把梳理的单一业务流程,按照上述图进行绘制,这样就可以清晰的明确一条流程中,有哪些节点,会有哪些参与角色。

3. 产出《需求分析文档》

通过以上的分析,我们最终能够将收集到的需求进行分析、汇总、归类。文档不需要非常详细,但是要给大家知道能够评估这个项目能不能做,具体怎么做,都有哪些东西需要做。

需求分析的文档一般包括以下部分:

1)项目背景

主要介绍当前项目的情况,包括的问题有客户的业务背景、产品背景情况:

  • 客户业务背景:主要体现当前客户所处行业、目前的业务情况,市场情况等简要做出概况;
  • 产品背景:主要介绍客户为什么要做这个产品。这个产品可以解决客户什么问题。解决的问题对于客户来说是否有足够的影响力(这一点可以判断客户是否重视这个项目)。

2)目标

产品的目标是什么,产品能够为自己的公司,为客户的公司带来什么样的价值。

3)期望

对于客户来说,有哪些期望,包括不限于上线时间,投入产出比等等。对于公司来说,又有哪些期望,也一并列举出来。

4)详细需求列表

一份详细的需求列表,主要记录的客户关注的重点需求的所有细节,包括类别、提出部门、提出人、提出时间、需求描述、需求背景、需求的目标、提出需求的期望、涉及到的角色、权限、业务流程。

5)产品架构图

如果是一个完整的业务架构,还应该根据业务流程绘制出对应的产品架构图,方便大家一眼能够了解整体的产品架构及相互之间的耦合关系(注:架构图不是结构图,两者不是一个东西)。

4. 需求分析评估的维度

我们最后产出的《需求分析文档》重点不是为了产出文档,而是为了各方在一起初步进行需求评估,从而为接下来需求是否能落地来进行准备。

所以在进入初期的评估阶段,公司的技术人员就必须介入进来参与评估。

ToB领域,如何收集分析客户需求?

三、总结

通过整体的文档介绍我们也能够了解到需求工作是非常庞杂的,所以我们在前期的收集、分析阶段,一定要把控好节奏,根据项目情况进行灵活的应变及应对。

对于一个复杂的项目,要做好长期进行需求收集确认的准备。

需求收集是一个不断变化的过程,我们有可能面临着,不同人员对于需求的理解不同导致需求多次变更情况;也有可能面临需求提出者睡一觉就会改变主意的情况;也有可能是我们需求在评估过程中,研发说技术上无法完成的情况,更有可能是在设计阶段发现需求不合理的情况……

这些都会导致需要进行变更,我们需要时刻跟进项目情况,不断做出调整和协调,最终将项目落地。

ToB领域,如何收集分析客户需求?

作者:两只猫爸;公众号:PMGrow ,我会持续分享更多自己的心得,与大家一起交流成长~

本文由 @两只猫爸 原创,未经作者许可,禁止转载。

声明:本站所有文章,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

给TA打赏
共{{data.count}}人
人已打赏
广告位招租919838898
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索