B端产品如何更清晰地理解业务?

4 评论 2.2万 浏览 58 收藏 17 分钟

B端产品要想清晰理解业务,就需要理解行业、熟悉流程——通过市场分析、行业分析、竞品分析熟悉行业;并从微观层面熟悉流程。

01

理解业务对于 B 端产品非常重要。

为什么理解业务对于 B 端很重要呢?

C端产品,每个版本的更新迭代最好不要超过三个功能,可以为了某个运营活动单独发一版; B端产品来说,衡量产品完善度的,不是功能点数,而是看是否满足具体业务,企业希望的是一站式解决方案,而不仅仅是解决一两个问题就可以的,做B端产品不仅需要满足核心业务,还要融合周边业务。

To B的用户与To C的用户有比较大的区别,企业服务产品的使用,并不是个人决定的,而是由用户企业的决策链决定的,这就导致了 C端的决策周期很短,而B端决策周期比较长。

C端产品经理一般都是产品用户,比如张小龙肯定会用微信聊天, 很多需求可以通过共情来挖掘; B端产品经理通常不是用户,必须通过业务来挖掘需求,不理解业务,也就失去了真实场景的来源。

我们在做HRM产品「完美工事」的时候,我要求我们产品要多和公司的HR聊,询问他们的痛点,多理解他们工作的流程,只有这样才可能挖掘出来符合场景的需求。

注意,上面说的是「可能」,为什么呢? 因为在不同行业下还会衍生出不同的模式。 比如 IT行业和建筑行业就完全不一样, IT行业按月发薪,工作时间相对固定;而建筑行业尤其是农名工,工作时间和地点都不固定,甚至发薪都不固定,比如农名工一般平时发生活费,年底或者项目结束时发薪。如果你要做各行业通用考勤薪资相关的产品时,就需要考虑这两个不同行业的场景。

同行业下每个公司的处理流程和方式也可能不一样,比如有的互联网公司当年年假是年底失效,有的则保留到次年3月底,做考勤相关的SaaS产品时,就需要考虑这种不同规则的情况。

综上所述,我们需要了解在行业内的企业,相应的业务是怎么样开展的,从而抽象出通用的流程和规则,这样我们才可以了解企业的核心痛点,提供B端产品与服务也可以有的放矢。对于每个企业,我们也有必要了解企业内相应业务的不同员工是如何操作,最终实现公司业务的运转,了解这些内容,才可以使我们B端产品的设计更加落地。

02

熟悉业务需要熟悉行业,以B端 SaaS 软件举例。

SaaS软件分为业务垂直和行业垂直,业务垂直型SaaS专注的是多数行业需求高度相似的业务领域,例如考勤服务;行业垂直型SaaS专注的是对在部分业务环节有强烈个性化需求的行业领域,比如金融领域。两者面向的客户群体并非完全的交叉重叠。但随着创业公司的发展壮大,业务边界拓宽,这种竞争关系也在发生变化。

其中常见的发展路径是——业务垂直型SaaS针对具备一定个性化需求的行业拓展行业解决方案,行业垂直型SaaS向特定行业全链条的闭环服务发展,形成有别于业务垂直型SaaS的竞争壁垒。

无论是业务垂直和行业垂直,都需要熟悉行业,怎么能快速熟悉行业呢?

行业的类别有很多,例如文娱业、金融业、IT业、建筑业等等,我们要了解行业需要通过三个大方面了解。

1. 行业大环境

建议可以按照 PEST分析法来分析行业面临的外部影响因素(P政治:政策趋势变化,E经济:经济环境变化,S社会:消费者习惯变化,T技术:技术革新)。

1)政策(P)

在中国做任何事情,基本上这事都要摆在第一位,首先看政策是否支持,其次看你监管是否已经开始介入,如果介入了意味着行业开始规范了。比如政府非常支持新能源,互联网金融已经开始监管了。

2)经济(E)

考量一个行业的空间,还关注这类行业的经济环境。比如随着互联网流量成本变高,电商解决方案不如以前理想,新零售又兴起了。

3)社会(S)

