【重磅系列】跟着老汤一步一步建立产品管理体系-第七篇-如何保证PMS的正常和高效运转(下)

在上篇和中篇中,我们介绍了“体制”对PMS运转的影响,常见的有四种情况以及我用一句话概括一下每种情况:

1)责权利的不清晰:干的多,拿的少,事得做,锅得背。

2)强势部门的影响:RDS和MMS都在想,“以前没有产品管理体系的时候,难道我们就不做产品了?“

3)决策的一言堂:产品经理要有,但最大的产品经理还是大boss!

4)近视的用人制度:经过同行多年的努力,产品经理终于变成了“售前工程师+需求分析师+产品设计师+原型设计师+文档工程师+售后工程师“。

好,接下来,我们就在本篇中讲一讲“组织架构“又会对PMS的运转产生何种影响。

目前PMS常见的组织架构形式主要有两种,因为本篇不是主要探讨如何构建,因此,我只对这两种架构形式做简要说明。

第一种:独立产品经理制

第二种:部门产品经理制

关于这两种产品经理体系架构,大家有一个了解即可,我重点想说一下这两种架构体系在现实中都是如何影响PMS的运转的。

先来看第一种架构,这种架构在国外比较流行,通常这种架构下的产品经理被称为是“individual contributors(独立价值贡献人)“,我查了很多资料,也没有找到这个名词的详细解释,不过这个IC普遍有三个特点,第一,在企业组织内处于某个权威地位;第二,在某一方面或领域有卓越的贡献能力;第三、既不领导人,也不被人领导(当然,这只是一种相对,你总得听大boss的吧)。

总之,大家只要知道IC是非常“牛“的一类人就行了。

据美国2018年度对产品经理的调查统计,受访者中有64%的产品经理在组织内是IC,当然,国内很多的企业总是习惯于有样学样的,因此,有些企业也就把产品经理定成了IC。

但是问题来了,我说了,IC是一批在某个领域或方面有卓越贡献能力的人,而要成为这样的人,除了必要的教育背景外,在这个领域内没有长年的磨练和坚定的方向是几乎没有可能的。

同样是美国2018年的调查统计,受访者中产品经理的年龄分布为:

  • 18-24岁:1%

  • 25-34岁:26%

  • 35-44岁:37%

  • 45-54岁:28%

  • 55-64岁:8%

也就是说,35岁往上的产品经理占到了73%,我们假设一个人22岁本科毕业就开始从事产品管理工作,那么,至少要在这个职位上干十年才能达到美国产品经理的主流年龄段。

这就是为什么我一直说要成为一个合格的产品经理,没有十年的时间是不够的。

再反观国内,什么五年成为资深产品经理,七年成为产品总监,这个除了自己吹着玩,还有啥现实意义吗?

于是乎,很多有样学样的企业在采用了这种体系架构后,开始逐渐发现怎么我公司的这些产品经理的IC们没有表现出该有的样子,别说有什么卓越贡献了,其它业务团队的成员们没造反就算是谢天谢地了。

因此,如果我们假设你基于这种架构构建的PMS体系在设计上是没有问题的,那么,如果这样的体系没有正常和高效的运转起来,那么,去好好评估一下你的产品经理是否达到了IC的要求,这个需要结合企业的现实要求和当前产品经理的现状来做评估,具体方式可以参考本系列的第三篇。

再来看第二种架构体系,这是国内采用最多的架构,这种架构也有一些变种,有时候变的让我们不敢相认,但是万变不离其宗,只要产品经理具备职能和业务的双重职责(产品经理在产品团队中管理业务,在产品部门中接受职能领导),那么,就都是基于这种架构的。

那么,这种架构在现实中,对PMS最明显的影响是什么呢?

从我观察的情况看,就是在“组织中再建组织“。

构建组织的目的是什么?简单说,就是为了更好的管理个体,让有着不同能力的个体在自身能力的范围内产出最大化,当然,相对等的收益也是符合产出价值的,其实就是我们都知道的:能者多劳,多劳多得。

但是,现实的情况是,很多企业并没有真正实现“因人而异”的完全岗位适配,尤其是当PMS被引入到企业组织中的时候,必然对现有的业务体系造成种种影响,甚至是冲击,那么,一旦面对这种情况,企业通常的着眼点就是:在不影响现有组织利益的前提下,通过在组织中再建组织来把PMS对企业造成的影响降到最低。

