如果要高度凝练总结一下本文的观点，如下所示：
我相信产品管理的未来建立在我们对人类复杂性的洞悉上，体现在开发产品的进程中以及借以了解客户的数据里。
我相信产品管理是一项具有决定意义的支持性辅助性角色，而不是某种「远见性」角色。
我相信如果在「硬技能」（专业性知识）与「软技能」（人际交往、组织协调等不容易被评估的能力）之间做出界限清楚的划分，这将给公司的生产力带来极大的阻碍作用。而最优秀的产品经理往往具有一种「连接性」的作用，能够将一个组织中的各个角色，各种立场衔接贯通。
传统产品经理的角色定位，技能档案中范畴拟定的太窄，有些时候还会出现错误的方向。而对于一个真正伟大的产品经理来说，他的角色应该超越于「会设计的工程师」和「会编程的设计师」之上。
如果你对上面的结论感到疑惑、不解、甚至是强烈反对，请继续读下去。
首先要先给大家分享一下在过去的 5 年时间里产品管理所出现的四大转变，这四大转变共同指向的尽头便是产品管理的未来。
产品经理的必要性
在开始描述这四个转变之前，我想要先指出另外的一个转变。当我刚开始以产品经理的身份工作的时候，这个问题经常出现在耳边：「为什么我应该聘请一位产品经理呢？」在一些状况中，我经常听到 CTO 和专注与技术的创始人吹嘘自己的丰功伟绩：在不需要产品经理的前提下就将软件开发出来。产品经理有些时候被视为一种「必要之恶」，一种对公司组织架构和损益表的妥协。
往往这样想法的背后都是认为产品经理无非是「二级程序员」，他们无法担当纯技术的角色。你需要一个程序员来真正把软件开发出来不是吗？产品经理说好听点「锦上添花」，说不好听点就是对「编程」和「配置代码」这些「实质性工作」的阻碍。
就算在如今的很多公司，这样的想法仍然存在，但是我已经很少碰到了。相反，人们经常问的问题是：「我该怎么去找来一位产品经理？」
为什么会出现这样的变化，我想部分原因是因为现在很多高调宣传的高科技产品往往无法达到开发人员的预期。将软件开发出来，我指的是任何一种类型的软件，把这个想法作为终极目标，比 5 年前要难太多。如今的风投们都越来越关心那些专注于提升收入，真正了解市场的公司， 所以难怪会出现从「开发出来软件」到「开发正确的软件出来」的转变。
但问题就恰好出在这里。为了达到这个目标，一个人或者一个团队所需要的技能组合空前的复杂。 招聘一个程序员本身就是一件很困难的事，但是招聘一个能够掌管人力组织以及系统就更难了。前者无非局限在技术层面精研深究，而后者考量的是更加综合的能力 。当越来越多的公司都承认产品管理的重要性，自然而然围绕着这个话题产生了无数的焦虑以及困惑， 比如「到底怎样才能成为一名好的产品经理」以及「如何寻找到他们」。
第一个转变：从 Agile 向 agile 的转变
我相信关于这些问题的答案是随着时间的变化而不断演变的。如今我愿意跟大家分享我所观察到，思考到的一些转变，尤其是在成为「优秀」产品管理者的这个话题上。第一个转变是在开发方式上的，它从首字母大写的「灵活」（Agile）转变为首字母小写的「灵活」（agile）。
这是什么意思呢？从最初的形式上来看，「Agile」这个词因为其首字母大写而具有了一定的宣言成分，它是某种价值观的确立，为了鼓励「灵活开发」，它下面应该有一套价值观做其支撑。从最纯粹的形式上来看，「Agile」意味着尊重每一个个体的复杂度，承认，接受无法避免的变数。
从这样的理念延伸出来一整套方法论，比如越来越细化的开发流程和工具，每一个都有着自身文档以及一系列的规则。 感觉上，这一切似乎都让招聘产品经理不再变成一件难事。你只需要从这个宏大系统中选择其中一个流程，针对这个流程选择想对应的专家，工作就完成了。
但这样的方法论有着非常严重的局限性。很明显，这意味着你所雇佣的这个人必须对某一系列的知识内容有相当程度的掌握，同时还要有一些特定的经验， 招聘的诉求点并没有瞄准到那些精于适应，快速思考的人才身上。而这些人正是如今小写的「agile」所需要的人才。
对于刚开始学习「灵活开发」的人来说，最有效的途径就是去遵循某些简单的，不考虑任何情境的规则了。「只要发生了这样的情况，那就这么做。」自然灵活开发给了人一套方法论之后，很多人很容易就入了门，然后就没有然后了，就卡在原地不动了。
当别人问起你在干嘛的时候，你会说「我在学习灵活开发啊」，然后就钻到了一套没有什么实际用途的规则当中不可自拔，反正你也不会因为学习这个而被解雇掉嘛。直到要把产品真正开发出来的时限将至，然后所有人都慌了。
从 Agile 到 agile，这是产品管理领域所发生的一次重大转变，而且这种转变给每一个人都带来了不小的挑战。 公司正在意识到产品管理并不仅仅是选择正确的流程，它是因地制宜，在自己公司的内部打造出来一套工作办法！
什么是「工作办法」呢？其实产品管理有点儿像做瑜伽或者灵修。你不可能通过读一本指导性规则的书来掌握它。目前通常会出现这样的状况，这也是大多数公司不知不觉中犯下的错误：公司采取了「Agile」的开发办法，又或者是招聘了一位新产品经理，当现状没有大的提升改善的时候，便宣称这些方法统统失败。有很多公司能够在产品管理流程上面转换 5 到 6 次，最后才意识到了根本问题是出在了「人」和「互动」上，而非工具和流程。将工具和流程改变是相对容易的，但是要把「人」和「交互方式」进行扭转则需要一定的时间，其中肯定伴随着抵触对抗。
将产品管理视为一种「工作方法」，我想来自 Kabat-Zinn 的这段话说的尤为精辟。
人们出于想要经历某种特殊情境，想要成为一个更好的人，想要降低自身的压力和痛楚，想要打破旧习惯以及旧的行为模式，想要变得自由以及睿智，往往会采取一种办法：「坐下来沉思冥想」。所有这些非常具有说服力的理由都让人们采取沉思冥想。但往往人们所期待的某种「特殊情境」，或者是意味着事情发生好转的「某些信号」没有出现的时候，你就顿时陷入到了被动的境地，你开始觉得自己选择的路是否出了差错，开始自我怀疑是否行动上错过了某些关键环节？
第二个变化：「以数据驱动」的产品管理向「以客户驱动」的产品管理转变
正因为在产品管理上存在着种种的焦虑，并且还容纳进来了一种名叫「软技能」的东西，人们就自然而然地去寻找数据来帮忙。在我做产品经理的时候，我知道想要让自己的话立刻充满无法辩驳的说服力，那么从「数据」上做量的判断吧。我的屏幕上充满了各种的面板，花了大量的时间去管理和评估各种分析工具的有效性。
但是产品经理的职责并不是去理解「分析工具」，而是要去理解「客户」。往往以数据为驱动的思维模式会让人痴迷于数字，脱离了客户情境本身。
我们生活在这样一个「大数据时代」，很容易陷入到对数字执迷不悟的误区中，我们看着那些数字和表盘，自以为能非常了解客户，甚至比客户自身还要了解他们。这样的想法不仅偏离了数据本身的目的，而且也将人性看得太简单了。只需要靠数据坐在房间里就能洞悉人心，完全没有必要走出门跟客户聊一聊，这样的心态自大无知，狭隘且令人悲哀。当然，跟客户直接交谈肯定会带来某种程度上的不解，尴尬，甚至会泄气，但是如果你真的想要去了解客户， 那么你就不得不放下手中的数据，接受「人的行为是无法预测以及量化的」。
这并不是说数据全无意义， 而是数据分析应该建立在有明确的诉求和目的基础之上的 。如果没有这些内容作为前提，那么「数据驱动」的产品开发只是忙来忙去一场空。
第三个转变：从「是什么」到「为什么」
现在想想，当我作为产品经理的时候，我为能彻底「拥有」一份产品开发路线图而感到幸福，我可是那个做决策的人，组织的「大脑」，某个充满远见和洞察力的人，一个能够走进来改变公司，使之变好的关键性人物啊！简而言之，我是那个告诉每一个人该开发什么的那个人。
这样的想法只要稍微往前挪一步，那么你的身份角色就类似于这个产品开发小组的「迷你 CEO」。当我开始以产品经理的角色工作时，我真的很喜欢这样的想法，它让我感到自己无比重要，充满权力。噢天哪，有时候我看镜子镜子里面竟然会浮现出上面这个男人的样子……
尤其这样的时刻最让我喜欢，我的团队中的某个成员跑过来问我：「我是否应该在这个领域继续开发下去？」这让我觉得我简直成为了产品的灵魂所在，路线图的拟定者以及守护者，产品未来的卫士，只有我能了解公司最深层次的目标和诉求……
不过，那是我生平犯过的最大的错误。曾经人们普遍认为：程序员就是负责执行的，其他的事儿不用管，比如商业层面的决策。程序员可以一整天耳朵里塞着耳机，一动不动的坐在工位上写代码，如果你拉把椅子坐到他们跟前，想要跟他们聊聊商业目标，对用户的理解，你现在做的这些事背后的意义是什么，换句话说你为什么要去做这些工作，一旦你有了这样的尝试，你肯定会招来厌烦的目光，他们觉得你是在浪费他们的时间，并且也让他们那么纯粹的专业技能显得不再纯粹了。
让程序员工程师就专注于手头上的编程工作，这不仅仅是错误的，而且也是对工程师职位的蔑视。我从来不相信一个人能够在不知道原因的前提下能把事情给干好，这样的想法当然不值得鼓励。坦白来说，几乎每一次产品经理或者高层在「为什么」这个问题上遮遮掩掩，其真相就是他们本来就不知道答案！
现在回想起来，如果我在刚开始当产品经理的时候有个人能给我提个醒该多好啊！「不去做超级英雄」，那种自视清高，觉得富有「远见」的产品经理绝对是有毒的。
产品经理的职责从本质上来说就在承接各个板块、部门、角色之间桥梁作用，他要让每个人明白自己工作背后的原因是什么，而不是工作内容是什么，这是一个支持性的角色，而不是一个「远见性」的角色。当被问及「我们接下来该干嘛」的时候，我也许会暂时感觉到舒服暗爽，但是这往往意味着我在产品经理上面的失职。
如果我的团队不清楚他们正在开发的产品背后是基于怎样一种考虑，他们根本不可能拿出适合这个项目的最佳技术决策来的。
最终，我不再尝试去当一名产品「领导人」，相反我正在想方设法的让公司的目标变得更加清楚，透明，这些目标要尽可能让所有人知道，这当然会让我显得无足轻重，但是它却极大地提升了整个团队的工作效率。现在我跟某些公司合作，对项目中各个工作的轻重缓急进行排序的时候，我经常问我自己的一个问题是：「这家公司的目标是否足够清楚，在我不在这家公司的时候，产品团队是否有能力像我在的时候一样，高效地排列出所有事情的前后次序轻重缓急？」
第四个转变：从「硬技能和软技能」向「连接式技能」的转变
最后，我想谈一下从「硬技能和软技能」向「连接式技能」的转变。
在招聘一名产品经理的时候，人们往往在问这样一个问题：如何在「硬技能」和「软技能」之间寻找到平衡点。我认为这种一分为二的方法让公司无法找到真正有价值的产品经理，也让产品经理在工作中无法感到充足的自信。
Megan Kierstead 是在产品管理和用户调研领域非常优秀的专家以及作家，他就说这里面采取的语言，「软」和「硬」之分从潜意识里就让人们觉得这是某种程度上的「零和游戏」，你不是这一头的就是那一头的。
那么招聘一名产品经理时描述的条件应该是什么样的呢？ 往往这里面会有对技术上的强调，比如「足够的技术水平」来树立产品经理的门槛。这会带来两种结果，好的结果是公司能够找到一名对技术充满好奇心的产品经理，他能够有效地将任务分配下去，并且也能提出好的问题。（其实这样的技术门槛即使在目前看来也是非常低的）；如果是最糟糕的结果，公司招来的应聘者只是看起来非常像工程师的一批人，这些人不可能成为优秀的产品经理。
产品经理要和工程师的角色一致，这样的想法在工程师团队中尤其受欢迎，甚至公司人事招聘上也会这么觉得，谁愿意把一个毫无技术背景的人招进来，让他给一群懂技术的人发号施令呢？他们必须有着相同的从业背景，相同的技术兴趣，特长，这样才能有共同语言， 最怕的情况就是工程师团队抱团排挤这名应聘成功的「菜鸟」产品经理了。
但不幸的是，就算是这个人符合了工程师团队的种种期待，这些产品经理还是会让团队失望，其原因跟这些人被招进来的理由恰好完全一样 ！我刚开始以产品经理工作的时候，我总是依照自己的视角，对那些能够证明我技术背景，价值的领域投以更多的注意力，尤其是工程师团队都表示很感兴趣的领域，我当然要着重强调。但是一旦团队开始面对客户，研究开发出怎样的产品才能提升客户体验的时候， 我顿时发现似乎没有什么领域是我的「私有领地」了，我的威信无所凭借，只剩下一点点敏感可怜的自尊。
我所认识的优秀的产品经理， 他们都非常了解如何让工程师团队纳入到「工作任务优先级排序」的环节中。这个过程既有趣，也带来了实质性的成果。他们知道如何授权给工程师团队，使得他们都能够从自己的专业视角出发，拿出对公司整体商业目标最有利的技术决策。换句话说，「成败与否」的关键并不是看他「是否有足够的技术背景」，而是一种能够在不同的技能、价值观之间来回游走，衔接的本领。
为什么对「技术背景」的要求如此普遍呢？貌似「技术背景」貌似就居于「以工程师为中心的文化」和「文化契合度」这两个要素交合的部分中。从理论上来说，高度专业的劳动团体必须跟值得他们尊敬和欣赏的人一起共事才可以。但这样一来，貌似工程师只会「尊敬」拥有相同技术背景的人们。但事实上不是这样子的，这份尊敬会给予管理层，当管理层能让工程师团队工作顺心愉快的时候，而非给予工程师本身这个角色。
「文化契合」是公司为什么这么难找到合适的产品经理的原因。因为这个角色范畴太过模糊，它牵扯到很多跟人们打交道的内容。
现在有很多人把「文化契合」替换了另外一个词，尤其在那些自诩自己为创新型公司中更为常见。这个词就是「增补文化」。这意味着公司愿意去拥抱不同的技能和不同的视角，借此增加公司的知识库和提升能力档次。我想所谓「增补文化」的到来，反而会赢得公司原有工程师队伍的认可，当然这得建立在工程师本身对新的视角，新的方法一直保持着好奇心，而不是畏惧新想法的冲击。
对了，就是「好奇心」，好奇心是理解一名优秀的产品经理的关键，也正是「好奇心」，是产品经理注入到公司中的重要因素。优秀的产品经理应该是将看似分割的经验、技能、价值观等方面有效的衔接整合！
有很多公司都发愁如何从公司内部找出一个合适的「产品经理」，我在给它们提供咨询服务的时候往往要他们拿出一张纸，上面画出来公司内部信息流动的图。这并不是组织机构图，仅仅是人们是如何交流的图。
往往画完这张图，很可能就会出现几个家伙，他们处于信息交流的中心节点，扮演者衔接沟通的角色。 但是往往这些人根本不符合过去传统意义上对产品经理的定义，他们不是那种对设计感兴趣的工程师，更不是会写一些代码的设计师。往往他们是销售员，又或者负责运营一个社群，又或者是负责营销。往往他们根本就是没有任何技术背景的家伙，这些人才是小写的「a」,「灵活开发」的真正代言人，他们在最为重要，且难以证明的沟通技能上面已经充满展现其价值。他们才是未来真正优秀的产品经理人。
文章来源：站长之家.