1

互联网的下半场

过去，平台的黄金时代

互联网上半场的商业模式，主要是以满足C端用户需求为核心的平台产品，包括：社交平台、电商平台、团购平台、出行平台、内容平台。平台通过链接人与人，内容与人，商家与人，聚合大规模的流量。

图1：平台产品示例

互联网平台的核心优势

① 超低的边际成本

平台公司的核心业务主要是信息服务，它每多服务一个用户所花费的边际成本极低。根据利润公式可知：

π(总利润) =TR(总收入)-TC（总成本）=TR(总收入)-TFC(总固定成本)-TVC(总变动成本)

其中，TR、TVC都是与Q（用户数量）相关的函数，只要TR-TVC为正数且TFC与Q的关系较弱时，规模效应会摊平TFC，实现整体盈利。

图2：当Quantity大于20时，产生正向的利润

② 赢者通吃的护城河

C端的平台产品显著区别于B端的是：“任一用户对平台的议价能力都很弱，单个用户的离开对业务的影响很小，并且C端平台规模有较强的马太效应（供需趋向于集中化），规模本身就是护城河。”

图3：流量与护城河

③ 网络效应筑造产品壁垒

如果淘宝/天猫只能购买一线城市的商品，那它很难有今天的规模与社会影响力。只有当它成为一款全国性的产品时，用户的需求才能更完整地被满足，它也才有更高的产品壁垒。一个硬币的反面，当一款产品无法通过网络效应提升壁垒时，它的竞争压力也会相对更大一些。

例：滴滴出行的快车业务属于本地生活业务，就算杭州的快车做得再好，对成都的快车业务是没有显著增益的，没有网络效应也就意味着在不同地区都可能直面竞争压力。就像两年前美团打车上海、南京与滴滴直接竞争。

④ 高技术杠杆

上半场的产品大多都是以代码为核心生产力的，技术的高杠杆在于：

1. 能够通过快速的迭代来创造用户价值。因为，

• C端平台关注核心用户的画像，产品标准化程度更高。
• 代码属于很轻的技术资产，不涉类实体行业的库存及现金流占用问题，沉没成本更低。

2. 数据与算法的应用降低了信息/交易的撮合成本，提升了用户获取信息及交易的效率。

其实，每一次新浪潮的开始，我们都能见到很多自信的、跃跃欲试的闯入者。那些一夜暴富的故事，支撑着雾霾下每日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：美股排名靠前的企业服务公司

2

TO B，业务下沉

业务设计与有效工作

世界上没有完美的规划，但全面、严谨的业务设计，能够大幅提升组织的有效产出。如果在这件事情上懒惰，天天拉着团队打鸡血、画饼、打仗，中长期持续的负反馈，很容易让团队崩盘。

1）业务设计要相信专家。相比较那些聪明、年轻的头脑，业务专家更值得信赖，因为B端很多线下的细节和业务逻辑，需要足够长的项目积累才能有判断力。互联网人在产业中往往不是用户，只能凭借逻辑或者类比法来演绎，决策的有效性不高。

2）业务设计要心怀敬畏。不管你做过多少DAU的产品、多么闪亮的教育背景，面对传统行业，都是从零开始。一定要对行业、前辈心怀敬畏，互联网在这里很难颠覆谁。

3）业务设计要勤于思考。

• 问：业务设计不是CEO、总经理关注的问题吗？和我有什么关系？我只想扎扎实实做好产品、运营。
• 答：扎扎实实做产品、运营和关注行业趋势是不矛盾的，这种东西不观察个3年、5年也观察不出什么，思考核心问题不怕早。并且，没有公司需要一个35岁的活动策划专员，努力认知业务是个人从点→面的过程。

TO B的业务设计概述

图8：TO B的业务设计概述

1）业务分析