出发点没有问题,因为没有一家企业愿意承担组织改造所带来的风险,但是,这就出现了一个悖论,任何组织改造都有风险,但又不愿意去面对风险。

因此,组织中再建组织就成为一种首选,而这种方法的最大优势就在于“用人力去降低各种风险”。

我曾经服务过一家企业,在职能上,产品部隶属于研发中心,归CTO管理,但是,在具体的业务上,我们又隶属于XX事业部,事业部有个总经理,但是呢,他又不管理我们,因此,我们在开展的工作的时候,经常会出现一个情况,就是一件事要向三个领导汇报,产品总监,CTO和事业部总经理,但是,等你要决策的时候,得到的回到经常就是:

产品总监:我已经和CTO说了,等等。

CTO:这件事我不清楚,我去问问事业部总经理。

事业部总经理:这是你们研发中心的事,CTO决定就行。

总之,很多事情就是“议而不决”。

为什么会出现这样的情况呢?

其实原因也很简单,知道整体情况的做不了决策,能做了决策不知道整体情况,越往高级别走,知道的信息越是支离破碎的,那么,大家为了避免给自己带来不利影响和风险,那就“等、推、拖”呗。

那么,问题出现在哪里呢?

后来我分析,就是出现在按照当时公司的实际情况看,其实完全没有必要按照事业部的形式构建,我们知道,事业部本身就是一个具备了各种业务职能的准企业组织,但我们这个事业部恰恰是个“肢体不健全”的事业部,所有市场职能的部门都有,但就是管理产品和开发产品的部门没有,而事业部的总经理和CTO又在公司内是平级,没有任何隶属关系,因此,就让我们这些产品经理在工作上经常是左汇报,右请示,时不时的还得请产品总监出马才能把一件事协调下来。

业务风险看起来是降低了,但效率呢?

这还不是最头疼的,最头疼的是当这一级的领导们都无法协调的时候,就得把事务提交到产品委员会,这就更麻烦了,要想把CXO集团的各位老大凑起做个决策,等吧。

其实像当时我们这公司的情况,体系构架完全可以很简单的,根本没必要搞什么事业部(当时确实正在流行事业部的组织形式),产品、研发、营销三大体系的框架搭起来,然后体系中各业务部门形成固定或灵活的产品组,每个产品组由产品经理领导,业务上直接向产品委员会汇报,向产品总监报备即可。

当然,我这家公司之所以这样做,其中还有一个深层次的原因,就是各个总监了,事业部总经理了都是空降过来的,过来了你不能给人家一个小职位吧,于是各种总经理,总监遍地跑,高峰时候一个400多人的公司,竟然有二十几个总监。

在我这些年的个人的工作经历以及给企业做PMS构建咨询的过程中,我发现这是一种比较典型的情况,但这已经远远超出我能控制的范畴了,因此,就不多说了,如果你负责PMS在企业内的构建,我有两点体会和各位分享一下,:

1、不要理想化的去设计、构建和运转你的PMS;

2、不要期望你能构建出一个理想化的PMS。

好,我们来总结一下,组织架构对PMS运转带来的影响。

如果你想构建第一种体系架构,那么,最重要的环节是在“人”的选择上,一个牛逼的产品经理IC是非常重要的,那么,什么样的产品经理才适合做IC呢?

我个人的想法是:如果这个产品经理是一个行走的公司,那就没问题了!呵呵!

如果你想构建第二种体系架构,那么,最重要的环节是在“组织”的设计上,这种组织的设计不但包括产品部内部的设计,更要包括整个企业组织的设计,在这种体系架构下,产品经理个体的能力反而居于次要位置,因为组织的能力会弥补个体能力的不足,并把个体置于最能发挥出现有能力的位置上。

当然,前提是你构建的PMS是适合于企业实际情况的。

总之,两种体系架构,一个偏重于“个体的力量”,一个偏重于“组织的力量”,但这并不是绝对的,在本系列开篇,我就提到了,PMS的体系能否运转好,无非就是“人”和“平台”的结合度和质量如何。

做个类比,这就像打《刺激战场》,单人模式和组队模式,尽管你还是你,游戏策略却是有偏重的,但目的都是为了吃鸡。

好,关于本篇主题中涉及到的“体系架构”的影响就说到这里,这个系列到这里,也基本上可以告一段落了,在下一篇中,我就对这个系列中涉及到的关键知识点做一个总结,方便大家参考学习。



分享到QQ 分享到微信 分享到微博

0 条评论

发表我的观点

取消

  • 昵称 *
  • 邮箱 *
  • 网址