无论什么时代，都不能缺少好的产品经理。本文是2015年 Matt LeMay 在美国新闻学会的产品经理聚会上所做的演讲。演讲者根据多年的经验和观察，总结对产品经理的未来看法。

注：下文中的第一人称是 Matt  LeMay，而非译者。

简要总结：

• 产品经理的未来关键在于拥抱用户的复杂性，理解用户的能力会更加重要。
• 产品经理是一个支持性的角色，而不仅是一个“有远见”的角色
• 硬技能与软技能之间的关系是此消彼长的，而最好的产品经理具备联接能力将组织内不同的价值、角色联接起来。
• 目前对产品经理的描述大多都是狭隘和误导性的，优秀的产品经理还有巨大的开发潜力。

引言

本文关于产品经理的未来，概括了我在过去五年中观察到的四个重大转变。

在介绍这些的转变之前，我想提另一个显著的改变。当我刚工作时，经常听到这个问题：“为什么要聘请产品经理？”。在某些情况下，还会听到CTO和技术出身的创始人公开吹嘘没有产品经理，也能够完成软件。产品经理不过是为了提高组织协同效率、企业经营效益的妥协。

其中，很大一部分是因为他们错误地认为产品经理只是二流开发人员。软件需要开发人员才能完成，而产品经理基本是阻碍开发工作。现在这种想法在一些组织中仍然存在，但明显比以前遇到的次数要少得多。相反地，我经常被问到：“如何招聘产品经理？”

我相信，部分原因是许多备受瞩目的高科技产品公开未能达到他们的预期。而且现在实现目标比五年前更难。随着风险资本对关注收益并真正了解市场的公司越来越感兴趣，随之而来的是从“完成软件”向“完成合适的软件”转变。问题在于如何开发一款合适的软件。招聘开发人员绝非易事，但技术终究比人类更容易理解和量化。随着越来越多的公司承认产品管理的重要性，“什么是好的产品经理以及如何招聘”成为了公司新的焦虑和困惑。

我相信这些问题的答案随着时间的推移会发生变化。

从 Agile 到 agile

我想讨论的第一个转变是从 Agile 到 agile。（译者注：Agile指敏捷开发流程；agile指具有敏捷思维的团队）

这是什么意思？

值得记住的是：Agile是一种价值观，“Agile”是尊重个体的复杂性和变革的必然性。

具有讽刺意味的是，这套价值观被编成了一个高度规范和静态的流程，然后成为一个包含关注具体呈现的流程、工具的生态。

每个流程或工具都有自己的说明文件和规则，但从某种意义上说，这使招聘产品经理变得更加容易。 您选择研发流程，然后聘请该流程的专家就好了，但这种方法有严重的局限性。

这意味着您正在招聘具有固定知识和经验的人，而不是那些适应性强和思维敏捷的人——agile。

敏捷宣言的签名者之一Andy Hunt，在他的博客文章“The Failure of Agile”中谈及此现象：

因为初学者实践 Agile 的唯一有效方法是遵循简单的规则，如“当发生这种情况时，就这样做”。由于Agile 提供一些实践方式帮助初学者入门，新的团队会抓住这些方式，然后停留在这个阶段。

因此，人们没有关注敏捷原则和敏捷宣言的理念，仅仅形成了一系列实践中的“铁”规。Agile 要求从业者思考，明白这是一个很难的东西。简单地遵循规则并按规则去做，这很简单。也可以避免嘲笑或指责，你也不会因此被解雇.……集中精力执行一小部分无用的规则， 每个人都感觉更好， 直到真正上线发布的时候。

我认为：这说明了产品管理正在发生的一个更具挑战性的变化。公司意识到产品管理不是选择正确的研发流程 – 而是在整个组织内实践。

实践是什么意思？

从某种意义上说，产品管理类似于瑜伽或正念，都无法通过阅读规则来掌握它。我看到公司所犯的最常见错误之一是实施新的“敏捷”流程或雇用新产品经理时，只要问题没有立即改善便会宣布其失败。

一些公司在转变研发流程五次才意识到问题是人和协作，而不是工具和流程。更改工具和流程相对容易，但改变人和协作需要时间——需要不断发现问题、反思总结。

