「产品管理」目前出现的四大变化：论「PM」的终
第三个转变从「是什么」到「为什么」
现在想想，当我作为产品经理的时候，我为能彻底「拥有」一份产品开发路线图而感到幸福，我可是那个做决策的人，组织的「大脑」，某个充满远见和洞察力的人，一个能够走进来改变公司，使之变好的关键性人物啊！简而言之，我是那个告诉每一个人该开发什么的那个人。
这样的想法只要稍微往前挪一步，那么你的身份角色就类似于这个产品开发小组的「迷你 CEO」。当我开始以产品经理的角色工作时，我真的很喜欢这样的想法，它让我感到自己无比重要，充满权力。噢天哪，有时候我看镜子镜子里面竟然会浮现出上面这个男人的样子……
尤其这样的时刻最让我喜欢，我的团队中的某个成员跑过来问我「我是否应该在这个领域继续开发下去？」这让我觉得我简直成为了产品的灵魂所在，路线图的拟定者以及守护者，产品未来的卫士，只有我能了解公司最深层次的目标和诉求……
不过，那是我生平犯过的最大的错误。曾经人们普遍认为程序员就是负责执行的，其他的事儿不用管，比如商业层面的决策。程序员可以一整天耳朵里塞着耳机，一动不动的坐在工位上写代码，如果你拉把椅子坐到他们跟前，想要跟他们聊聊商业目标，对用户的理解，你现在做的这些事背后的意义是什么，换句话说你为什么要去做这些工作，一 旦你有了这样的尝试，你肯定会招来厌烦的目光，他们觉得你是在浪费他们的时间，并且也让他们那么纯粹的专业技能显得不再纯粹了。
让程序员工程师就专注于手头上的编程工作，这不仅仅是错误的，而且也是对工程师职位的蔑视。我从来不相信一个人能够在不知道原因的前提下能把事情给干好，这样的想法不值得鼓励。坦白来说，几乎每一次产品经理或者高层在「为什么」这个问题上遮遮掩掩，其真相就是他们本来就不知道答案！
现在回想起来，如果我在刚开始当产品经理的时候有个人能给我提个醒该多好啊！「不去做超级英雄」，那种自视清高，觉得富有「远见」的产品经理绝对是有毒的。
产品经理的职责从本质上来说就在承接各个板块、部门、角色之间桥梁作用，他要让每个人明白自己工作背后的原因是什么，而不是工作内容是什么，这是一个支持性的角色，而不是一个「远见性」的角色。当被问及「我们接下来该干嘛」的时候，我也许会暂时感觉到束缚，这往往意味着我在产品经理上面的失职。
如果我的团队不清楚他们正在开发的产品背后是基于怎样一种考虑，他们根本不可能拿出适合这个项目的最佳技术决策来的。
最终，我不再尝试去当一名产品「领导人」，相反我正在想方设法的让公司的目标变得更加清楚，透明，这些目标要尽可能让所有人知道，这会让我显得无足轻重，它却极大地提升了整个团队的工作效率。现在我跟某些公司合作，对项目中各个工作的轻重缓急进行排序的时候，我经常问我自己的一个问题是「这家公司的目标是否足够清楚，在我不在这家公司的时候，产品团队是否有能力像我在的时候一样，高效地排列出所有事情的前后次序轻重缓急？」
第四个转变从「硬技能和软技能」向「连接式技能」的转变
，我想谈一下从「硬技能和软技能」向「连接式技能」的转变。
在招聘一名产品经理的时候，人们往往在问这样一个问题如何在「硬技能」和「软技能」之间寻找到平衡点。我认为这种一分为二的方法让公司无法找到真正有价值的产品经理，也让产品经理在工作中无法感到充足的自信。
Megan Kierstead 是在产品管理和用户调研领域非常优秀的专家以及作家，他就说这里面采取的语言，「软」和「硬」之分从潜意识里就让人们觉得这是某种程度上的「零和游戏」，你不是这一头的就是那一头的。
那么招聘一名产品经理时描述的条件应该是什么样的呢？ 往往这里面会有对技术上的强调，比如「足够的技术水平」来树立产品经理的门槛。这会带来两种结果，好的结果是公司能够找到一名对技术充满好奇心的产品经理，他能够有效地将任务分配下去，并且也能提出好的问题。（其实这样的技术门槛即使在目前看来也是非常低的）；如果是最糟糕的结果，公司招来的应聘者只是看起来非常像工程师的一批人，这些人不可能成为优秀的产品经理。
产品经理要和工程师的角色一致，这样的想法在工程师团队中尤其受欢迎，甚至公司人事招聘上也会这么觉得，谁愿意把一个毫无技术背景的人招进来，让他给一群懂技术的人发号施令呢？他们必须有着相同的从业背景，相同的技术兴趣，特长，这样才能有共同语言， 最怕的情况就是工程师团队抱团排挤这名应聘成功的「菜鸟」产品经理了。
但不幸的是，就算是这个人符合了工程师团队的种种期待，这些产品经理还是会让团队失望，其原因跟这些人被招进来的理由恰好完全一样 ！我刚开始以产品经理工作的时候，我总是依照自己的视角，对那些能够证明我技术背景，价值的领域投以更多的注意力，尤其是工程师团队都表示很感兴趣的领域，我要着重强调。一旦团队开始面对客户，研究开发出怎样的产品才能提升客户体验的时候， 我顿时发现似乎没有什么领域是我的「私有领地」了，我的威信无所凭借，只剩下一点点敏感可怜的自尊。
我所认识的优秀的产品经理， 他们都非常了解如何让工程师团队纳入到「工作任务优先级排序」的环节中。这个过程既有趣，也带来了实质性的成果。他们知道如何授权给工程师团队，使得他们都能够从自己的专业视角出发，拿出对公司整体商业目标最有利的技术决策。换句话说，「成败与否」的关键并不是看他「是否有足够的技术背景」，而是一种能够在不同的技能、价值观之间来回游走，衔接的本领。