作者：Tina Ruan

全文共 4316 字，阅读需要 10 分钟

———— / BEGIN / ————

因为我在哈佛商学院教一门关于产品管理的课程，经常有人问我 ：“PM的角色到底是什么？”

PM常常被称为“产品的CEO”。我不同意这个说法，因为正如Martin Eriksson指出的：

PM不是产品的CEO，在不同因素下，他们的角色千差万别。所以，如果你在考虑PM的角色，你应该考虑哪些方面？

有志向的PM，在衡量角色时，应该考虑三个主要因素：核心竞争力，情商（EQ）和人与公司契合度。

我合作过的，最优秀的PM拥有核心竞争力，高EQ和适合他们的公司。除了定期开发新功能和保持研发与设计小组和睦关系外，最优秀的PM创造的产品，能被用户高度接纳，从而带来收入的指数级增长，甚至颠覆一个行业。

一、核心竞争力

PM必须有的核心技能 —— 许多技能可通过理论学习获得，但大多数技能会随着经验、好榜样和指导而提升。

下面是一些例子：

• 消费者采访和用户测试

• 运行设计冲刺

• 功能优先级和计划road map

• 资源分配的艺术（不是科学）

• 进行市场评估

• 把商业需求转译成技术需求，然后再反过来

• 定价和收入模型

• 定义和跟进成功标准

这些核心技能是所有PM的能力底线，最好的PM通过多年定义、传输、迭代产品，磨练了这些技能。这些PM善于反思，哪些技能造成了产品的成功或失败，并不断地通过用户反馈调整他们的方法。

二、情商

一个好的PM知道采访用户时，该做的与不该做的，但是最好的PM有能力与用户共情，懂得他们的身体语言和情绪，并立刻弄清楚产品或功能可以解决的痛点。

一个有高EQ的PM，与ta的组织关系亲密，并且有敏锐的直觉，知道如何克服内外部的困难，推出优质产品。

下面看一下Daniel Goleman定义的EQ的四条特质，是如何影响PM的。

1. 关系处理

关系处理可能是PM能力中最重要的一项。

优秀的PM，通过与内、外相关人员建立互信关系，来激励他们，帮助他们发挥最大潜能。

在成功谈判，解决冲突和达成共同目标的过程中，关系处理都至关重要——尤其在达成共同目标的程中，PM要平衡客户需求，资源受限的工程师队伍和公司目标收入，使得关系处理非常具有挑战性。

组织中真实信任的关系，在项目需要额外资金支持时，或工程师需要在下一次迭代中快速修复bug时，非常有帮助。

组织外，这些能力可以让顾客参与beta测试，获得早期反馈，或在未公开阶段，说服目标客户试用MVP（最小可行产品）。这些关系技巧，也会让因为bug而愤怒的客户变成 “没关系，我知道你们会修复bug的” 的天使客户。

2. 自我感知

PM必须通过自我感知来保持客观，避免把自己的偏好投射到用户身上。

如果一个PM因为一个功能可以解决自己的痛点，而喜欢这个功能——这类PM通常是他们负责的产品的重度用户——PM可能会让用户说出他们喜欢这个功能，仅为了取悦PM（“假正向功能验证”）。

如果没有自我感知，当用户访问和证据都反对某功能时，PM仍会将此功能优先排序。缺乏自我感知会打乱其他优先功能，破坏PM与工程师的关系，因为功能不被用户接受，而让工程师丧失对PM的信心。

3. 社会意识

如Goleman所说，职业能力加社会意识就是同理心，是组织意识和服务意识。

PM必须像懂得销售关心如何销售产品，又或是技术支持如何支持产品，又或是开发团队如何开发产品一样，懂得用户对产品的情感和关心。

PM必须有对组织运转有深刻了解，并且必须建立社会资本让产品成功，从获得预算与人手到确保高级工程师努力开发产品。

最后，社会意识确保最好的PM服务于用户，建立解决用户问题的产品，最终确保产品与市场契合。

三、人与公司契合度

如果最好的PM拥有良好的核心竞争力，高EQ，是否意味着他们在哪里工作都注定成功呢？

并不尽然。

事实上，怀揣着这些技能和人格特质，并把它们应用在对的公司才会最终确保成功。

我还未见到过一个真正标准化的PM职责描述，因为这个角色是由公司的大小、产品类型、平台、行业，甚至是企业文化决定的。如果你拥有了核心竞争力和高EQ，需要获得成功，下一步就是就是搞清楚谁在雇用你，他们真正需要什么。

这里有些关键区，根据各家公司对PM的要求而不同：

1. 技术要求

产品类型，使用对象，和公司类型决定了PM是否需要懂技术。例如，Google要求PM必须通过技术测试，不管他们负责什么产品。如果公司在做SaaS CRM，就会要求有关于市场和用户生命周期的经验要求。

反过来，如果一个数据科学产品，包括机器学习算法和APIs，要求PM有深厚的技术，不只能理解如何搭建产品，还能在与使用客户谈话的时候有信服力。

也就是说：了解基本技术原理并掌握PM常用工具，对PM至关重要，无论在那个公司。

Colin Lernell 关于必懂的技术有更多要讨论的。如果你是个有抱负的PM，并且担心缺乏基本技术知识，也许你可以考虑参加在线课程，如哈佛大学出的有名的《计算机科学入门》（CS50）课程，或其他由Flatiron School提供的许多入门和高级技术课程。

2. 公司关于PM的理念

每个公司都对产品开发过程和PM在该过程的切入点有不同的理解。以下只最普遍的类型，包括类型的优缺点。

