产品经理为什么失败？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

灾难。

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

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

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

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

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

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

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

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