「产品管理」目前出现的四大变化：论「PM」的终极奥义（下）

2015-12-10 14:50:14 | 来源：玩转帮会 | 投稿：佚名 | 编辑：小柯

原标题：「产品管理」目前出现的四大变化：论「PM」的终极奥义（下）

第三个转变：从「是什么」到「为什么」

现在想想，当我作为产品经理的时候，我为能彻底「拥有」一份产品开发路线图而感到幸福，我可是那个做决策的人，组织的「大脑」，某个充满远见和洞察力的人，一个能够走进来改变公司，使之变好的关键性人物啊！简而言之，我是那个告诉每一个人该开发什么的那个人。

这样的想法只要稍微往前挪一步，那么你的身份角色就类似于这个产品开发小组的「迷你 CEO」。当我开始以产品经理的角色工作时，我真的很喜欢这样的想法，它让我感到自己无比重要，充满权力。噢天哪，有时候我看镜子镜子里面竟然会浮现出上面这个男人的样子……

尤其这样的时刻最让我喜欢，我的团队中的某个成员跑过来问我：「我是否应该在这个领域继续开发下去？」这让我觉得我简直成为了产品的灵魂所在，路线图的拟定者以及守护者，产品未来的卫士，只有我能了解公司最深层次的目标和诉求……

不过，那是我生平犯过的最大的错误。曾经人们普遍认为：程序员就是负责执行的，其他的事儿不用管，比如商业层面的决策。程序员可以一整天耳朵里塞着耳机，一动不动的坐在工位上写代码，如果你拉把椅子坐到他们跟前，想要跟他们聊聊商业目标，对用户的理解，你现在做的这些事背后的意义是什么，换句话说你为什么要去做这些工作，一旦你有了这样的尝试，你肯定会招来厌烦的目光，他们觉得你是在浪费他们的时间，并且也让他们那么纯粹的专业技能显得不再纯粹了。

让程序员工程师就专注于手头上的编程工作，这不仅仅是错误的，而且也是对工程师职位的蔑视。我从来不相信一个人能够在不知道原因的前提下能把事情给干好，这样的想法当然不值得鼓励。坦白来说，几乎每一次产品经理或者高层在「为什么」这个问题上遮遮掩掩，其真相就是他们本来就不知道答案！

现在回想起来，如果我在刚开始当产品经理的时候有个人能给我提个醒该多好啊！「不去做超级英雄」，那种自视清高，觉得富有「远见」的产品经理绝对是有毒的。

产品经理的职责从本质上来说就在承接各个板块、部门、角色之间桥梁作用，他要让每个人明白自己工作背后的原因是什么，而不是工作内容是什么，这是一个支持性的角色，而不是一个「远见性」的角色。当被问及「我们接下来该干嘛」的时候，我也许会暂时感觉到束缚，但是这往往意味着我在产品经理上面的失职。

如果我的团队不清楚他们正在开发的产品背后是基于怎样一种考虑，他们根本不可能拿出适合这个项目的最佳技术决策来的。

最终，我不再尝试去当一名产品「领导人」，相反我正在想方设法的让公司的目标变得更加清楚，透明，这些目标要尽可能让所有人知道，这当然会让我显得无足轻重，但是它却极大地提升了整个团队的工作效率。现在我跟某些公司合作，对项目中各个工作的轻重缓急进行排序的时候，我经常问我自己的一个问题是：「这家公司的目标是否足够清楚，在我不在这家公司的时候，产品团队是否有能力像我在的时候一样，高效地排列出所有事情的前后次序轻重缓急？」

第四个转变：从「硬技能和软技能」向「连接式技能」的转变

最后，我想谈一下从「硬技能和软技能」向「连接式技能」的转变。

在招聘一名产品经理的时候，人们往往在问这样一个问题：如何在「硬技能」和「软技能」之间寻找到平衡点。我认为这种一分为二的方法让公司无法找到真正有价值的产品经理，也让产品经理在工作中无法感到充足的自信。

Megan Kierstead 是在产品管理和用户调研领域非常优秀的专家以及作家，他就说这里面采取的语言，「软」和「硬」之分从潜意识里就让人们觉得这是某种程度上的「零和游戏」，你不是这一头的就是那一头的。

那么招聘一名产品经理时描述的条件应该是什么样的呢？往往这里面会有对技术上的强调，比如「足够的技术水平」来树立产品经理的门槛。这会带来两种结果，好的结果是公司能够找到一名对技术充满好奇心的产品经理，他能够有效地将任务分配下去，并且也能提出好的问题。（其实这样的技术门槛即使在目前看来也是非常低的）；如果是最糟糕的结果，公司招来的应聘者只是看起来非常像工程师的一批人，这些人不可能成为优秀的产品经理。