业务分析是为了“发现机会”与“预警风险”，对于TO B业务，除了常规的行业分析、用户分析，需要重点关注“监管趋势、政策走向”，并不是所有的行业监管都允许先粗放发展再加强监管，死亡可能是突然休克式的（电子烟、比特币）。

① 宏观经济

宏观经济的走势对企业融资成本、现金流压力是直接关联的。对比个人消费者被宏观经济的影响有逐级的传导迟滞，企业一定是更敏感的。

关注的核心模块，包括：出口/内需/投资的战略变化（例：近几年对外资的政策松绑）、货币政策的变化（例：近期的公开市场操作、准备金率变化）、税收政策变化（例：增值税税率变化对业务进销项的影响）、地方政策（包括：人口政策、产业政策）等等。

② 监管趋势

顺势而为，是保障业务能够持续发展的必要前提。滴滴规模近似垄断后迎来的管制压力，我认为本质上是国家对核心民生行业的行政干预预期较高，因为涉及到社会稳定、安全，强管制是有必要性的。

同样，像比特币这类去中心化、发行不由官方控制的所谓“货币”，在当前的监管层面上，肯定也是无法被接受的。以大局为重，是一个取舍的过程，4.025%的年金险下线也是同理。

③ 分析框架

分析框架需要站在行业的角度、客户的角度、需求的角度，评估业务的可行性。

案例：做一款TMS（运输管理系统），解决规模型车队的管车问题。

1. 行业基本情况与发展趋势概述

• 商流驱动的集约，受电商飞速发展的影响，中国集约性比较强的运输领域以快递为代表，CR5已接近70%，也带动了一些成规模的运输车队（下游）。
• 成本压力逐级传导，但由于快递行业过于集中，核心企业货量庞大议价能力强，成本压力逐级传导，中下游的运输公司经营压力大。尤其那些重资产、大规模的车队，其资产管理、资产利用率、成本控制等多个方面都对运营能力提出了极高的要求。
• …..（不赘述，参考咨询报告）

2. 客户概述及上下游分析

• 目标客户画像，拥有>100台卡车以上的运输公司，因为这种量级的客户才有优化管理成本的需求，目前这种规模的运输公司全国大概有10000家（假设）。
• 客户的上下游分析，这些运输公司的上游是通达系、德邦这类大型快递、快运公司，下游有自有购置的车辆，也有社会运力。当前的行业现状是：“运力相比货源大幅过剩，整体议价能力较弱。”除电商外，整体商流的集中度不足、需求个性化，无法形成高度集中的物流市场。
• ……（多维度、信息详尽）

3. 客户在成本、效率上有什么痛点？

• 效率瓶颈：公路运输核心还是在成本、履约质量上，为了保障履约，部分企业购入大量固定资产（车头、车挂）自营运力。与其他实体行业一样，这将面临着业务波动带来的周转效率问题。
• 品质管控：因为快递、快运对于运输的时效要求很高，供应商需要及时了解车辆位置，做好时效控制，降低时效罚款（大概占其总成本的5%（假设））。
• 边际成本：实体资产无法像代码资产那样，边际成本趋向于一个极低值，相反，每一个时间段内，一个货车只能运送一趟货物，这就决定了该场景下技术杠杆不会特别高，运营的效能非常关键。
• 现金流压力：中游运输公司需要承担>2个月的账期（甚至半年），相比快递、骑手这类即付现金流的模式，账期带来的资金压力也限制了业务规模。尤其在利润相对微薄的情况下，即使通过保理融资解决了现金流的问题，其所带来的成本上涨，对实体运输企业也可能是不可承受之重。
• ……（业务经验比逻辑闭环更接近事物的本质）

4. 业务的可行性分析

• 需求验证：管车的需求是真实的，主要是为了减少管理成本、降低迟到罚款。目前竞品已经切入了100家大客户。付费意愿大概在1500元/年，续费率75%。
• 注：上述数据皆为假设。
• 切入路径：目前通达系的供应商（我们的客户）都必须安装一款XX品牌的监控设备，如果想要切入该类客户，本质是需要搞定它的上游，客户不会重复采购两款类似的产品。
• ……（仅做示例，竞争力评估、关联市场影响等不在此赘述）

