产品经理为什么失败?

前文说过,我在招聘产品经理。

其实,我是一个研发 Leader,按照我现在管理的团队规模来说,还没到能配置产品经理的程度。但是为什么会有一个产品经理的岗位划归我管?这就是我本文想谈的问题,产品经理为什么失败。

这里要交代一个背景,就是我的部门,下辖多个研发部门,然后有一个产品组,直接汇报给分管副总,还有一个 BI 组,也如此。在这种组织架构下。产品组的工作,就是协调整个部门和外部门的合作,以及部门内部的一些系统的研发工作。其实这里隐藏了很多问题,这里关乎一个研发中心的人事建设问题,我就不展开说了,也没那个能力。

此前产品组,是有一个产品会分管我所在组的工作的,但是先后几任都失败了。很早前有过一位,没起到什么太大的作用,后来空缺了几年,随着业务压力增加,又补员了一位,结果没做多久,宣布失败,被开掉。现在经过协调,这个岗位的管理权暂时落到了我手里,变成我需要招聘一个产品经理,来辅助我组里的工作。

现在招聘快有眉目了,我就在想,产品如果入职了,我应该怎么管理这个产品,要想知道怎么去管理,就要明白,原来的历任人选,为什么失败。这里首先要声明,我所在的研发组,历史不短,也没什么问题,也没有跟产品闹矛盾,最后一任产品被开,甚至丧失了这个岗位的管理权,也都不是我的要求,而是来自客户要求。

总结前面几任产品的失败,我觉得有以下一些原因。

第一点,产品经理把任务当成工作。我所在的公司,把结果和目标当成对公司的驱动力,估计也没有多少公司不是这样的。要达成目标,拿到结果,就不得不做一下必要的工作,这些工作就是我所说的任务。任务是达成目标的路径或者说手段,但是不是目标和结果本身。话说得像绕口令,但往往就是这么回事。

很多事务性的工作人员,其工作组成只有任务,比如在生产线上拧螺丝,贴产品logo标签,就是一个一个贴,这是个任务,但是生产出来东西,卖得掉么?能赚钱么?跟做任务的这些工人,其实没有很高的相关性。只要他做了对应任务,检查合格,工作就结束了。

但是互联网时代的,提供软件服务的企业,产品经理不能这么思考问题,职位里带个经理,也不能将任务视为自己的工作目标。前几任产品的失败,就是其工作还停留在任务层面。总是满足于自己做了什么,动作执行是否到位。例如,是否及时跟需求方了解了需求?是否撰写了需求文档?是否问开发要到了排期?是否给上级写了项目进度报告?

你要说了,产品不就是做这些么?当然没错。可是产品经理不能只做这些!还有什么?我不知道还有什么,我只知道,如果只有这些,项目未必会成功。你东西做出来了,上线了,产品就会成功么?产品经理如果以交付为目标,最多只能算完成了任务。可是搞服务的,工作哪有个尽头呢?上线了,可以说你的项目才刚开始。但是我们这里的产品经理,他觉得自己工作已经结束了。

我面试时候,其实跟其中一个候选人提过这个问题,她很惊讶地反问,这不是产品经理都应该明白的道理么?我有点赧然,在我公司里,就有产品经理不懂这个道理。各位看官可能也觉得,我提出这种东西显得幼稚,但是,大家可以仔细思考一下自己见过的人,能不能做到我说的这些要求。我只能说,我职业生涯中,见过的多数产品,能做到的不多。有些是自己没意识,有些是迫于无奈。那些能在迫于无奈的环境中,依然坚持做一个合格产品经理的人,凤毛麟角。

关于低一点,我想说,不要甩锅给外部环境,老板昏庸之类的,坚持做正确的事情。甚至你要偷偷做正确的事情。

第二点,产品经理写需求偷懒。我说偷懒,是说,这个产品经理写需求不写真正重要的部分,总是写一些不重要的部分。避重就轻。那么什么为重?什么为轻?场景,用例为重,产品方案为轻。

我不知道读者你是产品还是开发,你可以回忆一下你自己看过写过的需求,仔细思考一下,这个需求讲得是怎么做,怎么实现?还是讲为什么做,为什么实现?前者为轻,后者为重。反正我看到的多数产品经理,写的需求都是说,要怎么怎么做,做什么什么。