产品经理要和工程师的角色一致，这样的想法在工程师团队中尤其受欢迎，甚至公司人事招聘上也会这么觉得，谁愿意把一个毫无技术背景的人招进来，让他给一群懂技术的人发号施令呢？他们必须有着相同的从业背景，相同的技术兴趣，特长，这样才能有共同语言，最怕的情况就是工程师团队抱团排挤这名应聘成功的「菜鸟」产品经理了。

但不幸的是，就算是这个人符合了工程师团队的种种期待，这些产品经理还是会让团队失望，其原因跟这些人被招进来的理由恰好完全一样！我刚开始以产品经理工作的时候，我总是依照自己的视角，对那些能够证明我技术背景，价值的领域投以更多的注意力，尤其是工程师团队都表示很感兴趣的领域，我当然要着重强调。但是一旦团队开始面对客户，研究开发出怎样的产品才能提升客户体验的时候，我顿时发现似乎没有什么领域是我的「私有领地」了，我的威信无所凭借，只剩下一点点敏感可怜的自尊。

我所认识的优秀的产品经理，他们都非常了解如何让工程师团队纳入到「工作任务优先级排序」的环节中。这个过程既有趣，也带来了实质性的成果。他们知道如何授权给工程师团队，使得他们都能够从自己的专业视角出发，拿出对公司整体商业目标最有利的技术决策。换句话说，「成败与否」的关键并不是看他「是否有足够的技术背景」，而是一种能够在不同的技能、价值观之间来回游走，衔接的本领。

为什么对「技术背景」的要求如此普遍呢？貌似「技术背景」貌似就居于「以工程师为中心的文化」和「文化契合度」这两个要素交合的部分中。从理论上来说，高度专业的劳动团体必须跟值得他们尊敬和欣赏的人一起共事才可以。但这样一来，貌似工程师只会「尊敬」拥有相同技术背景的人们。但事实上不是这样子的，这份尊敬会给予管理层，当管理层能让工程师团队工作顺心愉快的时候，而非给予工程师本身这个角色。

「文化契合」是公司为什么这么难找到合适的产品经理的原因。因为这个角色范畴太过模糊，它牵扯到很多跟人们打交道的内容。

现在有很多人把「文化契合」替换了另外一个词，尤其在那些自诩自己为创新型公司中更为常见。这个词就是「增补文化」。这意味着公司愿意去拥抱不同的技能和不痛的视角，借此增加公司的知识库和提升能力档次。我想所谓「增补文化」的到来，反而会赢得公司原有工程师队伍的认可，当然这得建立在工程师本身对新的视角，新的方法一直保持着好奇心，而不是畏惧新想法的冲击。

对了，就是「好奇心」，好奇心是理解一名优秀的产品经理的关键，也正是「好奇心」，是产品经理注入到公司中的重要因素。优秀的产品经理应该是将看似分割的经验、技能、价值观等方面有效的衔接整合！

有很多公司都发愁如何从公司内部找出一个合适的「产品经理」，我在给它们提供咨询服务的时候往往要他们拿出一张纸，上面画出来公司内部信息流动的图。这并不是组织机构图，仅仅是人们是如何交流的图。

往往画完这张图，很可能就会出现几个家伙，他们处于信息交流的中心节点，扮演者衔接沟通的角色。但是往往这些人根本不符合过去传统意义上对产品经理的定义，他们不是那种对设计感兴趣的工程师，更不是会写一些代码的设计师。往往他们是销售员，又或者负责运营一个社群，又或者是负责营销。往往他们根本就是没有任何技术背景的家伙，这些人才是小写的「a」,「灵活开发」的真正代言人，他们在最为重要，且难以证明的沟通技能上面已经充满展现其价值。他们才是未来真正优秀的产品经理人。

相关阅读：「产品管理」目前出现的四大变化：论「PM」的终极奥义（上）

本文来源：Medium 译文创见首发由 TECH2IPO / 创见花满楼编译

tags：

相关：

产品经理如何解决与协同部门之间的冲突

今天被问及了一个问题：产品经理如何解决与协同部门（研发、运营、市场）之间的冲突？上述的问题是个老生常

产品经理的“发现”与“发明”

如题目所说，我们要谈的是产品经理的发现与发明。发现与发明的不同发现，是指已经存在的事物，去发现它，是

数据是你的生命线，请待她如待初恋

Ben Porterfield 在自己的 Linkedin 主页这样形容自己：一个有经验的冲浪者。除了在 Santa Cruz 海岸冲浪以

当苹果大姨妈来临时，如何有效规避苹果喜怒无常的下架惩罚？

最近频繁有CP跟文公子反馈应用审核的时间延长，部分App遭遇苹果突然下架的惩罚。不但存在上述几类问题，12月