总结：只有深入了解供应链上下游的关系、供需基本面，才能更好地做销售、产品、运营的决策。

2）业务设计

业务设计的重点是“知己知彼、产品下沉、运营业务”。

① 知己知彼，百战不殆

不同的业务所处的行业周期、竞争情况都很不一样。但最抽象的一层，仍然是以“解决客户需求”为核心。需要通过持续分析竞品、完善服务体系、制定符合业务发展阶段的增长策略，去构建核心竞争力。

1. 产品分析

调研竞品是一个自省、迭代的过程，主要目的是为了评估客户需求集合的满足程度，以及产品切入场景后的角色体验问题。

• 关注客户的核心需求满足程度。B端业务需要满足企业的需求集合，而非单点打透。如果产品功能覆盖度不够，难以构建竞争力。
• 例：一款餐饮Saas，80%的用户不仅需要收银功能，还需要“经营分析、报表管理、营销管理、排号等位”等10项功能。产品A仅能满足其中5项，产品B全部满足，则产品A难以与B竞争（价格相差不大）。

图9：中国典型餐饮Saas竞争力分析

• 产品的操作体验是否能被客户的组织接受，也很重要。如果仅仅只是老板买了单，但客户的组织、各关键岗位无法接受系统的流程/交互，产品切入会受到各种各样的阻力，落地困难。

2. 销售策略分析

在有限的预算与HC的条件下，根据竞品的销售资源、销售策略，去制定ROI更高、长线收益更大的销售策略，是很有必要的。

• 客户：梳理竞品的客户清单，盘点客情关系及服务深度。
• 策略：梳理竞品的拓展策略，盘点其核心优势区域及下一步重点拓展的区域。
• 增长：梳理竞品在拉新、留存上的人力配置、补贴策略，能帮助我们更有针对性地开展差异化的增长策略。
• 例：产品A拉新方面投入了大量的线下力量，且线下销售的核心任务都压在了新增上面。此时，产品A通过“留存激励”的运营策略，即只要商户交易额在次月保持上个月的80%以上，即可获得“高额奖励/折扣”等（通过电销营销），以此减轻线下销售的存量客户维护压力。这笔营销费用需要与所释放销售的获客价值相比较。

② B端产品经理的业务下沉

TO B产品提供的是一套完整的服务，可以分为两个维度来看，

图10：看待服务的两种视角

• 面向客户（外部），业务需要交付“用户视角的产品与服务”，即：“用户会使用什么软件，体验什么样的服务流程，最终支付多少钱。”产品解决方案要满足需求、服务好、价格合理。
• 面向组织（内部），产品解决方案是由基础的职能分工（业务运营、业务产品）与多个项目共同构建的，所有的人力资源、财务预算配置，都需要以“保障面对客户视角的服务、体验不断改善”为核心目标。

1. B端产品经理如何创造价值？

抽象来看，产品经理最核心的能力应该是“解决问题的能力”，进而为用户创造价值。

图11：产品经理的核心能力

《俞军的产品方法论》中提到：

对于用户，大家有不同的理解，通常的理解是用户即自然人。以微信为例，一般的统计报告可能显示其“用户”为11亿，如果把微信的其他功能（支付、公众号、小程序、朋友圈、群等）都删掉，只留下通讯功能，它的用户数可能还是11亿，但它的商业估值可能就从2000亿美元变成了200亿美元。这种将用户定义为自然人的做法，显然在大型互联网产品上并不适用。

从产品经理的视角来看，用户不是自然人，而是需求的集合。

关于需求集合，C端与B端产品是有所区别的。

图12：需求集合的差异

