中台产品经理方法论( 七 )


3. 组织架构层面(1)高层的支持
看过一篇文章《重新理解中台—中台的战略和困境》对中台在组织架构层面的需求做了比较好的介绍,其中最关键的就是,中台是自顶向下向下的,中台一定需要得到高层的支持 。
和绝大多数商业化的事业部一样,我所在事业部的KPI一直是可量化的营收数据,而中台项目在启动运转的相当长一段时间内,我们所做的很难对KPI有直接帮助,甚至于在局部较短时间内是阻碍当年KPI达成的 。
大部分员工是很难站在一定的高度去做看十年做一年的规划,特别是当一件事和眼前的KPI难以达成平衡时,中台的工作会受到各个方面的挑战 。因此高层的坚定支持是中台战略的第一必要条件 。
中台的价值是有条件的,搭建完成后还得有机会来享受成果,这个判断也需要高层来完成 。此外高层还需要推动一些规范的建设,如交互规范、视觉规范、视觉配套的前端组件规范等,在这些规范的约束下,中台服务搭建的难度会大大降低 。
(2)各业务产品的支持
高层的支持是基础,但在中台和业务产品实际工作中无数次的碰撞都需要靠中台自己的影响力来推进工作,因此中台如何在各业务中获得影响力,并推动各业务接入服务也是至关重要的 。
那么如何推动业务产品接入中台服务呢?
直接利益就是人力成本节省 。针对单个业务而言,他最关心的就是接入中台服务能够为其节省的成本,这个计算方式在后面的「中台价值量化」部分会介绍 。
理念的灌输 。除了高层的直接支持外,中台的各负责人会时不时的在各种场合跟业务的负责人和小伙伴「洗脑」,鼓吹共享服务的思想 。
首先拉动的一定是研发人员,好的研发人员是有代码洁癖的,即使他不得不在某些情况下写出恶心的代码 。如果跟他们去聊抽象、架构和重用,天然就会产生亲切感 。
面对业务产品经理就往往需要做交换了,我可以在中台功能设计里支持你的一个偏定制需求,但你得答应要接入我的另一个服务,我甚至于可以出人力帮你接入 。
形成生态系统 。当iOS和android已经成为世界上最大的两个移动端操作系统后,无论开发者多么希望按照Windows Phone的标准做开发,他也只能选择iOS或android,这就是生态系统的力量 。
同理,当中台统一了各个业务的一些基础服务后,在上层的业务功能无论有多么个性化的需求,都不能跳出基础服务的限制 。而对于一个业务而言,放弃中台的底层服务自己重新搭建一套也几乎是不可执行的,太不划算了,无论该产品经理的主观意见多么强烈,在ROI的压力下也很难获得支持 。
当然,每个产品最初都需要一批种子用户来实现冷启动,中台服务最初也需要能有种子客户来打磨产品,那么应该找谁来合作呢?
大家习惯性会想去找战略型的重点业务产品,做成标杆客户 。但实际上重点业务产品往往人力充足,并且跑得飞快 。一个还不太完善的中台服务想要直接跟此类产品合作是非常难的 。他不在意成本,对质量不那么在意,更在意的是速度,这就是和中台本身的定位是有矛盾的 。
因此,中台服务反而应该去找潜力型的业务产品进行合作 。此类业务有着表现自己赢得关注的欲望,但又苦于资源不足很多事情都做不了,是非常有意愿去借助中台的力量做事情的 。
当然,中台支持此类业务产品需要承担的风险就是,这个业务产品可能活不了多久就被老板砍掉了 。因此如何选择具备潜力的产品就是需要中台负责人在战略上能有敏锐判断的地方了 。
(3)重要不紧急的事情始终在推进

推荐阅读