在讨论产品管理时，我发现Jon Kabat-Zinn关于冥想练习的描述很有启发性：

 人们想要通过冥想去放松、体验特殊的状态、成为更好的人、减少压力或痛苦、改变旧的习惯、变得自由或开悟。所有正当理由都可以参加冥想练习，但如果你因为冥想时预期这些事情发生的话，这些便成了新的困扰。你会陷入想要获得“特殊体验”或寻找进步迹象的过程中，如果你不能立即感到特别的东西，你可能会开始怀疑你选择的方式或者怀疑是否做对了。

从“数据驱动”到“用户驱动”

我想讨论的第二个变化是从“数据驱动”到“用户驱动”。

也许由于产品管理作为“软技能”（软技能是指：难以衡量的技能）的焦虑普遍存在，市场对“数据驱动”产品经理的需求不断增加。

而且在这个时代，谁不想“数据驱动”？ 在我的职业生涯中，我发现建立权威和评估方案合理性的一种有效方法是用“数据”进行量化评估，花费时间建立仪表盘，再投入时间来管理并分析数据。

但是，产品经理的工作不是要了解分析结果，而是了解用户。通常，“数据驱动”这一术语会产生一种思维模式，这种思维模式将数字置于产生这些数字的人之上。如果我们的目标只是向上和向右推动图表，那么我们将针对这些图表向上和向右进行优化，即使它是以牺牲我们的客户和产品为代价的。

我的朋友 Mike Dewar 是纽约时报的数据科学家，他撰写了一篇关于这件事的精彩文章，他认为推荐引擎不是为了最大化指标，而是为人们设计体验。

“大数据”时代最具破坏性和持久性的神话之一是：通过查看数字和仪表板，我们可以“比他们更了解自己”。

这种心态不仅暴露了对“数据”的基本误解，而且也是对人类本身的根本性误解。我们能够在不倾听他们的情况下理解他们的想法是傲慢的、狭隘的，坦率地说，是可悲的。与真实的人交谈可能会令人困惑、尴尬，甚至是彻头彻尾的沮丧。但是，如果我们真的想要了解用户，我们需要理解并接受人类无法完全预测和量化的问题。

Datascope Analytics的漫画表达一些非常重要的内容。我们有时不愿意承认：没有明确的目的，“数据驱动”的工作通常是忙碌而价值低的工作。有时，这类工作会过度简化用户的需求和行为致使我们远离用户。如果我们不问“为什么” ，如果我们不是在寻找“数据驱动”决策背后的混乱的人为因素，我们便不是产品经理。

从“做什么”转变为“为什么”

我想讨论的第三个转变是从“做什么”转变为“为什么”。

刚工作时，我很高兴能够规划产品路线。我是团队中那个有想法、有远见的人，能够让公司变得更好。简单地说，我将告诉每个人要打造什么。

这个想法与产品经理是“迷你CEO”这一概念密切相关。刚开始时，我真的很喜欢这个想法，这让我感到重要和强大。

为此，当团队成员问我“我应该做什么工作？”时，我很高兴。这让我感觉自己是一个真正的产品策划者，产品路线、指标、未来的引路人。我独自了解公司目标和愿景，我独自设计了能够实现这些目标的方案，然后告诉团队哪些能够执行以及何时执行。

我经常听到类似的想法，坦率地说，这是我犯的一个巨大错误。

大家普遍认为：主要负责执行的开发和其他人员要避免处理业务类事项。这个想法是希望开发人员能够整天戴着耳机敲代码。如果你告诉他们业务目标、用户场景，是在浪费开发时间，而且打断了他们敲代码的状态。

我不仅认为这是错误的，我还认为产品最终会屈服于开发人员。我真的不相信有人想在不知道为什么做的情况下执行，自然也不认为这种心态应该被鼓励。我遇到产品经理隐瞒“为什么”的场景，几乎都是因为他们并不知道真正的原因。

当我刚从业时，我希望有人告诉我：“不要成为英雄”。

自封的“有远见”的产品经理是危险的。产品管理从根本上讲是建立不同角色之间的联系和理解，而不是告诉人们该做什么。它是一个支持性的角色，而不是一个“有远见”的角色。被问到“我们下一步应该做些什么”可能会让我感觉良好，但这通常意味着我实际上并没有做得很好。

当我们的优先事项发生变化时，尤其如此。在对一个项目进行描述，或者从技术角度对项目进行范围界定时，如果不知道为什么要构建，那将非常困难。如果团队不知道为什么要构建，他们就无法做出最能支持项目目标的决策。

最终，我不再努力成为产品“领导者”，而是尽最大努力确保公司的目标清晰透明，并且尽可能多的人能很好地理解这些目标。这让我感觉自己不那么重要了，但它大大改善了我的团队合作的方式。