• 做好C端产品，要能够洞察人性本质的需求，要求产品经理除了有较强的逻辑、同理心之外，更要能透过现象看本质。世界上最成功的C端产品，都是人类本质需求的满足者，比如：微信的熟人社交、字节跳动的推荐算法、Pornhub的好人社区、Uber的出行服务。
• 但做B端产品，还需要产品经理有优秀的商业感觉。产品必须是一个业务专家，要能梳理业务的“供需关系、生产管理、组织管理、供应链管理、财务管理”等相关信息。有能力挖掘企业的效率、成本的痛点，并打造满足企业需求集合的产品。
• 例：钉钉，一款老板验高于一切的协同办公产品，一款优秀的老板呼叫器、考勤管理利器。只需要轻轻地夺命DING一下，员工24h在(bei)线(po)办公，老板能不喜欢吗（微笑）？

2. B端产品的货币时间价值

• 现金流A产品，营业收入105万元，总成本100万元（当期支付），此时的利润是多少？5万吗？但如果这105万是应收账款，实际1年后才到账：Ⅰ 假设贴现率5%，未来1年的105万收入在当期仅值100万，所以，考虑货币的时间价值，当期的利润为0。

图13：货币的时间价值

Ⅱ 由于105万的应收是1年后才到账，意味着当期支付的100万需要流动资金支持，此时使用100万自有资金周转业务（假设利率5%），该笔资金当期的机会成本为5万元。
业务的收入现金流是财务模型的关键点，像快递、滴滴这类客户即付，对下游供应商（运输车队、滴滴司机）有账期的业务，资金占用没有压力，有迅速做大规模的条件。但下游供应商如果想做大规模，周转资金反而成为较大的阻碍点。

• NPV计算
  只要当成本投入与收入有时间错配，NPV计算就是非常必要的。

图14：NPV计算公式

例：当期为了拉新用户，产品A共计投入补贴1000万元，获得的用户在第12个月单月合计贡献了1050万的利润，贴现率5%，当期价值Present Value 为1000万元。故可得NPV=0。

图15：各时段现金流的现值计算

总结：做业务决策时，如果不考虑货币的时间价值，往往会导致做投产比分析结论有误，带来无谓的财务亏损。

3. B端产品的用户调研

图16：B端与C端用户调研的差异

B端业务场景往往是非生活化，需求的搜集与分析，没有过往经验的支撑，更需要产品经理深入当前的业务场景中去，了解：

• 客户的决策机制、切换成本
• 实际决策人是核心需求的来源，组织的各角色是产品的实践者，他们的需求都需要了解（以决策人为核心）。
• 例：为餐饮商户提供外卖接单系统，商户决策因素有：加入美团点评后，店铺的流量获取能力会与哪些指标相关，收入抽成比例，提现规则（资金占用），营销工具包（会员、积分、优惠券）等等。
• 对于已经使用竞品的客户，除了考虑产品、成本差异，还要考虑切换成本，尤其那些与客户系统打通竞品（可能两边花了几个月时间才打通）。
• 我们产品的新体验能否超出旧体验+切换成本？如果不能，客户凭什么切给我呢？（答：也许可以通过销售动作补产品不足，为什么会有大保健？）
• 梳理业务流程、组织角色及其KPI梳理流程是业务设计最核心的工作之一，它类似C端的用户体验地图，通过梳理各个节点的“效率、成本”痛点，找到产品的核心价值点，并基于此去创造新的用户价值。
• 梳理各角色及其KPI，更有助于改善服务能力、产品体验。
• 例1：调研客户组织后了解到，采购经理的KPI除了找性价比更高的供应商，还要求供应商的履约品质必须达到公司设定的标准，这决定了业务的资源投入（例如：客服、Local人员的投入）。
• 例2：对于订单录入的操作员，每个人负责的线路相对固定，高峰期每日录入100单，每一单都需要重新选择出发地、目的地，操作成本太高，应该设计常用地址库功能解决这个问题。

4. B端产品的设计概述

