本文是基于我过去的从业经验，观察、以及犯下的许多错误中总结而来的。
如果要高度凝练总结一下本文的观点，如下所示：
我相信产品管理的未来建立在我们对人类复杂性的洞悉上，体现在开发产品的进程中以及借以了解客户的数据里。
我相信产品管理是一项具有决定意义的支持性辅助性角色，而不是某种「远见性」角色。
我相信如果在「硬技能」（专业性知识）与「软技能」（人际交往、组织协调等不容易被评估的能力）之间做出界限清楚的划分，这将给公司的生产力带来极大的阻碍作用。而最优秀的产品经理往往具有一种「连接性」的作用，能够将一个组织中的各个角色，各种立场衔接贯通。
传统产品经理的角色定位，技能档案中范畴拟定的太窄，有些时候还会出现错误的方向。而对于一个真正伟大的产品经理来说，他的角色应该超越于「会设计的工程师」和「会编程的设计师」之上。
如果你对上面的结论感到疑惑、不解、甚至是强烈反对，请继续读下去。
首先要先给大家分享一下在过去的 5 年时间里产品管理所出现的四大转变，这四大转变共同指向的尽头便是产品管理的未来。
产品经理的必要性
在开始描述这四个转变之前，我想要先指出另外的一个转变。当我刚开始以产品经理的身份工作的时候，这个问题经常出现在耳边：「为什么我应该聘请一位产品经理呢？」在一些状况中，我经常听到 CTO 和专注与技术的创始人吹嘘自己的丰功伟绩：在不需要产品经理的前提下就将软件开发出来。产品经理有些时候被视为一种「必要之恶」，一种对公司组织架构和损益表的妥协。
往往这样想法的背后都是认为产品经理无非是「二级程序员」，他们无法担当纯技术的角色。你需要一个程序员来真正把软件开发出来不是吗？产品经理说好听点「锦上添花」，说不好听点就是对「编程」和「配置代码」这些「实质性工作」的阻碍。
就算在如今的很多公司，这样的想法仍然存在，但是我已经很少碰到了。相反，人们经常问的问题是：「我该怎么去找来一位产品经理？」
为什么会出现这样的变化，我想部分原因是因为现在很多高调宣传的高科技产品往往无法达到开发人员的预期。将软件开发出来，我指的是任何一种类型的软件，把这个想法作为终极目标，比 5 年前要难太多。如今的风投们都越来越关心那些专注于提升收入，真正了解市场的公司， 所以难怪会出现从「开发出来软件」到「开发正确的软件出来」的转变。
但问题就恰好出在这里。为了达到这个目标，一个人或者一个团队所需要的技能组合空前的复杂。 招聘一个程序员本身就是一件很困难的事，但是招聘一个能够掌管人力组织以及系统就更难了。前者无非局限在技术层面精研深究，而后者考量的是更加综合的能力 。当越来越多的公司都承认产品管理的重要性，自然而然围绕着这个话题产生了无数的焦虑以及困惑， 比如「到底怎样才能成为一名好的产品经理」以及「如何寻找到他们」。
第一个转变：从 Agile 向 agile 的转变
我相信关于这些问题的答案是随着时间的变化而不断演变的。如今我愿意跟大家分享我所观察到，思考到的一些转变，尤其是在成为「优秀」产品管理者的这个话题上。第一个转变是在开发方式上的，它从首字母大写的「灵活」（Agile）转变为首字母小写的「灵活」（agile）。
这是什么意思呢？从最初的形式上来看，「Agile」这个词因为其首字母大写而具有了一定的宣言成分，它是某种价值观的确立，为了鼓励「灵活开发」，它下面应该有一套价值观做其支撑。从最纯粹的形式上来看，「Agile」意味着尊重每一个个体的复杂度，承认，接受无法避免的变数。
从这样的理念延伸出来一整套方法论，比如越来越细化的开发流程和工具，每一个都有着自身文档以及一系列的规则。 感觉上，这一切似乎都让招聘产品经理不再变成一件难事。你只需要从这个宏大系统中选择其中一个流程，针对这个流程选择想对应的专家，工作就完成了。
但这样的方法论有着非常严重的局限性。很明显，这意味着你所雇佣的这个人必须对某一系列的知识内容有相当程度的掌握，同时还要有一些特定的经验， 招聘的诉求点并没有瞄准到那些精于适应，快速思考的人才身上。而这些人正是如今小写的「agile」所需要的人才。
对于刚开始学习「灵活开发」的人来说，最有效的途径就是去遵循某些简单的，不考虑任何情境的规则了。「只要发生了这样的情况，那就这么做。」自然灵活开发给了人一套方法论之后，很多人很容易就入了门，然后就没有然后了，就卡在原地不动了。
当别人问起你在干嘛的时候，你会说「我在学习灵活开发啊」，然后就钻到了一套没有什么实际用途的规则当中不可自拔，反正你也不会因为学习这个而被解雇掉嘛。直到要把产品真正开发出来的时限将至，然后所有人都慌了。
从 Agile 到 agile，这是产品管理领域所发生的一次重大转变，而且这种转变给每一个人都带来了不小的挑战。 公司正在意识到产品管理并不仅仅是选择正确的流程，它是因地制宜，在自己公司的内部打造出来一套工作办法！
什么是「工作办法」呢？其实产品管理有点儿像做瑜伽或者灵修。你不可能通过读一本指导性规则的书来掌握它。目前通常会出现这样的状况，这也是大多数公司不知不觉中犯下的错误：公司采取了「Agile」的开发办法，又或者是招聘了一位新产品经理，当现状没有大的提升改善的时候，便宣称这些方法统统失败。有很多公司能够在产品管理流程上面转换 5 到 6 次，最后才意识到了根本问题是出在了「人」和「互动」上，而非工具和流程。将工具和流程改变是相对容易的，但是要把「人」和「交互方式」进行扭转则需要一定的时间，其中肯定伴随着抵触对抗。
将产品管理视为一种「工作方法」，我想来自 Kabat-Zinn 的这段话说的尤为精辟。
人们出于想要经历某种特殊情境，想要成为一个更好的人，想要降低自身的压力和痛楚，想要打破旧习惯以及旧的行为模式，想要变得自由以及睿智，往往会采取一种办法：「坐下来沉思冥想」。所有这些非常具有说服力的理由都让人们采取沉思冥想。但往往人们所期待的某种「特殊情境」，或者是意味着事情发生好转的「某些信号」没有出现的时候，你就顿时陷入到了被动的境地，你开始觉得自己选择的路是否出了差错，开始自我怀疑是否行动上错过了某些关键环节？
第二个变化：「以数据驱动」的产品管理向「以客户驱动」的产品管理转变
正因为在产品管理上存在着种种的焦虑，并且还容纳进来了一种名叫「软技能」的东西，人们就自然而然地去寻找数据来帮忙。在我做产品经理的时候，我知道想要让自己的话立刻充满无法辩驳的说服力，那么从「数据」上做量的判断吧。我的屏幕上充满了各种的面板，花了大量的时间去管理和评估各种分析工具的有效性。
但是产品经理的职责并不是去理解「分析工具」，而是要去理解「客户」。往往以数据为驱动的思维模式会让人痴迷于数字，脱离了客户情境本身。
我们生活在这样一个「大数据时代」，很容易陷入到对数字执迷不悟的误区中，我们看着那些数字和表盘，自以为能非常了解客户，甚至比客户自身还要了解他们。这样的想法不仅偏离了数据本身的目的，而且也将人性看得太简单了。只需要靠数据坐在房间里就能洞悉人心，完全没有必要走出门跟客户聊一聊，这样的心态自大无知，狭隘且令人悲哀。当然，跟客户直接交谈肯定会带来某种程度上的不解，尴尬，甚至会泄气，但是如果你真的想要去了解客户， 那么你就不得不放下手中的数据，接受「人的行为是无法预测以及量化的」。
这并不是说数据全无意义， 而是数据分析应该建立在有明确的诉求和目的基础之上的 。如果没有这些内容作为前提，那么「数据驱动」的产品开发只是忙来忙去一场空。
接下来，我们将谈到其余的两个转变。