现在，当我规划优先级时，会问：“公司的目标是否足够清晰，当我不在这里时，产品团队能够同样有效地规划优先级？”

从“硬技能”和“软技能”到“联接技能”

最后，我想谈谈从“硬、软技能”到“联接技能”的转变。

在招聘时，我经常被问到如何平衡“硬技能”和“软技能”。我认为这种区别通常会阻碍公司筛选出最有潜力的产品经理，还会影响产品经理对其工作的信心。

Megan Kierstead 是一位关于产品管理和用户研究的伟大作家，他讲述了这个故事。

我认为：这个故事可能很多经历过糟糕的面试的产品经理深有感触。对我而言，这就是你用“硬技能”和“软技能”来思考时所发生的事情的典型案例。“硬”与“软”之间的语言固有地将一方与另一方对比，也许是最具破坏性的，这表明这是一场零和博弈。

在许多产品管理的文章中，有一种观点认为产品经理需要“足够技术化”。

在某些情况下它发挥了不错的效果，但也有适得其反的情况。在最好的情况，这个想法迫使公司雇用对技术充满好奇和兴趣的产品经理，以有效地决策并提出好的问题（顺便说一句，做这些事的技术门槛是非常低的）。

最糟糕的情况是：这个想法迫使公司雇用最像工程师的候选人，而不是那些将成为最佳产品经理的候选人。

最像工程师的产品经理候选人往往是面试中最受欢迎的人选。

为什么不呢？

他们经常有类似的经历、兴趣和专业知识，开发人员可以跟他们交谈很多。招聘经理害怕聘请“非技术”产品经理，疏远了工程师。不幸的是，这些候选人往往以开发团队的失望而结束，因为最初期望很高。

真正优秀的技术型产品经理们知道如何邀请开发团队参与优先级排序，使得流程既有趣又有效。他们知道如何让开发团队获得足够信息，从而制定支持公司业务目标的技术决策。换句话说，成功与失败之间的区别因素不是“技术是否足够”，而是善于在不同的价值观和专业知识之间建立联系。

那么，为什么产品经理需要足够技术水平的想法如此普遍？

我认为：它是“技术驱动”和“文化契合”理念的呈现。理论上，开发应该在让他们感到高效和能够发挥价值的环境工作。当然，开发也希望能与他们尊重和钦佩的人合作。在实践中，这些观点通常表现为工程师只会“尊重”乐于分享技能的人。有趣的是，通常都是管理团队希望通过这种方式让开发保持愉悦。

“文化契合”是大部分公司很难找到优秀产品经理的重要原因。因为涉及许多混乱的人为因素，产品要承担的角色也总在变化，所以在招聘那些看起来契合团队的人时，都会有一定的安全感。

但我最近听到，人们用“文化添加”来取代“文化契合”的理念。这意味着接受不同的技能和观点，由此扩展组织的知识和能力。我想补充一点，如果你的团队会对新观点充满好奇，而不是害怕，那么这也是团队融合最好的方式。

我认为：这种好奇心是理解优秀的产品经理为组织扩展价值的关键。我希望面试者能够分享他们在各种团队中学到的知识，而不是scrum和XP之间的细微差别。优秀的产品经理可以在看似截然不同的体验、价值观和技能之间建立联系。

总结

当人们问我如何获得工程师、数据科学家和其他专业人才的青睐时，我的回答并不是“学习如何编码”，而是对他们的工作真正感兴趣。我花了好几年才明白这一点，培养真正的好奇心是产品经理工作的重要组成部分。

当组织希望了解哪些人可以成为产品经理时，我经常要求他们绘制组织内信息传播的地图。不是组织结构图，只是人们如何相互沟通的草图。

通常，一些人将成为中心节点、枢纽，这些人通常不符合产品经理的传统形象：他们并不对设计感兴趣的工程师，也不是能够编写代码的设计师。他们经常是销售、运营，他们完全处于“非技术”角色。但几乎每个团队都至少有一个人在不同的观点或部门之间畅通交流。这些是“agile”。而且至关重要的是，这些人已经在困难但关键的联接技能上证明了自己的能力。这些人我认为将会是优秀的产品经理。

原文来源：2015年 Matt LeMay 在美国新闻学会的产品经理聚会上所做的演讲

本文由 @吉诺是比利 翻译发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unspalsh, 基于CC0协议。