• 了解程序设计的MVC范式
• Model指数据模型、View指前端交互图，Controller指业务逻辑。任何一套软件系统运作的本质都是相同的；用户在前端交互层操作后，系统通过业务逻辑层处理数据层的数据。

图18：MVC范式

• 从业务流程到产品架构业务流程梳理是产品设计的重要基础。假设做一个外卖系统，一个商家要开店接单，最简易的流程需要有：注册认证→开店→接单→提现。流程之下就是需求的集合：(1) 注册认证：需要哪些资料、资质？审核标准、时效要求是什么？(2) 商品管理：支持排序管理？支持哪些信息修改？商品图片支持多大规格？配置商品数量的上限是多少？(3) 逆向流程（重要）：逆向流程的完备性决定了销售、客服、技术的无谓成本。完备性不足将可能导致技术分散精力去解决偶发的逆向问题，影响开发进度、质量。3.1 不同订单状态下，客户发起取消的业务逻辑应该有什么不同？3.2 骑手因故无法取餐，商家端是否需要支持发起重新匹配骑手？3.3 客户点的某一样商品无货，商家是否支持部分退货？……

图19：商家入驻外卖平台

• 基于业务流程对应的需求集合，梳理产品架构。(1) 基础功能：包括用户、支付、消息、发票等，可能会接入统一的中台服务，需要基于业务需求逐个梳理功能细节。例：因监管要求，营业执照有效日期单独录入字段，做较强的业务限制（超期不更新无法再接单）。(2) 业务功能：包括订单服务、营销工具包、门店管理、权限管理等。

图20：产品架构图（示例）

Ⅰ订单作为核心服务，其状态设计及各状态下的逆向流程非常重要，决定了商家自助经营的能力。Ⅱ营销工具，核心是赋能商家销售，包括：送券、卖券、满减、秒杀价、广告投放等等。Ⅲ权限控制，主要参考RBAC（Role-Based Access Control）模型。其中最简单的用户、角色、权限模型，包含了2种情况：ⅰ用户和角色是多对一关系，即：一个用户只充当一种角色，一种角色可以有多个用户担当。ⅱ用户和角色是多对多关系，即：一个用户可同时充当多种角色，一种角色可以有多个用户担当。注：权限管理涉及到子角色、继承、互斥、数量约束等逻辑，在此不一一展开。

图21：RBAC模型

总结：当角色的权限边界较为清晰时，可考虑使用多对一的权限设计。若不满足该条件，则最好使用多对多的权限体系（避免大量用户都要独立建设角色，变成一对一的权限管理），保障系统的可扩展性。例：小代既是销售运营，也负责财务对账，那小代就应该同时拥有销售运营与财务对账两个角色的权限。

③ 卓有成效的业务运营

1. 业务的增长解构

• NDR，增长的试金石

图22：ARR示意图

如上图，客户的年度经常性收入（Annual Recurring Revenue）可按用户新增年份划分为不同的颜色，可以清晰看到，一个有好的收入留存（Net Dollar Retention）的企业软件产品，其增长极大程度由老客户来推动，每年新客的获客压力很小。
注：收入留存Net Dollar Retention，指存量客户在新一年产生的所有收入（包括原有模块的续费与增购，新模块的增购）作为分子，这批客户在前一年产生的所有收入作为分母，两者相除。

• 商业模式决定增长策略业务增长由老客户留存收入+新客户收入组成。Ⅰ 留存周期很短的业务，大量成本都会花在了销售费用上，需要持续拉新才能保持增长。例：英语培训、婚庆服务。Ⅱ 留存周期很长的业务，收入可以更多转化到技术、产品迭代中去，提升自己的核心竞争力。例：协同办公、知识管理、云服务。例：Atlassian 的敏捷管理矩阵有“ Trello、JIRA、Confluence”三款产品，其超高的留存率反映了产品的粘性。根据2019年的投资者报告内容，Atlassian为花费5万美元或以上的客户实现了98%的保留率，其中90%的客户购买了3种或3种以上的产品。