社会环境本质上是研究人的需求层次,要关注用户需求的变化,比如现在大家消费升级了,需要能否让大家变的更有尊严,生活更有效率,是否能让大家充满憧憬。

4)科技(T)

科技的进步会对某些行业有影响,比如大数据、物联网、深度学习已经影响到各行各业。人类社会的发展史,就是一部科技史。

下图是零售行业的 PEST 分析:

PEST示例

2. 行业分析

任何事物发展的必经过程,一定是“萌芽——起步——快速发展——成熟——衰退”,这是规律,也是企业和行业的生命周期。

只有判断出行业所处的阶段,才能知道规模有多大,才能明白市场有多广。萌芽阶段的规模会缓慢爬升,此时不会太大,而起步阶段,上升曲线开始呈现陡峭状态,此时的市场容量,在逐渐增大。直到快速发展阶段,一般都是野蛮扩张,这时的发展曲线会呈现出斜率大于45度飙涨,规模极具增加。会表现出供不应求的节奏,此时大家发现该行业有暴利,就会争先去扩张,市场容量也会继续爆发,等到成熟阶段,市场则会开始进行“自发淘汰“,行业集中度会明显增加,很多小企业会被淘汰出去,最后只剩下一些有技术、有壁垒的大公司。

如果这个市场就1个亿的规模,无论你怎么折腾你的产品的天花板就一亿美金。雷军特别后悔的一件事就是当年在金山的时候先做了词霸,等了好几年才做毒霸,而毒霸的市场规模是词霸的一百倍以上。

针对市场增长率、PV、独立用户数、REVENUE/ PROFIT等关键指标而言可以判断出增长态势。这一条承担的是论证产品成长空间和盈利空间的职责,也能判断我们SaaS产品切入有没有机会,所以非常重要。

研究一个行业,一定要看它的市场容量,从而判断未来的市场规模。一个连市场规模都摸不清的行业,故事再好再美妙,业绩基本也没法落地。

有些行业,注定没法一家独大,比如餐饮业,也有些行业注定也是少数几家公司统治。了解行业一定要了解行业内的标杆企业,比如你想了解餐饮行业你可以了解下海底捞,看看财务报表,了解下创始人的格局,看看三方报道等等。这样你能更饱满的了解这个行业。 下面是烘焙行业的市场分析,可以作为参考: http://www.chyxx.com/industry/202003/841507.html

3. 行业下竞品分析

还要时刻关注下服务这个行业的 SaaS 产品,也就是你的竞品,找到自家 SaaS产品的差异和竞争点,回到自身产品的定位上。

比如,如果一个HRM招聘的SaaS产品,有面向IT行业提供SaaS产品与服务,那么产品经理做行业分析就不能停留在大而全地分析IT行业是什么样子的,这样分析出来的结果对具体工作几乎没有关联,而是要以自身SaaS业务为出发点,进而围绕“IT行业招聘模式是什么样子”进行深入研究,从而抽离出IT行业在招聘上通用的几种规则和玩法。只有这样,你才能更了解自身SaaS产品定位的客群有哪些,痛点表现在哪里,同时更高效帮你从微观层面调研运作流程。

03

了解完了行业,还需要从微观层面熟悉流程:

1. B端业务调研和C端调研还是有很大的区别的

To B的用户调研与To C的用户调研产生了比较大的区别,企业服务产品的使用,并不是个人决定的,而是由用户企业的决策链决定的。

简单的决策链条包括决策者(老板)、需求方(部门主管)、使用者(员工)来组成,而复杂一些的决策链条,还要考虑到采购、财务等因素。

以「完美工事」这款HRM管理软件举例,用户决策流程一般是这样的:

老板让HR部门看看有哪些可以用的 HRM管理软件,HR部门的负责人经过一番调研后,跟老板汇报了几种主流的HRM管理软件,经过一个个产品的沟通洽谈,最终选择了「完美工事」。

也存在需求方推动决策者,比如 HR部门体验了「完美工事」,觉得能提高不少工作效率,反馈给决策者,最终决策者拍板决定使用该软件。

To B业务类型的运营重心都在于服务,那么到了购买后,客户成功就需要开始与企业用户的HR部门进行对接,沟通最频繁的还是HR部门的员工。