为什么程序员,工程师,总是戏称自己是码农?或者说自己的工作是搬砖?就是需求上都写了,第一,把什么存储到哪里,第二,点击哪里发生什么,第三,在什么地方看到什么。不知道各位看到这种东西,想到的是什么,工程师,不就是把这种指令翻译成代码,然后测试一下有没有写对么?每天就是在不断服从命令,这样的情况下,工作如果有趣才怪!可是有些老板,就喜欢这样的开发人员,如果一个开发做不出需求上的指令,他就觉得开发无能。

这样的行为会扼杀开发工程师的创造力,以及剥夺开发工程师的判断力。他不知道产品的宏观定位,不知道功能设立的目标,不知道经营者想达成的效果,也不知道用户的反应,无法判断某些取舍的对错,最后做出来的,只能是垃圾。一些情况下,可能是能用的,但是如果说这个东西很好用,可能超出用户的预期,不可能!

可是我看到的需求,多数如此,我以前最痛恨画一大堆 Axure 的产品经理,后来我明白,有错的不是 Axure,而是在不讲清楚重要的目标和原因,不交代场景的情况下,空谈原型功能设计的产品经理,他们错了。如果你做的产品专业性很低,大家耳熟能详,根据常识就能理解,你做一个搬砖产品经理,把开发当搬砖工,你有可能混下去。但是如果不是呢?你的软件非常专业,客户更专业,业务逻辑并不是耳熟能详,也不能根据常识判断,你这样写需求,你的产品会有什么后果?

灾难。

所以我们组原来的产品经理失败了,不可避免。

第三点,产品经理的旁观者心态,或者说自诩智者的心态。这里就不得不提,不合适的组织架构,有时会让团队成员滋生这种心态。我跟几个同事讨论这事情,产品经理如果说话,总是说“你”,“你们”,“他”,“他们”,那么这个产品经理不会有什么大成就。产品经理应该总是说“我”,“我们”,“咱们”才有可能是正确的态度。

失败的产品经理,跟我的客户说话,有一种“我是来帮你们梳理需求的,你们要好好跟我交代,讲不清没关系,我会很耐心的”,面对客户的时候,没有把客户的需求,当成自己的事情,而是当成“你们” 的事情,“我”只是来帮忙的,而且,“我”会尽力的。当你把自己从一个事情里摘出去,当成中立第三方的时候,你的心态是什么?力所能及。你觉得失败跟你有关么?不重要。

失败的产品经理,来跟我们开发说话,有一种“需求方告诉我XXXX,所以你们要XXXX,你们说XXXX,我不管,需求方是这么说的”这种态度。又把自己摘出去了。觉得自己是传话的,或者觉得自己是领导,只是领导产品项目,不是领导人,但是你们得听我的。而且经常就是“你问我,需求方为什么这么要求,我不知道,反正就是对方说的”,尤其是需求方是老板的时候,更加如此,往往就是没理由要求一些功能和特性。

开发做不出来着急啊,不尽责的,破罐子破摔,项目就彻底失败了。尽责的开发只能越过产品,再去跟需求方沟通,最终解决问题。但是如果这样,要产品又有何用的?于是客户开除了产品经理。

我的建议是,要么产品经理以客户的事情为自己的事情,以客户需要为几任,将客户目标失败视为自己的失败。要么,产品经理以开发团队为自己的团队,以项目成功为自己的成功,将开发团队视为自己的人,站在开发的角度深度了解团队和项目需求,不要当成传声筒,要深度了解并规划产品的研发路径和功能组合。

为什么失败的组织架构会有这个后果,就比如我们部门,有好几个研发团队,都有 Leader,产品组是平级的,也有 Leader,看起来每个组都是平等的。产品组的人,天然觉得自己不受研发 Leader 节制,而研发组的成员,也更不会受产品经理领导。研发组的 Leader 更不会听命于产品组一个普通组员。同样,产品组的考核也不受到客户目标失败的影响。这时候,格局一般的普通人,做出什么选择,我只能说无可厚非,但必然是失败的产品经理。

可能还有很多问题,但是我一时能想到的,特别严重的,思维底层的根本逻辑问题,是失败的重要原因。有些格局大,能力好的产品经理,一看我说的,估计嗤之以鼻,说些这么基础的东西,难道有人做不到?如果你深谙人性就知道,多数产品都是我说的这些失败的产品经理。不然,既然人人都是产品经理,为什么世界上多是失败的产品呢?