图23：Atlassian的留存、购买数据

总结：当商业模式的留存能力较高时，成本投入可以更多倾斜到存量客户的价值满足上，用存量支撑增长的基本面。反之，只能将预算都投入到持续的拉新中去，此时存量客户的体验保障往往成为一个难题，婚纱摄影就是典型的销售大于服务，套路繁多，意图一次榨干的行业。

2. 业务运营的设计概述

业务运营是集增长、服务、数据、研究于一体的运营体系。不仅要对外提供营销策略、客户服务，更需要对内交付决策支持、用户反馈。

图24：业务运营架构图（示例）

对外，业务运营是营销策略、客户服务、培训支持等。要实现业务的增长目标，并为客户提供更好的的业务体验。

对内，业务运营是流程管理、数据分析、行业/用户/政策研究及运营支持，目标是保障业务运作的高效、流畅，保障业务决策的有效性、合理性。

• 如何实现增长？业务增长主要还是围绕营销策略展开的，包括产品定价及搭售方案、销售策略。Ⅰ 定价与搭售(1) 中小客户标准品，要参考竞品的定价模式，实施与业务节奏匹配的的搭售策略、促销策略。对于高续费率的产品，可在拉新上投入更多预算。例：假设Teambition给企业版购买者提供知识积累产品Thought半年10人的高级权限，由于知识积累属于切换成本很高的产品，灰度测试续费率约75%（假设），综合收益依然可观，搭售方案可行。(2) 对于大客户，要有完善的报价机制。包括：客户档案建设、个性化需求搜集、决策人影响（要避免花了很大力气BD，没找对实际决策人）、方案设计与成本评估。

图25：Teambition价格方案

Ⅱ 销售策略要开展全国性的业务，销售资源的配置是核心决策点，关系到整个业务的成本与产出。(1) 盘点：围绕增长目标，设定销售指标的拆解逻辑。盘点存量客户的产出预期，评估增量客户规模，并梳理潜在客户列表及对应的HC需求。(2) 合作：销售与事业部的组织关系，决定了业务在前台推进的效率。如果销售体系闭环在事业部内部，产研、运营与销售的合作，主要围绕KA需求的敏捷支持以及高优先级Feature List的迭代交付，围绕研发资源的配置，需要高频沟通。如果销售属于中台体系，承接各事业部需求，业务需要先确认销售的资源配置方案，包括：绩效考核的逻辑、业务的激励规则等等。围绕销售资源的配置，需要重点沟通。(3) 路径：是先从单一客户突破，还是从重点区域突破？要基于业务实际的竞争情况考虑。如哈罗单车初期就避开了一线城市，在二三线城市站稳了市场，最后切入一线城市。
(4) 模式：直营服务品质更好，为了拿下重点、核心城市，可能会使用直营模式；对于业务量小、基数庞大、单个价值低的中小型城市，可能会使用成本更优、速度更快的加盟模式。

• 构建服务体系C端产品，单个客户的流失对平台损失不大，客服体系可能会侧重构建标准、广覆盖的服务能力，尤其要在成本与收益面前做再平衡（例：印象笔记甚至没有电话客服，客服流程通过邮件处理）。但由于B端产品的客户价值相对更大，需要更完整、深度、个性化的服务，才能提升客户留存水平。为了实现这个目标，至少需要满足三点：Ⅰ 让客户方便地找到我们，搭建覆盖度高的服务窗口。Ⅱ 搭建售前、售中、售后多层次的服务能力。Ⅲ 实现数据闭环，便于高效、全面地评估服务质量。

图26：搭建服务体系的要点

客户服务不单单是一个体系问题，更是一个文化问题。如何看待用户的反馈？是真的闭环处理，还是记录后石沉大海？客服的应急权限有多大？这些问题的背后，体现了业务负责人对用户的真实态度。

