本文作者孙哲从事产品及运营工作十余年。曾任豆瓣产品总监,负责社区的整体产品和运营业务。2018 年初转型投身产业互联网浪潮,加入贝壳找房,现担任贝壳二手房产品线的产品及运营负责人,专注于贝壳二手房业务的产品和运营工作。
文章是他在产业互联网工作几年后的经验总结。全文分为三部分,分别是产业互联网是什么、产品经理在其中做什么、运营在其中做什么。
如果你身处产业互联网领域,或是想投身于产业互联网,相信本文会对你有所启发。
以下是正文部分,enjoy:
产业互联网在百度百科的定义是:「产业互联网是基于互联网技术和生态,对各个垂直产业的产业链和内部的价值链进行重塑和改造,从而形成的互联网生态和形态。」
这个定义其实是将 O2O 的概念做了升级。产业互联网的的描述相对更形象一些。
产业互联网是什么
不扯概念,我先尝试从互联网发展路径描述下特性:
# 第一阶段
最早的 web 1.0 由网站经营者提供信息服务,用户通过网站设计的路径获取信息,信息流动效率变高;
# 第二阶段
到了 web 2.0,用户参与到信息建设的环节中,用户生产,平台组织,用户再消费。
除了信息流动效率进一步变高之外,人群的连接效率也通过网络提升了。并且,在信息和关系之外,用户线下需求和对应服务线上化生态,也在网络上逐步产生。
比较典型的是电商,早期淘宝也就是有人买有人卖。这一阶段还是比较典型的消费互联网。
# 第三阶段
随着用户需求越来越复杂,对服务提供方的要求也变得越来越高。个体作坊式的服务交付能力不足以满足用户对于需求解决所期待的确定性要求,于是供给端的服务需要被改造,通过技术手段重新组织,提升服务效率和质量。
还是以淘宝为例,早期支付宝、四通一达都是它的供给端组成部分。
# 第四阶段
随着 O2O 大潮,各种传统线下行业开始触网,用户可以在线上触达到非常丰富的服务类型。同时每个行业的生产流程、角色关系、服务交付等,都有其行业特性。
于是如何将垂直行业供给端的各种元素做整合和连接,利用互联网技术经验去构建一个完整的产业生态,就是所谓的产业互联网区别于消费互联网所要做的事。比如盒马整合供应链、卖场,配送,还有消费者,形成了完整的生鲜消费生态管理。
上面四个演进阶段看似作为服务接收者的 C 扮演的角色没有太大变化,但实质 C 和 B 的交互以及服务交付关系都在很大程度被改造了。比如从货到付款到线上支付,从到店用餐到吃外卖等等。
# SaaS 公司和产业互联网公司有什么不一样
- SaaS 的收入模式是销售技术服务获取收益,简单的说就是软件销售和培训。
- SaaS 公司提供的服务,相对狭隘的说,其主要价值在于将一部分线下 Excel 管理的信息线上化并且关联起来,然后基于这些数据的线上化提供各类效率工具。
- 但 SaaS 公司并不为所服务公司的经营结果负责。
比较典型的 SaaS 公司有国内的金蝶、神策、纷享销客,国外的有 Salesforce、SAP。
- 产业互联网则是基于已有的行业特性,利用互联网技术整合产业资源,促进流程提效,管理协作分工等。
- 目标是提升经营规模和运营效率,是单体公司围绕所处产业搭建从需求端到服务端的完整线上生态。比如国内早期淘宝、携程,到现在便利蜂,瓜子,美菜等。
- 产业互联网公司往往需要针对目标群体搭建各种 SaaS ,但无论从业务模式还是经营目标来说,都不等于 SaaS 公司。
# 产业互联网和消费互联网的差异
MVP 成本:向市场投放一个 MVP,实现成本从低到高,最低的可能是新媒体选题,发篇文章测试一下。最高的应该是 3A 游戏,需要经历几年开发,极高完成度才可以面向大众发行。
消费互联网可能经过一到两周的迭代就做出个 MVP 去测试市场,而产业互联网可能在设计之初就得考虑从 C 到 B 的流程整合和服务交付管理,一次 MVP 的设计并投放市场的成本就很高。
用户群体:用户的概念被放大了。除去常规的使用 C 端产品的用户外,还有一堆不同分工的 B 端用户群。B 端用户的诉求非常刚性,他们依赖体系谋生,用户群体组成成员在一定时间周期内是非常确定的,对于体系运转的稳定性要求很高。
这里的稳定性不仅包含产品和系统,还有 C 和 B 的业务交互模式。一个新的业务机会出现必然需要对 C、B 两端做新的模式设计,也就是会打破稳定性,而人都是有路径依赖,意味着各种用户角色行为习惯的改变过程会很艰难。
比如,出租车司机在叫车软件出现前是满街绕等碰巧出现在路边的乘客招手,现在更多的是等待系统派单,这个行为可能直至今天也没有完全转换过来。
业务驱动力:当称之为产业的时候,势必有很庞大的潜在需求侧和复杂的长链条供给侧。那在业务开展过程中就需要考虑两端的切入角度和资源投入规模,也就是资源在需求侧和供给侧如何分配才能更高效促进业务正循环。
角度的选择并不是恒定的,跟产业特性和发展阶段有关。比如社区团购砸钱做补贴是个比较典型的需求侧撬动的做法,而快递行业在仓库里塞一堆机器人分拣包裹就是从供给侧提效。
# 先产业还是先互联网
首先一定是产业在前,将互联网作为基础生产工具,加入到传统线下行业里。不同的行业,甚至同一行业中的不同公司,都有比较成熟稳固的运转特性。
不能假设「互联网改变一切」这种浪漫的想象,会在短时间内应用到有着几十、几百甚至上千年积累的行业中。
所谓隔行如隔山,写代码的不一定种得好地,做设计的不一定卖得好化妆品,但都可以送外卖和开滴滴(不是)。
然而互联网的引入,意味着在给一个发展多年的行业注入一个巨大的新变量。这个新变量经过了几十年的发展,影响力已经足够大,和旧世界的任何东西发生关联都可能引发质变。
新变量引入,为行业带来变化,是所谓产业互联网的意义。
对于从业者来说,理解行业,适应产业,找切入点逐步地改进和优化,需要很深的业务洞察和长时间的耐心。
# 互联网对产业的增量变化是怎么发生的
一个产业的生产要素包含人、资源、流程等,按照某种既有的业务模型组合并持续运转。
没有 100% 完美的业务模型,每一个新要素的进入,都会对既有模型产生冲击。这样就可以持续探索老模型中的某个环节是否可替换或者重新设计,且有可能带来潜在的新增量。
我自己比较常用的一种思考模式是问若干个问题:
- A 这个东西一直是这样,那么能不能是 B?
- 如果把 A 重新设计成 B,需要改变什么?
- 被改变的要素,影响了之前 A 里的什么?
- 让 B 模式运转起来,需要怎么设计路径?
举一些栗子:
- 打车是需要走到路边等空车招手,滴滴省掉了这个步骤,让用户坐家里打车;
- 便利店的微操经营比较依赖店长,便利蜂将补货、调价等进行「大数据化」,且让店员按指令行动促使其「工具人化」;
- 学校办了几千年都是面授,在线教育让老师和学生可以不用凑在一个教室里面对面。这些都是旧环节被替换或重新设计的典型案例。
不断探索新要素介入的可能性,才能为已有的产业带来新变化。道阻且长。
产业互联网的产品在做什么
在讲产业互联网产品做什么之前,我们先理一理互联网产品是如何做增长的。
# 如何做增长
产品设计过程中一个常用的概念是「目标用户」,即你的产品所服务的是有什么需求的用户群。然后基于目标用户群的需求去设计产品。
在互联网初始阶段基本是信息服务,现在服务的种类相对更丰富。比如社交、个人表达、亦或是交易,金融等等。
这里引申出的第二个概念是「用例」。过去产品经理或者 UX 在工作产出中,经常会包含用例的描述,不过最近几年我见得比较少了。
「用例」是用以描述目标用户如何使用产品设计者所提供的服务,以满足需求。当为目标用户群的需求提供了足够丰富的产品,以满足其各种用例时,还不代表你会持续地增长。因为很有可能你的目标用户群并不知道你提供了这些服务,以及满足各种用例的产品服务并不被目标用户所接受。
驱动规模增长仍然需要做大量的工作,反复吸引并教育用户,用于建立用户长久的认知心智和使用黏性。
今天我们看到的各种产品增长方法论,无论是「道层面」还是「术层面」,实际运用过程中都是在「用户」和「用例」的基础上来搭建各自的增长引擎。
# 提供更丰富的产品服务
上面我们讲到,随着互联网的发展,业务复杂度会越来越高,业务流程中角色和角色之间的交互关系也越来越复杂。如何为目标用户提供更丰富的产品服务来满足各种使用场景中的用例,并且持续提升服务的效率和体验,是产业互联网非常重要的工作内容。
产业互联网的语境下,产品经理在搭建面向目标用户的产品服务能力时,需要建立复杂的服务交付系统和线上协作网络,C 端的需求解决获取流程越简单,往往意味着 B 端的供给能力越强大。
下面我们围绕着供给端的产品做拆解,分成若干的阶段去阐述产品的演进过程:
第一阶段:信息线上化
基础的 IT 化过程,也就是数据信息标准化的过程,这个过程对于 B 端和 C 端都差不多。在传统的供需两端,完成整个服务过程的的信息都需要被记录和查找,无论对于哪个角色。过去在纯线下时代可能都是通过纸笔完成的。
这个阶段,其实是将各类信息线上化,也就是把一个个信息数据库,从线下搬到了线上用以增删改查,完成检索、记录,归档等。比如相对简陋的商品库存管理就是在这个阶段完成。
不过互联网发展到今天,不太可能起步时就只做这部分,往往是第一、二阶段同时进行。
第二阶段:流程线上化
当各类信息开始在线上存储后,需要搭建处理信息流转和角色协作的系统。
比如商品库存管理,如果只是信息库,可用性仅仅是增删改查,而信息使用过程管理实际还是在线下由人为管理发生的。
各行各业虽然产业属性差异很大,但终归是供给端和需求端的管理,基础流程差异性没有特别大。
用比较简单的切分方式,无非是几大块:客户获取,客户管理,货源管理,财务管理等。通过系统流程串联,能够帮助线下的业务体系在线上做好日常工作管理。这阶段的重心基本都在流程、数据和权限上。
市面上比较典型的第三方 SaaS 公司做的主要产品就是替各行各业提供相对通用的解决方案。比如纷享销客做 CRM,金蝶做财务管理 SaaS 等,更细分的例如神策提供数据管理 SaaS,企微和钉钉也可以很粗浅的分类为内部协作 SaaS。
第三阶段:节点线上化
基础流程的管理,对于灵活度比较高的中小公司的业务发展一般也足够了,中小公司的人治管理边界覆盖率足够高,做好线下的科层管理结合线上的流程管理,已经可以起到很好的效果。
但是对于大型公司,人员规模大,业务复杂度高,基础流程线上化不足以解决体系内各角色个体步调不一致,带来效率损耗的问题。于是就需要依据产业特性做针对性的流程节点细化。比较直白的说就是将业务差异化流程做更细致、更定制化的编排改造以满足需求。
一般第三方 SaaS 公司也提供定制化服务,也就是大客户部做的事儿,得加钱。或者就是提供私有化部署和二次开发的空间,供使用公司自己的产研团队做加工。
比如 Apple 虽然用 Salesforce 作为自己的销售管理系统,但仍然有个很大的团队在做基于 Salesforce 的应用层开发。
这里再展开拆解一下这一阶段的产品意义。基于业务的定制化,本质上是使用方依照自己业务特性和诉求搭建的一套编排系统,创建了各式各样的线上业务流,对基础流程的变动触发做了更细定义的同时,让使用系统角色的输入和输出都经过编排系统,实现差异化的管理。
第四阶段:过程线上化
前三个阶段仍然是在基于产业的线下管理流程特性做的线上化系统支持,但还是有很多的服务过程是完全发生在线上的,同时伴随着智能手机出现而诞生的移动互联网,让越来越多线下流程的发生过程能够采集到完整数据。
比如外卖订单可以通过手机 GPS 管理完整的送餐过程,还有滴滴通过车内的摄像头和录音设备知道一个打车订单的完整过程,系统成为了上 帝的眼和耳。
这一步实现时,意味着不仅仅是服务的结果交付,而是业务体系中的角色在使用系统时的整个服务执行过程都可以被知晓。这时候就可以制定更细致的服务标准,个体差异化至少在线上系统层面可以完全被抹平。
通过系统的约束服务底线被提高,优秀个体的工作模式会被采集和采纳,形成新的标准,进一步提高服务交付的底线。比如滴滴司机在乘客上车时一定会有一句标准礼貌问候语,在没有完整的过程管理时是不可能实现的。
第五阶段:调度智能化
过程线上化管理意味着有大量的数据被收集,AI 发展到今天,已经能从海量数据和对应反馈中学习出阶段性最优解。业务流程的执行标准,依据不同的诉求,已经可以由人为经验定义转为算法定义。
这个阶段业务管理的主导权被切换,从原有的人使用系统,转变为了系统调度人,并且能够不断地做精细化管理迭代。当然,调度的目标仍然是系统设计者人为输入的,诉求是什么,系统就执行是什么。
不过也会有副作用,比如追求效率最大化到极致时,就可能会出现困在系统里的外卖小哥。
在产业互联网的产品工作中,并不是所有的产品设计都是顺序推进的,不同的业务模块所处的阶段也会依据基础设施的完善程度,处于不同阶段。
同时,我也不认为调度智能化是终局形态,一个没有感情没有温度的机器,很难让消费者感受到服务的真诚。
人作为业务体系的参与者,仍然起到很大作用。在作业效率和服务体验提升的演进过程中,个体的主观能动性仍然发挥着非常大的作用。
产业互联网的运营在做什么
在聊这个话题之前,我们需要先厘清一下产品经理和产品运营在职责上的差异。
市面上各种描述都有,但似乎没有权威的定义。我用二分法拆一下:
在业务目标一致的前提下,差异是面向的对象不同。产品经理面向线上系统,产品运营面向角色发动。当然还有 RD 面向系统实现,UE 面向用户体验等。
一人全栈的车库创业时代后,产品、运营、设计这些专职岗位依次分化出来,而不同岗位所负责工作的重心也在逐步变迁。
最初 web 1.0 时,互联网产品提供的是信息服务,运营的面向对象是消费信息的用户,工作重心基本都是在信息的整理和编辑上。
比较典型的是在 Google 没出现前, Yahoo! 信息分类检索体系都是由人工搭建出来的。这些工作的执行落地都比较基础和重复,早期的互联网运营从业人员有很大比例是纸媒编辑背景应该也跟这个特性有关系。
到了 Web2.0 时代,用户开始参与到信息的生产和传播。运营的重心转到用户运营,开始真正意义上的调动角色和发动角色。通过各种手段引导用户参与到线上服务的建设中,在提升用户活跃度,扩大信息消费用户规模的同时,也带动了平台服务能力的增强。用户参与规模越大,参与程度越高,产品的影响力也就越大。
到了产业互联网时代,在同一个产品体系提供的服务流程中,可能出现若干的角色类型,运营的工作就不仅仅是针对单一角色,还需要进一步影响多种角色的线上协作关系。
平台所提供的服务包含交付内容和交付形式,都需要通过运营去影响和推动各个角色来达成。完整的服务交付不是静态的货,客户真正接受的是结合参与角色交付方式的货。
# 运营工作的原点
用比较简单的话语描述,产品运营做的工作是在回答:谁?和谁?做什么?怎么做好?的问题。
主体是「谁」。只是放在产业互联网的语境下,需求侧的角色诉求细分,供给端的链条长且复杂,并且和消费互联网面向 C 端用户的运营从兴趣入手不同,产业互联网中被运营角色的驱动力,无论是 C 端还是 B 端,基本就都是基于现实利益。
运营的原点都是模式设计。先回答希望谁和谁做什么的问题,并能将其描绘出画面来,然后再去推动理想画面能够在业务实际运转过程中发生。这类问题的的触发,要么是用户需求,要么是产业体系中的某个要素的变化。
比如因为移动互联网的出现,滴滴让用户可以不用站在街边拦车了,外卖可以让用户坐在家里吃到餐厅里的饭菜。
模式设计完后,不代表就会自然发生。将业务模式分解成若干个切片,再做整合,运营的工作就是去推动模式切片中的各个角色,制定不同的策略并落地让理想画面发生。
# 机制策略设计
因为要推动的是人,促进或改造的是协作关系和工作流。意味着需要建立机制,让实际运转过程稳定可持续,长久不变形。
不同的机制设计可以选择不同的切入点,当面向角色,从人出发时,也就是寻找合适的切入场景。场景可以是业务发展多年后已经存在的沉淀事实,也可以是基于需要被创造出来的新事物。
场景中可能是单个角色参与,多数时候都是多个角色。当涉及到多个角色,角色和角色之间的关系就需要分析处理,正负向的关系往往是伴生的,有合作的时候一定有竞争,有上对下管理的时候一定有下对上博弈。分析清楚角色直接的利害关系,才能找促使角色行动的驱动方式。
前面也提到产业互联网中被运营角色驱动力大多是基于现实利益了,但实际运营过程中不可能干什么都给人发钱,太过于单一,这时候发明一些转换变形的东西来替代钱就显得尤为重要,也能降本提效,这也就是行业黑话说的「造抓手」。比如积分,兑换券等等。不同公司因为业务属性和场景角色不一样,设计出的抓手往往也不一样,但归根溯源,对应的本位其实都是人民币。
# C 端用户是数字,B 端用户是活人
To C 的运营,因为用户来了走,群体组成非常不稳定,对于运营来说只能关注用户群的共性,也就是一个个被统计总结出来用以描摹用户特征的数字。就像俞军说用户不是人,用户是需求的合集。
To B 的运营面向的对象是相对固定的一个群体,并且行为模式是有被管理规定约束过的,在稳定模式下的差异表现,会让个体显得更具体更生动。作为运营,日常工作过程中有很多机会是和你的运营对象在直接接触,会产生许多不可量化的感性认知。
B 端的角色群体稳定,不像 C 端一样取最大公约数,而是需要尽可能让所有人形成共识,保持行为的一致性。那意味着需要反复动用各种手段去影响所运营角色。比如搞培训,做演讲,都成了运营需要掌握的必备技能。这和面对电脑,通过屏幕去理解和触达用户的方式,还是很不一样的。
# 延迟满足的反馈
前文也谈到产业复杂度造成 MVP 投放市场的成本很高,业务模式运营产生的效果反馈周期也会非常长。产业的链条长,变化传导效应慢,往往量变的持续积累才能产生一点点质变。如果像消费互联网一样指望快速反馈,很多时候是不现实的。在实际工作中,需要笃定的信念和缜密地推演,才能支撑自己持续投入。
多数时候,需要利用既有的经验或者所谓的「行规」来作为业务持续推进的指导原则。我把这个过程叫做注入「公理」作为启动前提。「公理」是指很多产业经过几十年发展,反复试错沉淀了很多经验,逐渐形成的认知共识。
很多产业发展几十年,反复试错沉淀了很多经验,逐渐形成的认知会成为行业公理,科技发展和行业环境的变化并不会很快改变某些本质,到今天这些公理依然会帮助指明业务迭代前进的方向。
当然还是有颠覆的机会,让产业内出现全新的模式用于替代旧模式。发现旧世界的问题,重新设计替换,让所有的参与角色相信并认同,并最终获得不错的反馈。但其实说不好是模式设计得好起到效果,还是正收益由于群体盲从而被放大。也就是到底是先有鸡还是先有蛋,说不清楚。
但无论如何规则被重新制定之后有了迭代和优化的空间,而你作为新规则的制定者,已经获得了养鸡场的控制权。
运营发动各个参与角色,推动一次次的创新诞生,为产业内某个切片环节带来了改变,并形成了持续运转的新业务模式,持续长久的影响用户日常生活的方方面面。
—— 欢迎在线投稿 ——
特别提示:关注本专栏,别错过行业干货!
PS:本司承接 小红书推广/抖音推广/百度系推广/知乎/微博等平台推广:关键词排名,笔记种草,数据优化等;
咨询微信:139 1053 2512 (同电话)
首席增长官CGO荐读:
更多精彩,关注:增长黑客(GrowthHK.cn)
增长黑客(Growth Hacker)是依靠技术和数据来达成各种营销目标的新型团队角色。从单线思维者时常忽略的角度和高度,梳理整合产品发展的因素,实现低成本甚至零成本带来的有效增长…
本文经授权发布,不代表增长黑客立场,如若转载,请注明出处:https://www.growthhk.cn/cgo/coo/38051.html