万字长文解析:如何做好TO B产品?
这个被修昔底德陷阱笼罩的资本世界,并不会手捧鲜花迎接来我们的成功。历史之势从来不是无心为之,那这次为什么是TO B呢?要如何做好TO B 产品呢?本文是作者对自己五年运营工作内容的总结,来看要从哪些角度出发才能做好TO B产品。
一、互联网的下半场
过去,平台的黄金时代
互联网上半场的商业模式,主要是以满足C端用户需求为核心的平台产品,包括:社交平台、电商平台、团购平台、出行平台、内容平台。平台通过链接人与人,内容与人,商家与人,聚合大规模的流量。
图1:平台产品示例
互联网平台的核心优势:
① 超低的边际成本
平台公司的核心业务主要是信息服务,它每多服务一个用户所花费的边际成本极低。根据利润公式可知:
π(总利润)=TR(总收入)-TC(总成本)=TR(总收入)-TFC(总固定成本)-TVC(总变动成本)
其中,TR、TVC都是与Q(用户数量)相关的函数,只要TR-TVC为正数且TFC与Q的关系较弱时,规模效应会摊平TFC,实现整体盈利。
图2:当Quantity大于20时,产生正向的利润
② 赢者通吃的护城河
C端的平台产品显著区别于B端的是:“任一用户对平台的议价能力都很弱,单个用户的离开对业务的影响很小,并且C端平台规模有较强的马太效应(供需趋向于集中化),规模本身就是护城河。”
图3:流量与护城河
③ 网络效应筑造产品壁垒
如果淘宝/天猫只能购买一线城市的商品,那它很难有今天的规模与社会影响力。只有当它成为一款全国性的产品时,用户的需求才能更完整地被满足,它也才有更高的产品壁垒。一个硬币的反面,当一款产品无法通过网络效应提升壁垒时,它的竞争压力也会相对更大一些。
例:滴滴出行的快车业务属于本地生活业务,就算杭州的快车做得再好,对成都的快车业务是没有显著增益的,没有网络效应也就意味着在不同地区都可能直面竞争压力。就像两年前美团打车上海、南京与滴滴直接竞争。
④ 高技术杠杆
上半场的产品大多都是以代码为核心生产力的,技术的高杠杆在于:
a. 能够通过快速的迭代来创造用户价值。
因为,C端平台关注核心用户的画像,产品标准化程度更高。代码属于很轻的技术资产,不涉类实体行业的库存及现金流占用问题,沉没成本更低。
b. 数据与算法的应用降低了信息/交易的撮合成本,提升了用户获取信息及交易的效率。
其实,每一次新浪潮的开始,我们都能见到很多自信的、跃跃欲试的闯入者。那些一夜暴富的故事,支撑着雾霾下每日4小时的通勤人,他们是造梦者的门徒。直到潮水褪去,我们才在不断地离别、叹息和马后炮中,看见了市场它最冷静的一面。
流量红利殆尽,产业亟待升级
移动端的流量红利是互联网上半场创业市场繁荣的根本原因,海量的新流量,从供给端拉低了平台产品的获客成本。
然而在2018年后,移动端增速见顶。根据Quest Mobile的数据,2019年1~6月移动互联网MAU仅净增570万,Q2甚至净降了193万,预示着移动互联网进入“存量残杀”时代。
图4:移动互联网MAU趋势
1)TO B是顺势而为
2016年7月,王兴提出了“互联网下半场”的概念,他提到:“美团点评作为国内最大的互联网餐饮平台,过去几年做的只是很薄的互联网化,即帮助企业引流。接下来要实现和行业的深度融合,全面帮助它们提升效率,降低成本。”
历史之势从来不是无心为之,那这次为什么是TO B呢?
就在2019年,中国人均GDP正式迈入1万美元梯队,奇迹四十年彰显了中华民族韬光养晦、努力奋斗的民族底色,也给了Z世代的年轻人足够强的文化自信、道路自信。
但是,这个被修昔底德陷阱笼罩的资本世界,并不会手捧鲜花迎接来我们的成功。相反,在外部,富有针对性的遏制措施越来越多,霸权思维主导的国际秩序下,民粹、贸易保护主义抬头。强者间斗而不破,开始进入全方位的战略竞争期。
图5:2020年中美贸易协议双方需要履约的条款统计
在内部,劳动力受旧政策、新环境的复合影响,出现断崖式下降,成本不断攀升。导致低端制造业比较优势丧失,相关产业逐步转移至东南亚、印度、巴西等地区。
中国制造的升级需求急迫。
2018年中国出生人口达1523万,比上年减少200万人,是近40年来中国出生人口环比下降最多的一年。
2019年,中国美国商会(AmCham China)针对239家在华美资企业的调查显示,22.7%的公司将把供应链从中国转移出去,19.7%的公司正考虑将部分或全部制造业迁出中国,33.2%的公司将推迟或取消其投资,只有2.9%的公司将增加其在华投资。
还需要清醒认识的是:“我国的科技实力、大学教育、基础科学,相比美方仍然有巨大的差距。”
应该避免盲目自信稀释了专注度。
宏观层面,仍高度依赖发达国家的高科技产品(进口);中国智造想要迈向全球,也还长路漫漫。微观层面,传统行业信息化水平低、企业管理粗放、诚信体系缺失、供应链效率不足,制约着中国从量到质的转型。
这是未来10年必须要变革的难点,也是TO B赛道的历史机遇。
图6:半导体、飞机等高端制造,中美差距巨大
2)TO B的快速车道
相比于上半场以C端用户的规模效应、网络效应筑造护城河,下半场转向更多的企业服务,以及传统行业升级,包括,
①以企业为核心的产品/服务
包括:餐饮Saas、开店Saas、人力资源(组织发展、员工福利)、协同办公(Confluence、Teambition)、数据服务(神策数据、飞瓜数据)、云服务、人脸识别、无人驾驶等。
② 传统行业数据化、智能化、供应链优化
包括:新零售、物流科技、长租公寓、K12教育、AI芯片等。
区别于互联网上半场更高频、短链、碎片的移动场景,下半场对产品经理提出了新的挑战。
- 产品/服务不再完全以系统为核心,产品经理需要更多关注业务的场景、流程、组织、角色、供应链,去设计“服务”而不仅是“系统”。
- 用户体验由“抽象的主观效用”转换为“可量化的收入与生产成本”,要求产品经理有更强的业务认知、商业敏锐度。
近几年,TO B方向已经诞生了很多优秀产品。例如:有赞、旷视、Teambition、阿里云、钉钉、神策数据、G7等等。相信就在不久的将来,中国也将诞生像Salesforce、Atlassian、ZOOM、Slack这样千亿、百亿美金的企业服务公司,大势之下,只是时间问题。
图7:美股排名靠前的企业服务公司
二、TO B,业务下沉
1. 业务设计与有效工作
世界上没有完美的规划,但全面、严谨的业务设计,能够大幅提升组织的有效产出。如果在这件事情上懒惰,天天拉着团队打鸡血、画饼、打仗,中长期持续的负反馈,很容易让团队崩盘。
1)业务设计要相信专家
相比较那些聪明、年轻的头脑,业务专家更值得信赖,因为B端很多线下的细节和业务逻辑,需要足够长的项目积累才能有判断力。互联网人在产业中往往不是用户,只能凭借逻辑或者类比法来演绎,决策的有效性不高。
2)业务设计要心怀敬畏
不管你做过多少DAU的产品、多么闪亮的教育背景,面对传统行业,都是从零开始。一定要对行业、前辈心怀敬畏,互联网在这里很难颠覆谁。
3)业务设计要勤于思考
- 问:业务设计不是CEO、总经理关注的问题吗?和我有什么关系?我只想扎扎实实做好产品、运营。
- 答:扎扎实实做产品、运营和关注行业趋势是不矛盾的,这种东西不观察个3年、5年也观察不出什么,思考核心问题不怕早。并且,没有公司需要一个35岁的活动策划专员,努力认知业务是个人从点→面的过程。
2. TO B 的业务设计概述
图8:TO B的业务设计概述
(1)业务分析
业务分析是为了“发现机会”与“预警风险”,对于TO B业务,除了常规的行业分析、用户分析,需要重点关注“监管趋势、政策走向”,并不是所有的行业监管都允许先粗放发展再加强监管,死亡可能是突然休克式的(电子烟、比特币)。
① 宏观经济
宏观经济的走势对企业融资成本、现金流压力是直接关联的。对比个人消费者被宏观经济的影响有逐级的传导迟滞,企业一定是更敏感的。关注的核心模块,包括:出口/内需/投资的战略变化(例:近几年对外资的政策松绑)、货币政策的变化(例:近期的公开市场操作、准备金率变化)、税收政策变化(例:增值税税率变化对业务进销项的影响)、地方政策(包括:人口政策、产业政策)等等。
② 监管趋势
顺势而为,是保障业务能够持续发展的必要前提。滴滴规模近似垄断后迎来的管制压力,我认为本质上是国家对核心民生行业的行政干预预期较高,因为涉及到社会稳定、安全,强管制是有必要性的。
同样,像比特币这类去中心化、发行不由官方控制的所谓“货币”,在当前的监管层面上,肯定也是无法被接受的。以大局为重,是一个取舍的过程,4.025%的年金险下线也是同理。
③ 分析框架
分析框架需要站在行业的角度、客户的角度、需求的角度,评估业务的可行性。
案例:做一款TMS(运输管理系统),解决规模型车队的管车问题。
a. 行业基本情况与发展趋势概述
- 商流驱动的集约,受电商飞速发展的影响,中国集约性比较强的运输领域以快递为代表,CR5已接近70%,也带动了一些成规模的运输车队(下游)。
- 成本压力逐级传导,但由于快递行业过于集中,核心企业货量庞大议价能力强,成本压力逐级传导,中下游的运输公司经营压力大。尤其那些重资产、大规模的车队,其资产管理、资产利用率、成本控制等多个方面都对运营能力提出了极高的要求…..(不赘述,参考咨询报告)
b. 客户概述及上下游分析
- 目标客户画像,拥有>100台卡车以上的运输公司,因为这种量级的客户才有优化管理成本的需求,目前这种规模的运输公司全国大概有10000家(假设)。
- 客户的上下游分析,这些运输公司的上游是通达系、德邦这类大型快递、快运公司,下游有自有购置的车辆,也有社会运力。当前的行业现状是:“运力相比货源大幅过剩,整体议价能力较弱。”除电商外,整体商流的集中度不足、需求个性化,无法形成高度集中的物流市场……(多维度、信息详尽)
c. 客户在成本、效率上有什么痛点?
- 效率瓶颈:公路运输核心还是在成本、履约质量上,为了保障履约,部分企业购入大量固定资产(车头、车挂)自营运力。与其他实体行业一样,这将面临着业务波动带来的周转效率问题。
- 品质管控:因为快递、快运对于运输的时效要求很高,供应商需要及时了解车辆位置,做好时效控制,降低时效罚款(大概占其总成本的5%(假设))。
- 边际成本:实体资产无法像代码资产那样,边际成本趋向于一个极低值,相反,每一个时间段内,一个货车只能运送一趟货物,这就决定了该场景下技术杠杆不会特别高,运营的效能非常关键。
- 现金流压力:中游运输公司需要承担>2个月的账期(甚至半年),相比快递、骑手这类即付现金流的模式,账期带来的资金压力也限制了业务规模。尤其在利润相对微薄的情况下,即使通过保理融资解决了现金流的问题,其所带来的成本上涨,对实体运输企业也可能是不可承受之重。……(业务经验比逻辑闭环更接近事物的本质)
d. 业务的可行性分析
- 需求验证:管车的需求是真实的,主要是为了减少管理成本、降低迟到罚款。目前竞品已经切入了100家大客户。付费意愿大概在1500元/年,续费率75%。(注:上述数据皆为假设。)
- 切入路径:目前通达系的供应商(我们的客户)都必须安装一款XX品牌的监控设备,如果想要切入该类客户,本质是需要搞定它的上游,客户不会重复采购两款类似的产品。
……(仅做示例,竞争力评估、关联市场影响等不在此赘述)
总结:只有深入了解供应链上下游的关系、供需基本面,才能更好地做销售、产品、运营的决策。
(2)业务设计
业务设计的重点是“知己知彼、产品下沉、运营业务”。
① 知己知彼,百战不殆
不同的业务所处的行业周期、竞争情况都很不一样。但最抽象的一层,仍然是以“解决客户需求”为核心。需要通过持续分析竞品、完善服务体系、制定符合业务发展阶段的增长策略,去构建核心竞争力。
a. 产品分析
调研竞品是一个自省、迭代的过程,主要目的是为了评估客户需求集合的满足程度,以及产品切入场景后的角色体验问题。关注客户的核心需求满足程度。B端业务需要满足企业的需求集合,而非单点打透。如果产品功能覆盖度不够,难以构建竞争力。
例:一款餐饮Saas,80%的用户不仅需要收银功能,还需要“经营分析、报表管理、营销管理、排号等位”等10项功能。产品A仅能满足其中5项,产品B全部满足,则产品A难以与B竞争(价格相差不大)。
图9:中国典型餐饮Saas竞争力分析
产品的操作体验是否能被客户的组织接受,也很重要。如果仅仅只是老板买了单,但客户的组织、各关键岗位无法接受系统的流程/交互,产品切入会受到各种各样的阻力,落地困难。
b. 销售策略分析
在有限的预算与HC的条件下,根据竞品的销售资源、销售策略,去制定ROI更高、长线收益更大的销售策略,是很有必要的。
- 客户:梳理竞品的客户清单,盘点客情关系及服务深度。
- 策略:梳理竞品的拓展策略,盘点其核心优势区域及下一步重点拓展的区域。
- 增长:梳理竞品在拉新、留存上的人力配置、补贴策略,能帮助我们更有针对性地开展差异化的增长策略。
例:产品A拉新方面投入了大量的线下力量,且线下销售的核心任务都压在了新增上面。此时,产品A通过“留存激励”的运营策略,即只要商户交易额在次月保持上个月的80%以上,即可获得“高额奖励/折扣”等(通过电销营销),以此减轻线下销售的存量客户维护压力。这笔营销费用需要与所释放销售的获客价值相比较。
② B端产品经理的业务下沉
TO B产品提供的是一套完整的服务,可以分为两个维度来看:
图10:看待服务的两种视角
- 面向客户(外部),业务需要交付“用户视角的产品与服务”,即:“用户会使用什么软件,体验什么样的服务流程,最终支付多少钱。”产品解决方案要满足需求、服务好、价格合理。
- 面向组织(内部),产品解决方案是由基础的职能分工(业务运营、业务产品)与多个项目共同构建的,所有的人力资源、财务预算配置,都需要以“保障面对客户视角的服务、体验不断改善”为核心目标。
B端产品经理如何创造价值?
抽象来看,产品经理最核心的能力应该是“解决问题的能力”,进而为用户创造价值。
图11:产品经理的核心能力
《俞军的产品方法论》中提到:
对于用户,大家有不同的理解,通常的理解是用户即自然人。以微信为例,一般的统计报告可能显示其“用户”为11亿,如果把微信的其他功能(支付、公众号、小程序、朋友圈、群等)都删掉,只留下通讯功能,它的用户数可能还是11亿,但它的商业估值可能就从2000亿美元变成了200亿美元。这种将用户定义为自然人的做法,显然在大型互联网产品上并不适用。
从产品经理的视角来看,用户不是自然人,而是需求的集合。
关于需求集合,C端与B端产品是有所区别的。
图12:需求集合的差异
做好C端产品,要能够洞察人性本质的需求,要求产品经理除了有较强的逻辑、同理心之外,更要能透过现象看本质。世界上最成功的C端产品,都是人类本质需求的满足者,比如:微信的熟人社交、字节跳动的推荐算法、Uber的出行服务。
但做B端产品,还需要产品经理有优秀的商业感觉。产品必须是一个业务专家,要能梳理业务的“供需关系、生产管理、组织管理、供应链管理、财务管理”等相关信息。有能力挖掘企业的效率、成本的痛点,并打造满足企业需求集合的产品。例:钉钉,一款老板验高于一切的协同办公产品,一款优秀的老板呼叫器、考勤管理利器。只需要轻轻地夺命DING一下,员工24h在(bei)线(po)办公,老板能不喜欢吗(微笑)?
B端产品的货币时间价值:
1)现金流
A产品,营业收入105万元,总成本100万元(当期支付),此时的利润是多少?5万吗?
但如果这105万是应收账款,实际1年后才到账:
Ⅰ 假设贴现率5%,未来1年的105万收入在当期仅值100万,所以,考虑货币的时间价值,当期的利润为0。
图13:货币的时间价值
Ⅱ 由于105万的应收是1年后才到账,意味着当期支付的100万需要流动资金支持,此时使用100万自有资金周转业务(假设利率5%),该笔资金当期的机会成本为5万元。
业务的收入现金流是财务模型的关键点,像快递、滴滴这类客户即付,对下游供应商(运输车队、滴滴司机)有账期的业务,资金占用没有压力,有迅速做大规模的条件。但下游供应商如果想做大规模,周转资金反而成为较大的阻碍点。
2)NPV计算
只要当成本投入与收入有时间错配,NPV计算就是非常必要的。
图14:NPV计算公式
例:当期为了拉新用户,产品A共计投入补贴1000万元,获得的用户在第12个月单月合计贡献了1050万的利润,贴现率5%,当期价值Present Value 为1000万元。故可得NPV=0。
图15:各时段现金流的现值计算
总结:做业务决策时,如果不考虑货币的时间价值,往往会导致做投产比分析结论有误,带来无谓的财务亏损。
B端产品的用户调研:
图16:B端与C端用户调研的差异
B端业务场景往往是非生活化,需求的搜集与分析,没有过往经验的支撑,更需要产品经理深入当前的业务场景中去,了解:
1)客户的决策机制、切换成本
实际决策人是核心需求的来源,组织的各角色是产品的实践者,他们的需求都需要了解(以决策人为核心)。
例:为餐饮商户提供外卖接单系统,商户决策因素有:加入美团点评后,店铺的流量获取能力会与哪些指标相关,收入抽成比例,提现规则(资金占用),营销工具包(会员、积分、优惠券)等等。
对于已经使用竞品的客户,除了考虑产品、成本差异,还要考虑切换成本,尤其那些与客户系统打通竞品(可能两边花了几个月时间才打通)。
我们产品的新体验能否超出旧体验+切换成本?如果不能,客户凭什么切给我呢?(答:也许可以通过销售动作补产品不足,为什么会有大保健?)
2)梳理业务流程、组织角色及其KPI
梳理流程是业务设计最核心的工作之一,它类似C端的用户体验地图,通过梳理各个节点的“效率、成本”痛点,找到产品的核心价值点,并基于此去创造新的用户价值。
图17:瑞幸咖啡的用户体验地图(示例)
3)梳理各角色及其KPI,更有助于改善服务能力、产品体验。
例1:调研客户组织后了解到,采购经理的KPI除了找性价比更高的供应商,还要求供应商的履约品质必须达到公司设定的标准,这决定了业务的资源投入(例如:客服、Local人员的投入)。
例2:对于订单录入的操作员,每个人负责的线路相对固定,高峰期每日录入100单,每一单都需要重新选择出发地、目的地,操作成本太高,应该设计常用地址库功能解决这个问题。
B端产品的设计概述:
1)了解程序设计的MVC范式
Model指数据模型、View指前端交互图,Controller指业务逻辑。任何一套软件系统运作的本质都是相同的;用户在前端交互层操作后,系统通过业务逻辑层处理数据层的数据。
图18:MVC范式
2)从业务流程到产品架构
业务流程梳理是产品设计的重要基础。
假设做一个外卖系统,一个商家要开店接单,最简易的流程需要有:注册认证→开店→接单→提现。流程之下就是需求的集合:
注册认证:需要哪些资料、资质?审核标准、时效要求是什么?
商品管理:支持排序管理?支持哪些信息修改?商品图片支持多大规格?配置商品数量的上限是多少?
逆向流程(重要):逆向流程的完备性决定了销售、客服、技术的无谓成本。完备性不足将可能导致技术分散精力去解决偶发的逆向问题,影响开发进度、质量。
- 不同订单状态下,客户发起取消的业务逻辑应该有什么不同?
- 骑手因故无法取餐,商家端是否需要支持发起重新匹配骑手?
- 客户点的某一样商品无货,商家是否支持部分退货?
- ……
图19:商家入驻外卖平台
3)基于业务流程对应的需求集合,梳理产品架构
基础功能:包括用户、支付、消息、发票等,可能会接入统一的中台服务,需要基于业务需求逐个梳理功能细节。
例:因监管要求,营业执照有效日期单独录入字段,做较强的业务限制(超期不更新无法再接单)。
业务功能:包括订单服务、营销工具包、门店管理、权限管理等。
图20:产品架构图(示例)
Ⅰ订单作为核心服务,其状态设计及各状态下的逆向流程非常重要,决定了商家自助经营的能力。
Ⅱ营销工具,核心是赋能商家销售,包括:送券、卖券、满减、秒杀价、广告投放等等。
Ⅲ权限控制,主要参考RBAC(Role-Based Access Control)模型。其中最简单的用户、角色、权限模型,包含了2种情况:
- 用户和角色是多对一关系,即:一个用户只充当一种角色,一种角色可以有多个用户担当。
- 用户和角色是多对多关系,即:一个用户可同时充当多种角色,一种角色可以有多个用户担当。
注:权限管理涉及到子角色、继承、互斥、数量约束等逻辑,在此不一一展开。
图21:RBAC模型
总结:当角色的权限边界较为清晰时,可考虑使用多对一的权限设计。若不满足该条件,则最好使用多对多的权限体系(避免大量用户都要独立建设角色,变成一对一的权限管理),保障系统的可扩展性。
例:小代既是销售运营,也负责财务对账,那小代就应该同时拥有销售运营与财务对账两个角色的权限。
③ 卓有成效的业务运营
1)业务的增长解构
a. NDR,增长的试金石
图22:ARR示意图
如上图,客户的年度经常性收入(Annual Recurring Revenue)可按用户新增年份划分为不同的颜色,可以清晰看到,一个有好的收入留存(Net Dollar Retention)的企业软件产品,其增长极大程度由老客户来推动,每年新客的获客压力很小。
注:收入留存Net Dollar Retention,指存量客户在新一年产生的所有收入(包括原有模块的续费与增购,新模块的增购)作为分子,这批客户在前一年产生的所有收入作为分母,两者相除。
b. 商业模式决定增长策略
业务增长由老客户留存收入+新客户收入组成。
- 留存周期很短的业务,大量成本都会花在了销售费用上,需要持续拉新才能保持增长。例:英语培训、婚庆服务。
- 留存周期很长的业务,收入可以更多转化到技术、产品迭代中去,提升自己的核心竞争力。例:协同办公、知识管理、云服务。
例:Atlassian 的敏捷管理矩阵有“ Trello、JIRA、Confluence”三款产品,其超高的留存率反映了产品的粘性。根据2019年的投资者报告内容,Atlassian为花费5万美元或以上的客户实现了98%的保留率,其中90%的客户购买了3种或3种以上的产品。
图23:Atlassian的留存、购买数据
总结:当商业模式的留存能力较高时,成本投入可以更多倾斜到存量客户的价值满足上,用存量支撑增长的基本面。反之,只能将预算都投入到持续的拉新中去,此时存量客户的体验保障往往成为一个难题,婚纱摄影就是典型的销售大于服务,套路繁多,意图一次榨干的行业。
2)业务运营的设计概述
业务运营是集增长、服务、数据、研究于一体的运营体系。不仅要对外提供营销策略、客户服务,更需要对内交付决策支持、用户反馈。
图24:业务运营架构图(示例)
对外,业务运营是营销策略、客户服务、培训支持等。要实现业务的增长目标,并为客户提供更好的的业务体验。
对内,业务运营是流程管理、数据分析、行业/用户/政策研究及运营支持,目标是保障业务运作的高效、流畅,保障业务决策的有效性、合理性。
a. 如何实现增长?
业务增长主要还是围绕营销策略展开的,包括产品定价及搭售方案、销售策略。
Ⅰ 定价与搭售
中小客户标准品,要参考竞品的定价模式,实施与业务节奏匹配的的搭售策略、促销策略。对于高续费率的产品,可在拉新上投入更多预算。
例:假设Teambition给企业版购买者提供知识积累产品Thought半年10人的高级权限,由于知识积累属于切换成本很高的产品,灰度测试续费率约75%(假设),综合收益依然可观,搭售方案可行。
对于大客户,要有完善的报价机制。包括:客户档案建设、个性化需求搜集、决策人影响(要避免花了很大力气BD,没找对实际决策人)、方案设计与成本评估。
图25:Teambition价格方案
Ⅱ 销售策略
要开展全国性的业务,销售资源的配置是核心决策点,关系到整个业务的成本与产出。
盘点:围绕增长目标,设定销售指标的拆解逻辑。盘点存量客户的产出预期,评估增量客户规模,并梳理潜在客户列表及对应的HC需求。
合作:销售与事业部的组织关系,决定了业务在前台推进的效率。
如果销售体系闭环在事业部内部,产研、运营与销售的合作,主要围绕KA需求的敏捷支持以及高优先级Feature List的迭代交付,围绕研发资源的配置,需要高频沟通。
如果销售属于中台体系,承接各事业部需求,业务需要先确认销售的资源配置方案,包括:绩效考核的逻辑、业务的激励规则等等。围绕销售资源的配置,需要重点沟通。
路径:是先从单一客户突破,还是从重点区域突破?要基于业务实际的竞争情况考虑。如哈罗单车初期就避开了一线城市,在二三线城市站稳了市场,最后切入一线城市。
模式:直营服务品质更好,为了拿下重点、核心城市,可能会使用直营模式;对于业务量小、基数庞大、单个价值低的中小型城市,可能会使用成本更优、速度更快的加盟模式。
b. 构建服务体系
C端产品,单个客户的流失对平台损失不大,客服体系可能会侧重构建标准、广覆盖的服务能力,尤其要在成本与收益面前做再平衡(例:印象笔记甚至没有电话客服,客服流程通过邮件处理)。
但由于B端产品的客户价值相对更大,需要更完整、深度、个性化的服务,才能提升客户留存水平。为了实现这个目标,至少需要满足三点:
- 让客户方便地找到我们,搭建覆盖度高的服务窗口。
- 搭建售前、售中、售后多层次的服务能力。
- 实现数据闭环,便于高效、全面地评估服务质量。
图26:搭建服务体系的要点
客户服务不单单是一个体系问题,更是一个文化问题。
如何看待用户的反馈?是真的闭环处理,还是记录后石沉大海?客服的应急权限有多大?
这些问题的背后,体现了业务负责人对用户的真实态度。
3)面向经营的数据体系
数据体系核心是面向经营提供业务观察、业务诊断的能力,它的结构类似MVC结构,前端是可视化的控件,中间层是数据仓库以及对应的报表结构,底层是业务分析的体系。
图27:业务的数据体系
c. 业务分析体系(核心)
分析的目的是诊断、监控。业务分析可以大概分为2个模块:什么样的数据表现是健康的?哪些项目需要重点监控?
根据2个模块的具体内容,再结合业务构建指标体系:
- 业务健康度指标:判断业务是否健康发展的核心指标集合,任一指标出现问题都预示着业务存在较大的健康风险。一般健康度指标都有明确的目标,便于做业务发展的过程管理。
- 分析型指标:业务分析逻辑链路上的过程指标,以及其他需要重点监控的指标。由于业务不同阶段的侧重点不一样,监控的方向也各不相同。
例:业务冲刺阶段,业务负责人希望重点关注客服质量,避免高成本拉来的客户因为客服质量不满意而流失。
图28:业务分析体系框架(示例)
d. 数据仓库/报表体系
有了业务分析逻辑,就可以开始搭建业务报表了,这是一个从想→做得过程。在MVC的架构中,前端层、业务逻辑层都会有数据上报,形成数据库表/日志。
图29:数据的形成
了解产品数据结构的业务运营,对分析的实现才有更强的判断力,也更能够理解各系统间的交互逻辑。
所以,在产品设计初期,业务运营就需要和业务逻辑层(后端)沟通各个服务、系统的数据记录的字段、规范,避免业务所需的关键数据漏存。
图30:业务数据的表结构(示例)
通常,业务分析体系的指标,往往需要关联多张核心表关联计算,例如:用户表、支付表甚至其他业务的表,单一业务方难以实现。为了解决这个问题,大数据部门通过拉取各业务的数据,经过流程调度、数据清洗、数仓建表,最终提供数据服务(例:可视化平台、用户标签查询、报表服务……)为业务方赋能。
在数仓的建设过程中,最好能有懂业务、数据结构的业务运营与大数据工程师共同建设,保障“业务分析逻辑”→“技术实现”的信息传导足够对称。
图31:数仓整体的技术架构(示例)
e. 数据可视化
数据可视化,实际是将数据信息以更低的阅读成本提供给数据消费者。不同类型的数据适合不同的展示方式。不必过度追求炫酷的效果,时刻关注它的核心价值是“更低成本的阅读”。
推荐工具:Tableau
图32:Tableau展示案例(Hanah Anderson、Matt Daniels)
④ 敏捷的项目管理体系
一个业务要持续前行,有两种工作要做:
- 重复性工作,例:日常的数据监控、客服等运营工作。
- 项目型工作,通过完成一个新项目改善产品/运营,从而让业务发展得更好。
图33:业务与项目的关系
互联网行业,业务从0~1的过程中:
- 需求变化很快、要求整个组织足够敏捷、高适应性地去为组织提供服务。
- 团队规模的扩张,没有体系化的项目管理,将出现:“信息不对称、进度把控弱、协同成本高、边界不清晰”等问题。
图34:项目管理的急迫性
1)敏捷的业务运营
如同产品是迭代出来的,运营要持续优化业务,也必须采取迭代交付的模式,以应对多变的业务需求。
图35:迭代式开发的优势
我通过3年的实测与迭代,验证了“建设以Scrum(敏捷)为核心的项目管理体系,确实能有效提升运营团队的自我管理、高效沟通、适应变化的水平”。
下面我会简单介绍下敏捷运营的方法。
2)什么是Scrum?
Scrum一词来自橄榄球运动中的“并列争球”。在软件开发历史过程中,Scrum 先驱们将 Scrum 这个词的隐喻应用于软件开发。它是一套轻量级的核心价值观、原则和实践,统称为 Scrum 框架,在这个框架中人们可以解决复杂的自适应问题,同时也能高效并有创造性地交付尽可能高价值的产品。
在这个框架下,我们可以检验团队是否符合 Scrum 原意的要求:
- 团队成员是否有共同目标?
- 团队成员是否开诚布公地紧密合作?
- 团队成员是否经常检视和调整?
- 团队成员是否各自发一颗球(各做各的用户故事等),各自努力往后场冲刺以争取个人绩效?
- ……
图36:Scrum Process
3)Scrum的运营实践
Scrum的运营实践,借鉴了Scrum在产品开发上的应用。
它是一种有计划、持续迭代的运营策略。通过多次交付来应对需求的变化,逐步得到一个完善的解决方案,并影响业务的结果。
图37:Scrum运营实践概述
a. Scrum运营有哪些角色?
BusinessOwner(BO):业务负责人
职能:负责勾勒业务愿景、为业务指明方向、计划节奏、考虑成本等。他一方面要理解用户、利益干系人的需求。另一方面,对正在推进的业务,要和产品、运营、研发团队紧密合作,验收各方交付出来的产品。
Scrum Master(SM):敏捷教练
- 职能:Scrum Master 既是 Scrum 团队的教练,是团队服务型领导、“保护伞”和“清道夫”。
- 负责指导团队在通用的 Scrum 框架上建立并遵循自己的过程,帮助每个参与者理解并乐于接受 Scrum 的价值观、原则和实践;
- 充当教练、在过程方面发挥教导作用,帮助团队以及组织中的其他人指定合适的高绩效、有组织特色的 Scrum 方法;
- 负责保护团队不收外部干扰和障碍,(在个人无法有效解决遇到的障碍时)发挥领导作用,清楚阻碍团队生产率的障碍;
- 他是领导者,不是管理者。
Operation Team(OT):运营团队
职能:负责确定如何交付业务负责人要求的成果,负责运营的策略设计、数据分析等工作;团队成员整体具备的技能,需要足以实现业务负责人要求交付的业务价值。
b. 项目管理概述
Ⅰ 业务计划(Business Planning)
每月的OKR评审会议将产出“业务代办列表、OKR”。
主R:业务负责人(BO)
- 待办业务列表:评估业务工作及优先级。
- OKR:评估一段时间内业务的目标及关键结果。
图38:Uber的OKR示例
Ⅱ 冲刺计划(Sprint Planning)
主R:Scrum Master
基于“OKR、业务待办列表”,Scrum Master需带领敏捷运营团队,将“业务待办列表”中的工作拆解为下一个冲刺(Sprint)的“工作包”列表。
工作包是一个有明确时间节点的可交付成果。
图39:业务待办事项与工作包的差异
Ⅲ 冲刺(Sprint)
主R:Scrum Master、运营团队
时间盒
以时间盒(例:2个自然周)为单位进行冲刺(Sprint),持续交付工作包。在每个时间盒结束后,重新评估一次“业务待办事项列表”所需交付的工作包是什么,以适应业务的变化。
图40:业务待办事项与工作包的差异
看板
使用“看板”作为“信息发射源”,同步各项目冲刺(Sprint)的工作包状态。
图41:Teambition看板
Ⅳ 冲刺回顾(Sprint Retrospective)
主R:运营团队
每个月结束(约2个Sprint),结合OKR做冲刺回顾(复盘)。回顾的目的是:
- 评估目标及达成情况
- 遇到了哪些问题?有什么亮点?
- 总结经验教训、客观规律
- 总结接下来冲刺(Sprint)的改善项
- 团队进行充分的交流、沟通
总结
写到这里已经12000+字了,算是对5年业务运营工作的总结。
其实不管是产品也好,运营也好,最终的目标都是做一个业务负责人,只有持续地去认知行业,打磨自己产品、运营、商业能力,构建自己的轮子而不只是在得到上听别人的轮子,我相信未来才能跑得更从容一点。
最后,祝大家开工大吉!
参考文献:
《2019年中国报告》,麦肯锡全球研究院,2020年;《企业服务创业者必读:影响公司估值和发展的核心指标 | GGV投资笔记第十一期》,GGV纪源资本;《俞军产品方法论》,俞军,中信出版社,2019年;
《决胜B端,产品经理升级之路》,杨堃,电子工业出版社,2019年;
《两万字谈谈如何使用 Scrum 框架进行敏捷开发》,@yishuailuo,2017年;
《RBAC模型:基于用户-角色-权限控制的一些思考》,公众号:PM珣玗琪。
作者:一只特立独行的Eric;公众号:一只特立独行的Eric
本文由 @一只特立独行的Eric 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CC0协议
微多少
公众号:一只特立独行的Eric
交个朋友吧
公众号:一只特立独行的Eric
微信交流
感谢支持
769710589
有深度接地气