（1）产品驱动研发

这是一个“各管一摊”的方法，此方法中PM收集需求，编写需求文档，然后交给研发，规范技术需求。

现在的组织可能会用一种更敏捷协作的方法进行这个流程，但需要PM非常了解用户需求和技术可实现性。

• 优点：工程师可以专注于代码，不被分心；这个方法适合有长生命周期的瀑布流开发工作。

• 缺点：工程师不了解产品整体情况，无法产生对用户的同理心，因而造成用户体验差。但当技术问题需要排在用户需求前时，会出现不利的紧张感。

（2）研发驱动产品

更多面向技术的产品公司（如云，大数据，网络）都是有研发驱动，公司里的工程师都是在其领域最前沿的人，PM验证解决方案或者建立前端接口（UIs，APIs）来接入最新科技。

这种情况，会出现客户、PM和研发之间的合作关系与反馈循环。

通常PM在这些公司里服务于研发。

• 优点：突破性技术可以给用户提供他们不知道他们需要的产品。VMware中的VMotion就是很好的例子。一个工程师觉得这么做很酷，PM想到用它变现的方法，于是VMotion就给公司带来了数十亿美元的收入。

• 缺点：工程师追求酷炫的新东西，过度技术化的方案，或永远反复迭代，在获得用户反馈前就追求完美。PM排出的优先级被忽视，而优先级中包含了用户需要的基础功能。

（3）PM-工程师合作关系

在这种情况，PM和工程师有很强的阴阳关系，共同发现、做决策、分担责任。

工程师参与PM的用户调查，PM参与冲刺会议，帮助拆解任务，明确需求。但是两个角色知道在哪里止步，不相互干涉。

PM理解编程内容，但是不会告诉工程师如何编程，工程师有用户需求的同理心，但会把优先级排序留给PM。

• 优点：一个流程化的优先级处理过程可以优化技术负债和“管道”工程；良好的设计过程产出正面的用户体验；高效率团队有着高效率，高质量和更开心的用户。

• 缺点：突破性的革新可能不会被通过。上线时间也许会延后（尽管我认为上线时间要与用户的需求结合，才能成功）

我很明显地偏向第三种理念，因为我体验过这三种理念，并发现阴阳体系是最有效率的。

但是并不是说另两种不好—— 这真的取决于在做的产品，公司阶段和其他因素。

3. 公司阶段

PM的角色在创始公司更像是万能角色，而在成熟公司，PM角色被划分的更细（Banfield，Eriksson，和Walkingshaw在《产品领导力》一书中，有一章节详细介绍了此问题）。

（1）创始公司

除了发现、定义和推出产品，PM也许还会负责定价，支持，甚至销售产品。这些PM成长在不连贯的环境中，习惯于公司在努力进行市场匹配的时候，创造的矛盾又频繁的产品方向变动。

• 优点：PM更容易参与公司的策略，与高层领导和董事会离得更近，有能力冒更多的险，有更大的影响力。他们对公司资源有跟更多的影响和权利。

• 缺点：基本没有导师，榜样或公司内的成功实践。（你可能需要在公司外寻找）预算紧张，而且PM没有相关的必要经验。

（2）成熟公司

PM可能会有狭窄的眼界，有同时帮忙解决定价，入市策略，等等。而且他们属于PM大团队的一部分。

• 优点：PM更有可能有导师指导，榜样，开发标准和公司内的成功实践。长时间与开发团队的亲密配合可以建立牢固的关系。非常有利于长期影响和职业成长。并且，如果产品与市场契合，公司有现成的用户基础和性能底线做开始，不需要再去一再猜测。

• 缺点：PM很少接触公司策略，并且只能听到一种客户声音。PM在体制中迷路，并且需要处理更多办公政治和紧缺的预算。

（3）创立者/CTO/CEO 与PM的关系

尤其是公司早期，知道如何让创立者/CTO/CEO参与到项目进程中非常重要。如果他们参与过甚，PM更多会扮演支持角色，帮助他们实现他们的想法或验证用户概念，并与实现PM自己的想法产生冲突。

对一些PM来说，这会非常有趣，与创始人和C级别的执行官们合作，创造产品。

但是对另一些PM，这会让他们非常沮丧。如果他们喜欢自己控制产品方向。这也会非常有挑战性，如果一个更加技术性的创始人或C级执行喜欢直接与工程师合作；这样会让PM被留在圈外，没有威信（有时是无意的），不但造成个人的挫败感，而且会延迟进度。

当考虑一个PM角色可能与创始团队密切合作时，确保了解他们对PM功能的期望，再决定这么做是否符合自己的利益。

当然，对于任何角色，都有很多需要考虑的因素，比如产品类型（B2B，B2C，工业类），与你合作的同事，总体企业文化（多元化，包容心，弹性工作时间，远程合作）当然也包括工资和福利。还有很多关于招聘PM的文章，通过它们可以看出招聘经理想要什么—— 我特别推荐我的朋友 Ken Norton的一篇文章 “如何招聘PM”。

但是，如果你想努力成为伟大的PM，你需要签下一个工作前考虑我上面所说的。发展核心技能是需要贯穿你生涯始终的，而利用EQ可以保证你有正向的经理。但你在哪里工作，他们如何工作，你和谁工作，与谁工作会最终决定你长期的成功。

———— / END / ————

原文地址：https://hbr.org/2017/12/what-it-takes-to-become-a-great-product-manager

原文作者：Julia Austin

译者：Tina Ruan

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