3. 面向经营的数据体系

数据体系核心是面向经营提供业务观察、业务诊断的能力，它的结构类似MVC结构，前端是可视化的控件，中间层是数据仓库以及对应的报表结构，底层是业务分析的体系。

图27：业务的数据体系

• 业务分析体系（核心）
• 分析的目的是诊断、监控。业务分析可以大概分为2个模块：什么样的数据表现是健康的？哪些项目需要重点监控？
• 根据2个模块的具体内容，再结合业务构建指标体系：
• Ⅰ 业务健康度指标：判断业务是否健康发展的核心指标集合，任一指标出现问题都预示着业务存在较大的健康风险。一般健康度指标都有明确的目标，便于做业务发展的过程管理。
• Ⅱ 分析型指标：业务分析逻辑链路上的过程指标，以及其他需要重点监控的指标。由于业务不同阶段的侧重点不一样，监控的方向也各不相同。
• 例：业务冲刺阶段，业务负责人希望重点关注客服质量，避免高成本拉来的客户因为客服质量不满意而流失。

图28：业务分析体系框架（示例）

• 数据仓库/报表体系有了业务分析逻辑，就可以开始搭建业务报表了，这是一个从想→做得过程。在MVC的架构中，前端层、业务逻辑层都会有数据上报，形成数据库表/日志。

图29：数据的形成

了解产品数据结构的业务运营，对分析的实现才有更强的判断力，也更能够理解各系统间的交互逻辑。所以，在产品设计初期，业务运营就需要和业务逻辑层（后端）沟通各个服务、系统的数据记录的字段、规范，避免业务所需的关键数据漏存。

图30：业务数据的表结构（示例）

通常，业务分析体系的指标，往往需要关联多张核心表关联计算，例如：用户表、支付表甚至其他业务的表，单一业务方难以实现。为了解决这个问题，大数据部门通过拉取各业务的数据，经过流程调度、数据清洗、数仓建表，最终提供数据服务（例：可视化平台、用户标签查询、报表服务……），为业务方赋能。
在数仓的建设过程中，最好能有懂业务、数据结构的业务运营与大数据工程师共同建设，保障“业务分析逻辑”→“技术实现”的信息传导足够对称。

图31：数仓整体的技术架构（示例）

• 数据可视化数据可视化，实际是将数据信息以更低的阅读成本提供给数据消费者。不同类型的数据适合不同的展示方式。不必过度追求炫酷的效果，时刻关注它的核心价值是“更低成本的阅读”。
• 推荐工具：Tableau

图32：Tableau展示案例（Hanah Anderson、Matt Daniels）

④ 敏捷的项目管理体系

一个业务要持续前行，有两种工作要做：

• 重复性工作，例：日常的数据监控、客服等运营工作。
• 项目型工作，通过完成一个新项目改善产品/运营，从而让业务发展得更好。

图33：业务与项目的关系

互联网行业，业务从0~1的过程中，

• 需求变化很快、要求整个组织足够敏捷、高适应性地去为组织提供服务。
• 团队规模的扩张，没有体系化的项目管理，将出现：“信息不对称、进度把控弱、协同成本高、边界不清晰”等问题。

图34：项目管理的急迫性

1. 敏捷的业务运营

如同产品是迭代出来的，运营要持续优化业务，也必须采取迭代交付的模式，以应对多变的业务需求。

我通过3年的实测与迭代，验证了“建设以Scrum（敏捷）为核心的项目管理体系，确实能有效提升运营团队的自我管理、高效沟通、适应变化的水平”。

下面我会简单介绍下敏捷运营的方法。

2. 什么是Scrum？

Scrum一词来自橄榄球运动中的“并列争球”。在软件开发历史过程中，Scrum 先驱们将 Scrum 这个词的隐喻应用于软件开发。它是一套轻量级的核心价值观、原则和实践，统称为 Scrum 框架，在这个框架中人们可以解决复杂的自适应问题，同时也能高效并有创造性地交付尽可能高价值的产品。