如果产品体验好,员工的工作效率会提高,如果产品体验不好,员工就会开始抱怨,并且没有体现什么产品价值,反而会浪费一些资源。那么员工的使用会逐层反馈到老板那里,如果是负面的反馈,还能复购么?从正常的运营逻辑来说是不能了。

所以做To B端的用户调研重点调研的是决策者、需求方和使用者三个层级。这三类人群的侧重点时候不一样的。

决策者比较看重产品能够为企业带来的实际价值,决策者关注的重点无非就是两个,多赚钱和少花钱。从这两个方面去做调研,了解决策者现在面临的主要问题有哪些,需要解决的关键环节在哪里。和同类产品对比,决策者更关注你的产品功能是不是更多,价格是不是更低,品牌是不是更好,而不是界面是不是更好看,体验是不是更好。

需求方在小企业中可能和决策者是同一人,在大企业可能会有专门的采购部门来扮演这个角色,更多的还是需求部门的主管来充当这个角色,调研要关注产品的使用场景、希望带来的价值、现在存在的问题等方面。相对于决策者,需求方可能更关注是否能提升本部门员工的 KPI和话语权,而不是是否降低成本。需求方是To B产品在线上推广时的主要目标用户人群。

使用者往往是「被需求方管理」的那一批人, 这类角色使用的功能和其他角色使用的功能形成闭环,比如HR使用完美工事管理考勤,就需要使用者使用软件打卡。 对使用者的调研一般作为对决策者和需求方调研的补充。使用者的需求其实和 C端用户的需求很类似,关注的是能不能解决问题,使用是不是流畅,界面是否好看。

2. 业务调研最终是为了理解业务的运作流程

我们一般会选择标杆企业进行用户调研,以标杆企业的需求为核心。标杆企业需求有代表性,相对容易抽离,标杆企业的声音有影响力,后期能够引领其他客户。 比如我们产品首先选择本公司进行调研,因为我们集团规模足够大,需求足够明确,相对比调研外部公司,没有跨公司的壁垒,要简单一些。

运作流程两个核心元素是角色和流程。 调研完了最终要找到并梳理业务链条下的所有角色,切勿遗漏角色,B端SaaS产品业务需要注意业务的闭环,即使是忽略了业务链条上不重要的角色,也会导致业务无法形成闭环。

核心业务的工作流程是怎么样的,通过观察与用户调研厘清角色的工作流,对SaaS业务来说,观察比直接开放式调研更有效,可以深入业务需求方的工作场景,观察他们平时的工作方式如果有机会,最好能够直接上手体验业务方的工作。

04

总结一下, 理解业务需要理解行业熟悉流程。

B端产品其实并不完全依赖互联网,绝大部分行业公司的业务模式,在互联网真正对企业经营发挥影响之前,就已经天然存在。至少到目前,互联网还很难从根本上撼动绝大部分公司的业务模式,B端产品基本上是将「线下已有需求」系统化,所以需要「还原业务」,而非「创造业务」。

理解业务其实没有太多的技巧,更多需要循序渐进,通过调研与观察交叉,了解客户的需求,并通过产品设计满足需求,了解反馈,进而根据反馈继续满足需求——通过不断完成这样的循环,深耕业务,才能不断深化对于业务的理解。

 

作者:老于;公众号:老于的笔记

本文由 @老于 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自 Unsplash,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 于老师,您好,我是人人都是产品经理的运营 漓江,有详细看过您近期在B端方面的文章,想跟您具体沟通是否可能有其他更多的合作机会,微信id:18612189170,已加您好友,期望能和老师具体沟通

    回复
  2. 这里讲了做事情的目的,但是该谁来做,谁来负责哪一块呢?

    回复
  3. 做B端产品,最重要的是对业务的熟悉和了解

    回复
    1. 那如果公司产品经理就是老板,产品经理和项目经理,极少和用户去谈,只和客户经理人,比如某个部门的管理者来谈呢。产品经理和项目经理并不会很理解业务,而我做为需求分析,理解业务但是没有职权左右产品和项目的决定的时候,是不是就注定这款产品是失败的?

      回复