B端产品经理,应从哪些方面理解业务?
作为B端产品经理,理解业务是开展一切工作的基础。那么B端产品经理,又应该从哪些方面理解业务呢? 快来看看本文的解答吧。
新人入职新公司后,第一个工作就是了解公司业务,一般都是看公司项目PPT、产品需求文档,根据现有系统功能梳理功能结构图、产品流程等方式,但并不能系统化地帮助我们了解公司业务,容易流于表面。
由于TO B业务往往具有鲜明的业务特性,如果我们对业务只是局部理解,或者理解有偏差,做出来的产品可能无法适应和支撑业务。
作为B端产品经理,理解业务是开展一切工作的基础。
一、理解业务的重要性
1. 设计出更符合业务需求的产品方案
B端产品经理在日常工作中,常常会收到各种各样来自不同部门的需求,所接收的需求,更多是意向,我们的工作就是要推导出意向背后的真正需求是什么,然后设计产品方案。
错误的理解业务,可能会直接影响需求的推导过程,如需求的定义、用户分析、需求分析的角度和实现方式等,最终可能导致产品方案的设计有所偏差。
与销售部门收集需求过程中,可能听得最多的是类似“客户有一个A想法”。
但实际上A想法是客户的解决方案,甚至是销售人员的解决方案,而不是真正的业务需求。
如果我们立即考虑怎么去实现A,做出来的方案,往往不是客户想要的。
而是要思考:客户为什么想要A?A能解决哪些问题?A与业务之间有哪些约束条件和弹性条件?有没有B方案呢?等等。
产品是基于业务之上的,只有对业务有足够深入的理解,才能发现业务需求背后的本质问题,从而制定更符合业务需求的产品方案。
2. 提高决策质量
决策是获取和处理信息,再对行为作出预测和判断的过程。
产品经理无不时刻处于决策的环境之中,上至产品策略、产品方向,下至产品功能设计、页面文案。选择做什么,不做什么,如何做,用什么方式去做,都是一个个的决策。
而我们所做的决策受业务信息的理解程度影响。
某TO B垂直领域平台的运营人员提出“年度报告”需求,根据客户日常基础数据提炼出营收增长、运营效率提升等方面的数据,并有积分抽奖小活动,感谢客户一年以来的辛勤劳动和支持。
产品上线一周后,尽管“年度报告”入口在客户端工作台的显眼位置,但打开率寥寥无几,活动更加无人参与。
产品经理可能没有意识到,企业客户的决策者和使用者,两者的用户特征和需求关注点是截然不同的。
决策者(老板、高层)确定购买产品服务后,极少或根本不会登陆客户端。
使用者(员工)并不关注减本增效方面的问题,至于积分抽奖活动,更加不敢私用积分。
产品经理对业务特征和用户特征的理解偏差,导致了错误的决策,最终浪费研发资源。
如果我们对业务有足够深刻的理解,就能提高我们做出正确决策的概率。反之,会导致我们做出错误的决策。
俞军老师曾经说过:产品经理的核心技能,其实是输出决策质量,持续的输出决策质量。
二、业务与产品之间的关系
进入主题之前,我们先梳理一下TO B业务与产品之间的关系。
企业会根据市场环境,结合自身优势和资源制定商业模式,商业模式的落地可能需要1个或多个项目支撑和运转。
每个项目也可能会发展为1个或多个业务,每个业务会有明确的业务定位和业务目标。
产品会根据业务定位转化为产品定位,同时为支撑业务目标会设定不同阶段的产品目标,产品目标最后会落地为我们最经常接触的一个个产品功能。
对于大部分产品经理来说,可能接触不到制定战略、商业模式这一层面的工作。
所以本文将从产品经理最经常接触的业务定位、业务目标、业务场景、业务关系、业务角色、业务流程、业务规则的角度讲解,让我们更好的理解业务,帮助我们快速进入岗位角色或开展工作。
三、从哪些方面理解业务
1. 业务定位
B端产品一般都是由业务驱动的,这就决定了产品面向的目标客户群体是谁,要做什么东西,什么东西不能做,怎么做,为什么这样做,帮助客户解决什么问题,有什么价值,都受业务定位的影响。
(1)业务定位
业务定位指企业对客户群体和业务方向的选择,是业务立项之初最为重要的环节。从定义上可以找出两个关键点:选择客户群体,选择业务方向。
举例:
有赞的业务定位:中小商户的软件服务商。
从中可看出,有赞选择的客户群体是中小型规模的商户,业务方向是成为软件服务商。
(2)产品定位
产品定位,是产品与用户的连接点,通过用户研究,挖掘客户群体的特征和需求,定义产品的方向和边界,如果有竞争对手,还需要考虑差异化的方向是什么。
业务定位与产品定位是挂钩的,从理论上讲,先有业务定位,然后才有产品定位,产品定位是业务定位的产品化结果。
举例:
有赞的产品定位是:做生意,用有赞。
结合有赞的业务定位“中小商户的软件服务商”,看看有赞业务定位与产品定位的关联性。
中小商户最典型的特征是做生意,赚当下的钱,有赞围绕中小商户,以软件服务商的身份,切入零售、美业、教育细分市场。
挖掘出商户网上开店、网上营销、管理客户、获取订单等需求,提供适用行业多场景的SaaS软件产品。
大多数时候,我们进入公司的时候业务定位和产品定位已经明确了,可通过业务负责人或产品负责人获知。
我们在产品设计时,需要围绕已设定好的产品定位去设计产品,清晰的业务定位,有利于产品经理了解团队当下做的事情和方向。
2. 业务目标
业务目标的主要获知来源,同样为业务负责人或产品负责人。
每个业务都会有1个或多个业务目标,即在一定时间范围内要完成的预期成果,如销售额、渠道转化率等。
业务目标需要产品目标做为落地的支撑,业务目标是定义产品目标的方向来源,只有明确业务目标,我们才能设定产品目标。
产品为配合业务目标的达成,会依据业务所处阶段和业务目标制定产品目标。
举例:
某TO B平台全年业务目标为1亿GMV,产品负责人根据业务发展阶段和业务目标,分析和制定了用户端和商户端的产品目标。
- 用户端:增长率为xx,留存率为xx、使用频率为xx,客单价为xx,复购率为xx等等。
- 商家端:不断深化运营管理、营销工具等方向的基础设施建设。
业务在不同的发展阶段,会面临不同的问题、矛盾,甚至机遇,所以,业务目标并不是不可变的,会因阶段而变化,产品目标也会随之发生变化。产品经理在工作中需时刻关注业务目标的变化,要与之适应设定不同的产品目标和产品规划。
3. 当前业务与其他业务的关系
企业为了给客户提供更多的产品和服务,或利用未被充分利用的企业资源,或避免单一业务的风险,或寻找新的增长点,甚至为了资本运作,会同时发展多个业务,建立业务矩阵。
了解当前业务和其他业务关系的目的是,一个业务体系为何会存在这些业务,这些业务之间是如何进行协同来支撑项目发展的。
TO B业务常见的方式是以某业务为核心,向产业链的上下游延伸开拓新业务,带动不同场景的其他业务,完善和互补业务场景,业务之间关联性很强。
滴滴出行以快车、出租车、顺风车、专车、代驾、单车等出行业务为核心。
通过挖掘个人车主/专职司机的车生活场景,提供缴纳违章、车险、优惠加油、养车等业务服务。
以及为企业用户提供差旅用车、加班用车、活动用车、会议用车等出行业务。
当然,也有业务关联性不强的情况,如支付工具想做社交。
了解当前业务在业务体系中与其他业务的关联,疏导出各业务的内在联系和推演发展趋势,有助于设计出更合理产品架构。
4. 业务角色
业务角色就是搞清楚这个系统到底有哪些人在用,可分为内部角色(如财务人员、销售人员、客服人员)和外部角色(如终端用户、商户、配送员)。
虽然TO B业务十分复杂,但只要拆分出业务角色了解他们的具体诉求,就能把握需求边界和业务流程,业务角色是业务需求的源头。
仓库人员角色有入库、出库、调拨、盘点等诉求。商户有营销活动、提高曝光度、经营管理等诉求。
拆分出业务角色只是开始,接下来,要明确哪些业务角色是核心?角色之间的层级关系是什么?角色的限制条件是什么?角色之间的差异是什么?角色之间是否有协作关系?角色之间是否有互动?等等。
TO B业务具有多人协作的特点,一个业务角色在不同的业务流程下,可充当不同的身份。
根据业务的承接和交互关系,可分为请求服务、响应服务、调度服务、完成服务类型。
如运营部门员工组织一次场外活动发起物料采购申请(请求服务类),运营部门主管审批通过(响应服务类),采购部经理审批和安排采购工作(调度服务类),采购部员工完成物料采购入库(完成服务类)。
同时,每个业务角色的诉求,会随着业务发展阶段的变化而变化。
5. 业务场景
业务场景是需求的灵魂,来源于真实的现场实景,通常存在某种需要被满足或解决的问题。
了解业务场景的目的在于获取需求和进一步分析需求,基于场景了解业务角色诉求和业务情况,可以让我们更清楚业务角色为什么会提出这些需求,他们想解决什么问题。
在梳理业务场景时,我们要从用业务角色的角度进行思考:业务角色可能遇到哪些问题?可能存在的异常场景?产品方案是否能解决他们的问题?
运营:话费订单可以增加人工“标记订单失败”功能吗?
产品:系统目前可以根据直充结果自动修改订单状态了,为什么还要人工标记订单失败?是遇到什么问题了吗?
运营:最近话费供应商经常不定期维护直充通道,导致话费直充时效不确定,导致投诉率上升,影响用户体验,人工标记订单失败后,可及时给用户退款。
产品:好的,以前为什么没有发生过这种情况呢?
运营:目前话费供应商的供货能力好像有点问题,经常维护其实是缺货,去找其他资源调货了。
从案例中的业务场景,站在运营同学的角度,我们还有很多问题需要考虑:
如果人工标记失败后但实际又充值成功了,怎么办?如果接入多家话费供应商,日常运营维护会不会很麻烦?当充值时效较长时怎样处理?等等。
业务场景分析的过程,其实就是解决问题的过程,针对这些问题,分别提出不同的解决方案,最后落地为产品方案。
业务场景衍生需求,基于需求设计产品。当我们充分了解业务场景之后,才能更好的设计产品方案。
6. 业务流程
业务流程是由不同业务角色分别共同完成的一系列活动,这些活动的内容、方式、责任都有明确的界定。
任何业务流程,都可从整体到部分、由上至下的角度进行理解。
首先根据业务定位和业务目标,以实际业务场景为基础,还原业务的主流程,再深入各个阶段的分支流程,考虑细节流程、辅助流程、异常流程,流程是否闭环,避免整个产品只有功能,而没有业务。
以某B2B电商为例,梳理出业务主干流程(已省略部分细节流程和异常流程),如下:
- 买家:注册/登录平台——选择商品——生成采购单——支付——收货
- 卖家:注册/建立店铺——发布商品——处理订单——发货——收款
其中“发货”流程属于业务主干流程分支流程,如下:销售出库——分配仓库——捡配单——分配物流——扫描出库
通过了解业务流程,可理解业务节点与业务节点之间,业务与业务之间的协同和集成关系。
否则看到的,可能是孤立的业务节点或业务,业务节点之间出现断点是无法协同支撑业务的。
同时,业务流程有严格的先后流转顺序限定,一定程度上也反映了流程之间的层次关系。如买家的进行订单支付,是建立在生产采购单的基础上。
7. 业务规则
业务规则能让业务角色知道在什么情况下,该做什么或不做什么,用于控制和影响业务目标,维持业务结构、规避风险的规范和策略,可分为通用业务规则和一般业务规则。
通用业务规则对业务的规范和导向作用,不是通过硬性的制度、规章手段来实现的,而是通过共同意识的引导来实现的,是一种软性约束,如企业价值观。
早期淘宝通过《大淘宝宣言》,明确消费者理应获得优于传统商业环境的商品与服务,消费者的地位至高无上。
当消费者与商家纠纷不清的情况下,淘宝客服基于《大淘宝宣言》的基本原则,应优先维护消费者的利益。
一般业务规则都是基于业务场景、业务经验或数据分析产生出来的,一个业务通常会包含很多不同类型的一般业务规则,如运营类规则、交易类规则、售后类规则等。
淘宝交易类中的超时规则,买家自拍下商品之时起算,超过24小时未付款的,交易自动关闭。
不同的企业会根据自身的业务情况建立适合的规则体系,同时还会根据市场环境调整业务规则。
在新冠病毒疫情期间,淘宝推出0账期服务,帮扶商家一起度过难关,意味着淘宝结算规则的变化。
理解业务规则能帮助我们更好的转化和设计产品规则,业务规则与产品规则存在着紧密而复杂的关系。
最后的话
无论是刚加入新公司,0-1设计产品,还是某个需求的产品设计。
做B端产品,实际上就是了解业务的运作,搞清楚复杂的业务逻辑,场景思考,对业务进行抽象,提出解决方案,最后产品化的过程。
而这一切,都是基于深入理解业务才得以开展的工作。
作者:青木,B端产品经理;公众号:青木产品笔记
本文由 @青木 原创发布于人人都是产品经理,未经许可,禁止转载
题图来自 Unsplash,基于 CC0 协议。
认真读完了还做了笔记!谢谢分享,对产品原则有一些模糊,请问在实际工作中在哪个阶段制定产品原则呢?
另外有个问题想请教作者,个人在参与B端产品设计的过程中,当感觉脑子里没有后台设计框架的时候,应该怎么做呢?有时对小功能细节的设计产生困惑,是该全力将需求优化更有效率,研发看了觉得技术上可行但是之前没有见过类似产品,还是循规蹈矩。
1、产品原则是整个团队必须达成的共识,需要团队整体配合推动和执行,种一棵树最好的时间是十年前, 其次是现在。
2、TO B产品都是与业务强关联的,是实际业务的具象化结果,可能对具体业务还不够熟悉吧。
3、这是效率和效果的问题,注重效率,可遵循MVP原则;注重效果,需要考虑投入产出比。
不懂就问:B端产品是包括“帮助企业达到业务目标”的产品和“针对企业的角度制定需求“的产品吗?(来自一个产品小白的提问
TO B产品的核心价值都是减本增效
说白了就是B端的需求基本上都是和业务相关的,无关人性、癖好。
嗯呢
优秀
very good,彩踩过,才晓得B和C区别,才晓得B端核心和基础是啥子,,,