在这个框架下，我们可以检验团队是否符合 Scrum 原意的要求：

1. 团队成员是否有共同目标？

2. 团队成员是否开诚布公地紧密合作？

3. 团队成员是否经常检视和调整？

4. 团队成员是否各自发一颗球（各做各的用户故事等），各自努力往后场冲刺以争取个人绩效？

……

3. Scrum的运营实践

Scrum的运营实践，借鉴了Scrum在产品开发上的应用。

它是一种有计划、持续迭代的运营策略。通过多次交付来应对需求的变化，逐步得到一个完善的解决方案，并影响业务的结果。

(1) Scrum运营有哪些角色？

Business Owner(BO)：业务负责人

• 职能：负责勾勒业务愿景、为业务指明方向、计划节奏、考虑成本等。他一方面要理解用户、利益干系人的需求。另一方面，对正在推进的业务，要和产品、运营、研发团队紧密合作，验收各方交付出来的产品。

Scrum Master(SM)：敏捷教练

• 职能：Scrum Master 既是 Scrum 团队的教练，是团队服务型领导、“保护伞”和“清道夫”。
• Ⅰ 负责指导团队在通用的 Scrum 框架上建立并遵循自己的过程，帮助每个参与者理解并乐于接受 Scrum 的价值观、原则和实践；
• Ⅱ 充当教练、在过程方面发挥教导作用，帮助团队以及组织中的其他人指定合适的高绩效、有组织特色的 Scrum 方法；
• Ⅲ 负责保护团队不收外部干扰和障碍，（在个人无法有效解决遇到的障碍时）发挥领导作用，清楚阻碍团队生产率的障碍；
• Ⅳ 他是领导者，不是管理者。

Operation Team(OT)：运营团队

• 职能：负责确定如何交付业务负责人要求的成果，负责运营的策略设计、数据分析等工作；团队成员整体具备的技能，需要足以实现业务负责人要求交付的业务价值。

(2) 项目管理概述

Ⅰ 业务计划（ Business Planning）

每月的OKR评审会议将产出“业务代办列表、OKR”。

主R：业务负责人（BO）

• 待办业务列表：评估业务工作及优先级。
• OKR：评估一段时间内业务的目标及关键结果。

Ⅱ 冲刺计划（Sprint Planning）

主R：Scrum Master

基于“OKR、业务待办列表”，Scrum Master需带领敏捷运营团队，将“业务待办列表”中的工作拆解为下一个冲刺(Sprint)的“工作包”列表。

• 工作包是一个有明确时间节点的可交付成果。

Ⅲ 冲刺（Sprint）

主R：Scrum Master、运营团队

• 时间盒

以时间盒（例：2个自然周）为单位进行冲刺（Sprint），持续交付工作包。在每个时间盒结束后，重新评估一次“业务待办事项列表”所需交付的工作包是什么，以适应业务的变化。

• 看板

使用“看板”作为“信息发射源”，同步各项目冲刺（Sprint）的工作包状态。

Ⅳ 冲刺回顾（Sprint Retrospective）

主R：运营团队

每个月结束（约2个Sprint），结合OKR做冲刺回顾（复盘）。回顾的目的是：

• 评估目标及达成情况
• 遇到了哪些问题？有什么亮点？
• 总结经验教训、客观规律
• 总结接下来冲刺（Sprint）的改善项
• 团队进行充分的交流、沟通

写到这里已经12000+字了，算是对5年业务运营工作的总结。

其实不管是产品也好，运营也好，最终的目标都是做一个业务负责人，只有持续地去认知行业，打磨自己产品、运营、商业能力，构建自己的轮子而不只是在得到上听别人的轮子，我相信未来才能跑得更从容一点。

作者：一只特立独行的Eric 快手商业化运营