产品管理剧场 | Marty Cagan（硅谷产品集团）

Marty Cagan 2024-03-10

产品管理剧场 | Marty Cagan（硅谷产品集团）

访谈记录

Marty Cagan：毫无疑问，疫情期间很多公司过度招聘了。我走进一些公司，说实话，我简直不敢相信他们设置了那么多荒唐的岗位——敏捷教练、产品负责人、产品运营、业务分析师。

Lenny：这基本上就是你所说的那种”剧场”，那些并非真正产品经理的人。

Marty Cagan：相对于他们提供的价值而言，他们的薪酬严重过高。因为那本质上是一个项目管理角色。交付产出比交付成果要容易得多。

Lenny：是什么让你决定再写一本书，这本书讲的是什么？

Marty Cagan：我们行业里有太多人把自己看作公司的受害者，觉得自己被困在功能团队里，除了辞职什么都做不了。我认为事实并非如此。他们能做的事情太多了。

嘉宾介绍

Lenny：今天的嘉宾是 Marty Cagan。Marty 在超过 20 年的时间里一直帮助产品团队和产品经理提升他们的专业能力、流程和职业发展。他与更多的产品团队和更多的产品经理合作过，比这个地球上任何一个人都多。他还撰写了产品管理领域最受欢迎的两本书——《INSPIRED》和《EMPOWERED》，而本周他将发布最新的著作《TRANSFORMED》。在这次对话中，我们讨论了一些犀利而重要的话题：产品管理领域正在走向何方，产品经理及相关职能的过度招聘，一个他注意到的趋势——产品管理剧场。还有，为什么你在网上找到的大多数产品管理建议都是错误的，以及为什么会这样。为什么很多产品经理实际上只是项目经理，以及如何避免成为那样的人。还有，如何避免招到那样的人。你需要培养和构建哪些技能才能成为一名出色的产品经理，尤其是在 AI 时代。

如何推动你的团队和公司向赋能型转变。你在功能团队工作的迹象，以及为什么你可能不想待在那里，还有更多内容。如果你关心产品管理领域及其未来走向，你一定会喜欢这一期。话不多说，稍后由赞助商播报之后，我为你请出 Marty Cagan。

(广告段落已跳过)

重返播客

Lenny：Marty Cagan，欢迎回到播客。

Marty Cagan：非常感谢，Lenny。谢谢你再次邀请我。

Lenny：感谢你回来。我们上一期合作的节目仍然是我整个播客中排名前五的最受欢迎节目之一，这太疯狂了，因为当时播客的规模比现在小得多。你还有一本新书即将出版，我们会谈到这个。你近来的写作也越来越犀利了，你写了关于产品管理剧场、产品领导力剧场等等这些话题。所以我很有兴趣深入探讨这些问题。我想先问问，是什么驱使你最近写作风格变得如此犀利？

为什么写作越来越犀利

Marty Cagan：这是有意识的。我发现自己——我也意识到自己在逐步调高这些话题的修辞力度。实际上这些东西我已经说了很久了，真的是很久，而且都有记录可查。你可以去读十年前、甚至二十年前的博客文章。但形势正在发生变化。首先，我应该承认一点——我不知道你是不是这样，Lenny——但大多数我认识的产品人都跟我一样有一种危机感。我们总是在担心有新的东西冒出来，把我们的客户抢走，颠覆我们的产品。所以我知道自己有这方面的倾向。我一直在关注哪些因素可能真正搅动局面，无论是朝好的方向还是坏的方向。有一些事情我长期以来一直非常担忧，而且我认为现在多重因素正在同时汇聚。其中一个挑战在于——这些变化是同时发生的。

所以有若干事情正在并行发生，这恰恰是混乱和大量恐惧的温床。在产品社区、设计社区、工程社区，你都能感受到这种氛围。你能看到它。跟你一样，我几乎每天都在跟人交流。所以我确实有很多关于为什么会这样、以及人们怎样才能最好地保护自己、保护自己的职业生涯和公司的理论。我很乐意分享这些想法，但这不是一个小问题，不是一个小的因素集合。不过在我展开讲之前，我想大家应该了解我的出发点，以及它跟你的出发点有什么不同，因为这个视角……需要说明的是，我认为我们都在努力帮助产品社区，但我们试图以非常不同的方式来做这件事。

两种不同的使命

Marty Cagan： 我想说明一下，我非常欣赏你做事的方式。事实上，如果有人不知道的话，我是你的付费订阅者，因为我觉得它对我的工作非常有用。那我们来聊聊这件事。你显然比自己描述得更好，但我的理解是——这也是我觉得有价值的地方——你在分享越来越广泛的视角、人物、工作方式、做产品的方式，以及对产品模型的实验、对领导力的实验。我非常喜欢这一点。它确实帮了我很多。这也是我订阅的原因。说实话，我之所以最终订阅，也是有人推了我一把——我知道在有一百种产品相关newsletter和其他东西的情况下，花钱订阅某个服务是需要理由的——但事情的经过是，你的订阅者很多，我认识的人看到什么内容就会发邮件给我，说：“你看到 Lenny 跟某某聊的那个话题了吗？你怎么解释那个？你怎么看这件事？”

这让我想去看很多这类内容。有些公司我认识，但另一些是你介绍给我的，我在那里谁都不认识。对我来说这极其宝贵。这比过去方便多了——以前我得大量出差，跑很多公司。所以我非常喜欢。你在帮助很多人获得对产品更广阔的理解。而我的目标不同，SVPG 的目标不同。我们同样在努力帮助产品社区，但有趣的是，当我看你的访谈时，你在试图从人们身上挖掘出他们做的事情有什么特别之处——这正是我想听到的。但有趣的是，我寻找的不是差异，而是共性。我们的核心使命是分享那些最优秀的产品公司持续使用的原则和实践。事实上，我们有一个经验法则——这一点我们从未隐瞒。

我们经常被问到新技术、新方法、新流程，我们的回答是：“我们需要看到它被至少几家已经证明能够持续创新的公司所使用。“如果这些公司能有效地运用它，我们就会大力推广。我们在每本书里都说得很清楚：这些东西没有一项是我们发明的。我们只是——如果它们有效，我们就愿意谈论它们。所以我们寻找的是共性，而主要目标是帮助一家公司——无论是初创企业还是大公司——获得最大的成功概率。这就是我们的目标。是一个不同的目标。你能看出来。所以所有这些数据点作为数据点来说很有意思，但我们在寻找的是那些经得起时间考验的东西——而你永远不知道，你必须去观察。

举个例子，我很喜欢跟初创公司合作，但正如你所知，很多初创公司是由创始人和早期团队主导的，他们用什么技术几乎无所谓。如果他们足够优秀，做出的东西令人惊叹。就是那么了不起。这一点可能需要先说清楚。

Lenny： 我很喜欢这个视角。

Marty Cagan： 把这个视角带出来。

Lenny： 我同意你说的所有内容。我认为我们为产品社区提供的东西确实非常不同。有趣的是，坐在这支麦克风的这一侧，我对记者产生了很多共情。我知道 Brian Chesky 那期节目就是一个很好的例子——其中有很多内容听起来可能有问题，你也有不同意见。作为采访他的人，我面临的挑战是，我只有他一个小时的时间，我必须不断做决定：是去追问反驳、试图弄清楚”这真的像你描述的那样运作吗？这真的是正确的方式吗？这就是为什么你可能不该这样做”？还是说，我有那么多话题想要触及、想问他——我就想，我该往哪个方向走？而且如果我反驳得太厉害，人们会说：“我才不去上那个播客呢，他就是在质疑我认为的一切。“所以这是一个非常有趣的角色。

Marty Cagan： 我认为这完全合理。而且，你也不想吓跑你的嘉宾。这毕竟是他们分享自己认为重要的事情的平台。不过我确实一直觉得很有趣，因为你报道的一些公司我已经认识了，听他们描述自己的做法，然后对比我在他们公司实际看到的情况——当然两者不总是一样——这总是很有意思。但这就是人性，我们都会这样做。总之，我希望你继续做你正在做的事情，Lenny，我也会继续关注。

Lenny： 太好了，非常感谢。对你也一样。

Marty Cagan： 好的。

人们需要听到的话

Lenny： 那么关于写作，我觉得按照你描述的方式，言下之意基本上是——你在告诉人们他们不想听但他们需要听的东西。你是这样看待这件事的，对吗？

Marty Cagan： 是的。事实上，我有一些非常让人不舒服的话题要谈，我知道自己更理智的那一面会说”别提那个”，但另一面会说”但人们需要听到它”。

Lenny： 既然人们需要听到，那我们就来聊聊——我也同意这一点。你一直在谈论”产品管理剧场”和”产品领导力剧场”这些概念。让我们深入聊聊。它看起来是什么样的？你怎么判断自己身处这种”剧场”之中，还是在以正确的方式做事？

产品管理剧场

Marty Cagan： 毫无疑问，很多公司在疫情期间过度招聘了。这一点即使在当时就能看出来。而且不仅仅是过度招聘，很多公司还降低了招聘标准。但与此同时，金融世界也发生了变化，融资成本大幅上升。这是另一件同时发生的事情。而可能最大的一个因素——这也是最难的，因为它还没真正发生——就是生成式 AI 预期带来的影响，对吧？我不知道你有没有看到，NVIDIA 的 CEO 前几天 literally 就在说”不要学编程”。

首先，我甚至不确定那是不是好建议，但世界上最重要、最令人惊叹的公司之一的 CEO 说”不要学编程”——这本身就是颠覆性的。至少，它在公司领导者中制造了不确定性——至少是这样。但说实话，我认为会产生非常真实的影响，我对此深信不疑。我只是不知道真正的时间线。我有很长一段时间都过于乐观，总认为事情会比实际发生得更快。所以我不知道它们究竟什么时候会真正到来，但这是一个大问题。还有一个我认为没有被充分讨论的问题——在很多公司里，尤其是硅谷以外的公司，团队规模已经失控了。我走进一些公司，说实话，我不敢相信他们竟然有那么多荒唐的岗位。如果你想的话我后面可以展开讲，但毫无疑问，人们已经意识到更小的团队往往能产出更多、更好的成果。

远程办公与组织臃肿

Marty Cagan： 你的嘉宾里有多少人也这么说了？我从很多人那里都听到了这个说法。讽刺的是，缩减组织规模反而能带来更多成果。所以现在人们普遍意识到，也许我们在这些角色上做得过头了。当然，我说的就是敏捷教练、产品负责人、产品运营、业务分析师，以及各种助理产品经理类的角色。如果你愿意的话我们后面可以展开讲，但在很多公司里，这已经失控了。

还有一个话题我可能不该提，因为它几乎已经变成了一个宗教式的话题。我知道这对很多人来说是个超级敏感的话题，但现实是，远程办公让速度和创新都受到了真正的打击。别误会，我不认为我们会回到大公司几乎全员集中办公的那个时代。但毫无疑问，我与很多公司合作过，他们都在创新和速度上苦苦挣扎。事情进展得更慢了，他们也不像以前那样做那个层面的创新了。这些都是重大因素，是正在发生的宏观因素。

更糟糕的是，如果你走出硅谷的泡沫，情况更糟。因为这些公司——尤其是大公司——在所有这些多余角色上投入了大量资源。我提到了敏捷教练，还有 Scrum Master 和你能想到的每一种项目经理，他们无处不在，还有各种产品人员的助理。我觉得这已经疯了。事实上，我很久以前——大约十年前——写过一篇当时很受欢迎的文章叫《Epic Waste》，我就在指出这个问题，说这太疯狂了。讽刺的是，越优秀的公司用少得多的人做出了多得多的成果。

流程崇拜与浪费

所以，回到角色的问题。那这么多年以来，那些大公司一直认为答案在于流程呢？尤其是像 SAFe 这样的东西——在硅谷以外的世界里，它令人沮丧地流行。即便是 Scrum 这样简单的流程，很多人都没有理解，更别说掌握要点了。所以在世界上这么多地方发生的情况是，花了这么多成本，能拿出来的成果却少得可怜。我们谈到光人数本身就成问题，成本之高令人震惊，浪费之严重基本令人尴尬。所以公司做出反应并不让我意外。更大的意外是，老实说，竟然有这么多的公司花了这么长时间才意识到正在发生什么。

归根结底，今天我认为每个人——尤其是那些流程和角色臃肿的大公司——都需要认真审视自己如何构建产品、如何服务客户。他们需要更认真地看看那些最优秀的公司是如何用少得多的投入获得多得多的真正回报的，真正重新审视如何最好地满足客户需求。这就是转型的意义所在——转向那样的工作方式。我认为那些做得好的公司，才有最大的生存机会。

“我们不需要产品经理”

Lenny： 我觉得还有一个更广泛的趋势，就是很多地方的人真的不喜欢产品经理。就是这种趋势——“我不想让我的公司有产品经理”、“我不想让我的创业公司有产品经理”、“很长一段时间里我们不会有产品经理”。好像已经成了一种普遍观念。而我想你的意思是，这其中很大一部分原因在于很多被招来做产品经理的人并不擅长这份工作，人们接触到的产品经理就是那样的人。

Marty Cagan： 我觉得答案是另一回事。我还没有深入讲这个，但你可能知道。那些例子——极少数例外——我一直在听到，几乎每天都有——你描述的那些情况，它们都是功能团队。事实是——我也说了很久了——功能团队根本不需要产品经理。不需要，因为在那种情况下它就是一个项目管理角色，Lenny，而且他们已经有足够多的人可以承担这个职责。而且很多时候工程师或设计师会说，“我们宁愿自己做，也不想跟这个总想当所有人的老板、实际上什么贡献都没有的人打交道。“所以在我看来，真正发生的就是这样。他们要么是交付团队（delivery team），要么是功能团队——在这种模式下通常是功能团队。

我不怪那些人觉得产品经理没有价值。他们确实没有带来那个价值。公平地说，他们确实带来了一点价值，但——这话说得很残酷——相对于他们提供的价值来说，他们的薪酬严重过高。但另一方面，在一个真正的产品团队里，那是完全不同的工作，我没有看到那种抱怨。事实上，我认为你提到的那个抱怨是最大的线索——他们很可能就是功能团队。然后我会去问他们是怎么工作的，那个人具体做什么……当然，我问产品经理的第一件事就是：你怎么定义你的工作？我猜你听过一百种版本的含含糊糊、模棱两可的回答——“我做些协调工作”、“我做些沟通”、“我管理这些人”——我听着就想，天哪，我可不想试着向 CEO 捍卫这份工作的价值。

功能团队 vs 赋能型产品团队

Lenny： 我知道你经常谈论团队和产品团队。我想人们可能还不是百分之百确定你具体指的是什么。那我们就花点时间聊聊，功能团队——或者说功能工厂——到底是什么样的，和赋能型产品团队有什么区别？

Marty Cagan： 嗯，有很多线索。最简单的一些就是：在功能团队里，你基本上会被给到一张以产出为导向的路线图。关键就在这里——产出。换句话说，他们的功能就是项目，通常可能来自某个高管，可能来自某个大客户，也可能来自其他什么地方。但就是一堆功能，你被要求去设计、构建、测试、部署这些功能。通常还会给你日期和时间节点，这就是功能团队。你的任务就是交付。别误会，这仍然是工作，但这是产出。交付产出比交付成果要容易得多。

而产品团队——赋能型产品团队——他们得到的不是那张功能路线图，而是需要解决的问题。可能是客户问题，也可能是业务问题，或者两者兼有，但他们被给予的是一个需要解决的问题。通常是每个季度一到两个——当然还要加上大家都在做的日常维护工作——但他们被给予的是难题，衡量标准不是”把东西发布出去”，衡量标准是它是否解决了问题。这就是为什么强大的产品公司和其他公司之间最大的区别就在于：强大的产品公司理解一切的核心是成果。你不会因为发布了东西而得分，你是因为交付了价值而得分。

我跟很多 CEO 和 CFO 交流时，他们最有共鸣的是当我把它表述为：关键在于 time to money 而不是 time to market。我们知道怎么做 time to market。如果你坚持要 time to market，我们知道怎么做，那些技术是众所周知的。更难的是 time to money，而我知道这才是他们真正关心的，这才是更难的部分，也是产品团队真正在做的事情。

产品经理的真正职责

Marty Cagan： 只有当你承担了成果导向的责任时，你才真正需要产品经理。我想说，按照硅谷的标准，那就是你需要产品经理的时候。因为如果你被要求解决这些问题，意味着你必须想出一个方案——不只是可用和可行（这是功能团队做的事），还要有价值、有商业可行性。而这就需要一套工程师和设计师几乎不具备的不同技能。这不是在贬低他们，而是因为那些是非常不同的技能组合。所以你需要一个深入理解客户、深入理解业务的人。这正是产品经理这个角色的由来，也是优秀产品公司中他们至今仍承担的职责。这是一份非常不同的工作。而且，如果一个人真正在扮演这种产品经理的角色，他几乎不可能有空闲时间去干预设计师的工作、帮他们画线框图，或者去打扰开发人员。他们有自己的事情要做。

Lenny： 这基本上就是你所说的”剧场”——那些并非真正产品经理的人在做产品管理的活动。你能具体讲讲这是什么样子吗？

Marty Cagan： 最典型的例子就是，他们顶着产品经理的头衔——很大程度上归功于你，全世界都知道这个头衔很酷——但他们并没有在做这个角色该做的事，也不具备相关的技能。当然，真正让我不安的不是这个。让我不安的是，如果他们有动力的话，其实并不难。培养这些技能并不难，这也是我跟人们讨论的内容。你可以提升自己，真正在这一层面上做出贡献。这不仅是你应该为自己的职业发展做的事，而且——并非巧合地——这也是你的公司需要你做的事。

价值与可行性

Lenny： 有些听众可能在想，我需要培养哪些技能才能成为真正的产品经理？我记得你经常说的是，核心在于价值（value）和可行性（viability），而这正是很多问题的——

Marty Cagan： 价值和商业可行性正是产品经理的职责所在，就像工程师负责技术可行性一样——方案必须能够被构建和交付。而产品经理负责的是价值和商业可行性。我喜欢换一种说法：在一个真正的赋能型产品团队中，产品经理是创造者，不是协调者。每次有人跟我说”我的工作是说明为什么（why）“的时候，我都会觉得尴尬。我就想问，“那除了说清楚’为什么’这十分钟之外，这一周剩下的时间你都在干什么？“太荒唐了。但人们真的这么想。不过你知道，在功能团队里，当你绞尽脑汁为自己的存在价值找理由时，这种想法也不奇怪。但事实是，“为什么”其实来自产品战略，你连”为什么”都不是你定的。

产品经理是创造者，所以要与设计和工程并肩创造，共同得出解决方案。为了做好本职工作——代表价值和商业可行性——需要一些真正的技能。首先，你必须真正成为你的用户和客户的专家。我知道当年我被允许担任产品经理角色之前，必须亲自拜访三十家客户——美国十五家，欧洲十五家。这是我当时的导师定的规矩。我只知道那三十家客户改变了我的一生，因为我以为我了解客户，但其实我并不了解。其次，你应该是数据的专家——我们的产品是如何被使用的？使用方式随时间如何变化？购买方式是怎样的？这些都是大事。还有一个重要的是，你是团队中代表合规问题、销售问题、营销问题、财务成本问题、变现问题，以及整体推向市场（go-to-market）的那个人。

产品经理与产品负责人的本质区别

所有这些法律约束，所有这些都是产品经理的事。你想想，如果团队中没有这个人，你又想让这个团队有能力自主决策，怎么办？凭空编造吗？还是像通常那样——召集二十个利益相关方坐在一起开会来决定这些事情？那就倒退回了委员会式设计。所以不行，产品经理需要把这些知识带进来。他们还需要对市场有深入的理解。当我把这些描述给一个典型的产品负责人听时，他们的反应是”我们完全不在同一个世界”。他们在 CSPO 或 PSPO 课程中学到的是如何在 Jira 中管理 backlog，这在我看来非常类似于学习如何操作 Google Docs。当然，那不是真正的工作。那是我们每天都在做的事，但它不是工作本身，就像……

开发人员每天都在用 Jira。难道那就是他们的工作吗？当然不是。他们的工作是构建产品。这就是产品经理所贡献的。如果你把它看作一个光谱：一端是产品负责人——说实话，那是交付流程中的一个角色，根本不值得设一个专职岗位，真的不值得。我认识的大多数团队中，资深工程师都能比产品负责人做得更好。光谱的另一端就是我们所说的赋能型产品经理。而功能团队的产品经理则处于两者之间。他们做的比管理 backlog 多一些，他们做大量的项目管理。别误解我，项目管理很重要，但它不是产品管理。而且，在我见过的几乎每一家有功能团队产品经理的公司里，本来就有一大堆项目经理。

行业警钟

你能听出我语气中有些无奈，因为我觉得这些道理已经很清楚了，但大多数公司对此充耳不闻。他们不在乎。我有自己的猜测为什么会这样，但说出来挺令人沮丧的。不管原因是什么，我觉得我现在需要提高音量，因为人们正在以惨痛的方式认识到这一点——很多公司在裁员，而这些角色恰恰是公司中最脆弱的人群之一。

Lenny： 让我读一段你写的话，正是关于这一点的。你写道：“几年来我一直在警告，交付团队的产品负责人和功能团队产品经理很可能面临清算，因为公司会意识到这些角色并不是他们以为的那样。据我所知，这场清算已经开始了，而且我预计 GenAI 只会加剧这一趋势。”

Marty Cagan： 这是悲观版本的世界观。也许我反应过度了。也许吧。我不以危言耸听著称，但也有可能。我希望如此，但我表示怀疑。我认为这些趋势是真实的。那么，这是否意味着人们……没希望了？他们都应该重新去学什么？比如说房屋建造之类 GenAI 可能替代不了的？不是的。我认为真正要做的是提升你的技能。别再搞交付团队和功能团队那些虚假的表象了。你应该提升自己的技能。很多产品经理联系我说，“我知道我在一个功能团队里，我不喜欢这样。“我经常用”被困在功能团队里”这个说法——他们说”这不是我当初想要的。关于产品管理的那篇《纽约时报》文章里写的不是这样的。那是不一样的。“然后他们问：“我该怎么办？是不是应该离开公司，去那些别的公司？“

个人也能推动改变

Marty Cagan： 我试图向他们解释，他们实际上拥有的主动权比他们意识到的要多得多。作为个人贡献者，能做的事情其实很多。当然，产品领导者能做的要更多。而这正是整件事中最大的遗憾——产品领导者们没有在推动这件事。大多数产品领导者没有这么做，因为他们当然有很大的主动权，有很大的能力去改变一家公司。但个人同样可以做到。他们可以提升自己的水平。他们可以真正做一次自我评估，把技能从产品负责人或功能团队产品经理提升到真正的产品经理。至少，我告诉人们——而且我见过无数次这样的例子——至少，你的公司会感激你，很可能会提拔你，因为你是少数真正理解这些东西的人之一。更理想的情况下，他们会说，嘿，我们为什么不试试用这种方式来管理一组团队，看看效果如何？所以这种改变也可以自下而上地发生。

Lenny： 我想很多人在想，我该怎么做？我知道你写过书，应该也有课程和各种资源。如果你能给人们一些建议，告诉他们如何在这方面做得更好、应该专注哪些技能，你有什么快速的建议可以分享吗？

认证机构的误导

Marty Cagan： 这可能是我所有事情中最令人沮丧的一件。事实上，我之前应该回答你问我是什么让我开始”火力全开”的、是什么让我忍无可忍的。也许那天我就是心情不好，谁知道呢。但就是那篇在网上广泛传播的文章，出自大概最大的产品经理认证机构。他们发了一篇大文章，标题是”产品经理是做什么的”。配了一张大图，我看着它心想，我简直不敢相信他们竟然把这个白纸黑字写出来了。这百分之百是项目经理的工作，百分之百。他们甚至都没有假装往产品方面靠一靠——大多数人至少还有点创造力，会稍微弯一下让它看起来像产品经理的工作，但这连边都沾不上。

我意识到，令人如此沮丧的是，所有这些人都意识到事情不对劲，但他们能找到的大多数资源都在传播同样的模型。这些认证，在我看来就是假的，但大多数人不知道。想象一下你是一个全新的产品经理，你上网去看，大概百分之九十的内容都来自功能团队的世界，甚至更糟。所以除非他们真的很幸运，或者碰巧有一个好的经理在引导他们往正确方向走，否则这种模式就会不断自我复制。你到处都能看到这种现象——文章、书籍、会议演讲者，很多时候我甚至看不下去。并不是说没有优秀的人可以出来演讲，只是按比例来说他们是少数。所以事情本不该这么难，但确实不容易。就像你说的，为什么人们不能直接去学呢？

如果他们足够幸运知道去哪里学，他们是可以学到的。显然我有偏见，你也有偏见，我们在这件事上都有偏见。但人们需要更多地掌控自己的职业发展，真正运用自己的判断力，去想清楚：如果你想留在产品领域，你想成为什么样的人？你想成为什么样的产品经理？如果你想留下来，那也行。但如果你想走这条路，好的资源肯定是有的。好的资源确实存在。当然，我希望越来越多的人这样做。

社区的自我复制

Lenny： 我觉得你刚才分享的这个洞察非常有力量——你在网上找到的关于产品管理的大部分内容，我想你说的是百分之九十，都来自那些做法不对的公司，你用的说法是功能团队。你能再多谈谈这个吗？为什么会这样？为什么我们听不到更多来自优秀公司的声音？

Marty Cagan： 事实上，最令我沮丧的事情之一就是社区。社区有很多好的方面——你拥有当今最大的社区之一，产品领域还有很多这样的社区、产品子社区。我喜欢社区的一点是，你遇到的几乎每一个人都真心想帮忙。真的，每一个人。但问题是，有人发了一个问题——每天都会发生很多次——大多数好心的人就会跳进来，分享他们在自己那家糟糕的公司里学到的东西。我看着这些回复，提问者说，“哦，非常感谢，现在我知道该怎么做了。“而我在想，“哦不，又一个被带偏了。“这就变成了自我复制。你又能怎么办呢？难道让某个人去监管这些板块上成千上万的内容，比如一个 Lenny 认证的人或者 Marty 认证的人？我不想做这件事，你大概也不想。

Lenny： 不想。

Marty Cagan： 那就是灾难的配方。所以这种模式传播的原因太多了。我看到的大多数书籍——我被邀请审阅很多书——当出现例外的时候我很高兴，会觉得，哇，这是一本好书。Teresa Torres 的书《Continuous Discovery Habits》，好书。我尽量让每个人都去读那本。但那是例外。大多数时候，人们在认真地描述自己在公司里学到的东西，而不是真正优秀的公司是怎么做的。所以这非常困难，因为他们不是坏人，他们是出于好意。

学会批判性思考

Lenny： 对于那些提问后得到回答、但不确定该不该听信这些人的人，你有什么建议吗？

Marty Cagan： 这在整个世界都是一样的道理——买者自负。你必须运用自己的判断力，你必须思考。对产品人来说最重要的技能——我知道这听起来不太好——但确实是学会如何批判性思考。这包括真正的评估。我帮助别人准备面试的时候经常跟他们说，“听着，最重要的是，你需要对你未来的直属经理做一些研究。做一些背景调查。去看看他们之前在哪里工作，LinkedIn 上都有。去了解那些公司，了解那些产品。确保你在这些方面做好了准备，因为这才是真正重要的。重要的不是公司，而是谁会来指导你。“所以人们可以做很多事来做好准备、武装自己，更多地掌控自己的职业发展。

Lenny： 有意思的是，我相信你也遇到过这种情况，我分享一个我想到了的例子。我在 Airbnb 工作的时候，读你的文章，我心里想，“谁会那样工作啊？他写的那些公司，就是拿到一个路线图然后执行——真的有人这么做吗？“我心里想，“不可能，这不是真实存在的。他在写什么啊？“那是因为我在一家做得好的公司工作——我知道你对那里的现状也有不同看法——但不管怎样，我猜很多听这期节目的人会想，我不相信很多公司是这样运作的，你在说什么？同时我也能想象，有很大一部分人在功能工厂工作，他们会说，不，其实挺好的，没有你描述的那样。所以我猜这对你来说确实非常令人沮丧。

Marty Cagan： 是的，我也有过同样的经历，因为我职业生涯的大部分时间都待在那个同样的泡沫里。当我发现别人不是像我们那样工作时，我非常惊讶。我还记得那是什么时候，因为当时我是一个开发工具的开发者，我在构建工具的时候假设所有人都是像我们一样开发的。然后我被派了出去，我之所以记得，是因为其中最让我大开眼界的一次访问是我第一次去沃尔玛总部。他们的做法截然不同。他们有完全不同的工作方式、完全不同的设备，一切都不一样。那是一次警醒。就像在说，你知道吗？我活在一个泡沫里。硅谷和世界上大多数地方不一样。当然我后来意识到，为什么不呢？为什么阿肯色州、印度和其他地方的公司不能获得同样的方法、工具和技术呢？这正是创办硅谷产品集团的灵感来源——把这些东西传播出去。

我跟人有过完全一样的对话。我记得你说这话的时候，Shreyas Doshi 第一次跟我说了同样的话。他问我——因为他认识我——他说，“我知道你写这些东西，但我真的不敢相信人们真的这么做。“我跟他说，“Shreyas，我真希望这不是真的。“但他今天已经不再怀疑了。

Lenny： 是的，因为他现在也在做大量这方面的工作。我好奇的是，如果有人在一个功能团队里，就这么待着也觉得挺开心，这样可以吗？今天 LinkedIn 上其实有一位产品经理 Ben Erez 发了帖子，谈到如果是 B2B 销售驱动的公司，也许做成功能工厂也没什么，因为人们非常清楚需要构建什么，你就把这些东西建出来，挺好的。我们不需要你来引导我们的成果。你怎么看？有没有可能就是，这样也行？

Marty Cagan： 嗯，我的第一个回答是——大多数 B2B 软件之所以那么烂，这不是偶然的。它们确实很糟糕。当然，那些真正脱颖而出的，通常不是这个模式。所以销售驱动型产品，别误会，像 Oracle 这样的公司靠销售驱动产品获得了巨大的商业价值，但你真的想成为 Oracle 吗？你想成为 SAP 吗？有人喜欢那些产品吗？我不知道。我不确定我有没有见过不讨厌那些产品的人。所以不行，我觉得那只是糟糕的产品。不过我想说，一些我最喜欢的案例……事实上，在新书里我们专门介绍了一个经典的销售驱动型金融服务公司转向产品模型的故事，以及这种转变如何极大地改善了销售团队的工作。

销售驱动型产品为何普遍

还有一个更深层的原因，我认为为什么会有这么多销售驱动型公司存在——那就是在那些公司里，大多数情况下 CEO 不是做产品出身的，这就是他们那样运营的原因。除非 CEO 自己意识到这样不行——通常是因为某个优秀的产品公司跑来抢走了他们的客户——否则这种情况大概不会改变。

Lenny： 明白了。所以你的反馈基本上是——你可以这样运营，但你不会做出伟大的产品，长期来看你会遇到竞争压力？

Marty Cagan： Lenny，我还想说的另一点是，赋能型产品团队能做到功能团队能做到的一切，而且还能做得更多。偶尔我确实会听到有人说，做一个功能团队有什么不好的？你怎么回答这个问题？对我来说就是——你为什么要做这行？你真的不在乎客户怎么看待你的产品吗？说真的？我知道如果我有发言权的话，我绝不会雇用你，因为这是我们在候选人身上最先看重的东西之一。我们希望人们真心关心我们的客户、关心我们的业务，致力于让客户的生活变得更好。所以我对那些人没有太多同情。不过我知道他们有充足的资源可以混得不错，没问题。我关心的是那些真正想做得更好的人。

Lenny： 这让我想起你的同事 Christian 在我们播客那期节目中说过的话——我们能有机会解决人们的问题、帮助他们，这是多么幸运的事。

Marty Cagan： Christian 就是我们所谈内容的活生生的例子。毫无疑问。他为这些机会而生。

自上而下与自下而上

Lenny： 我想谈一个话题。我之前采访了 Meta 的 CTO，你提出了一个非常有意思的观点。当我想到 Meta/Facebook 的时候，我总觉得他们是一个非常自下而上的文化。团队里的人构建实验、运行各种东西，没有太多”做这个、做那个”的指令。但他的表述是，Meta 其实是非常自上而下的。Zuck 和高管团队决定我们在做什么、这是我们的战略、这是我们的重大押注。所以他认为 Meta 实际上比自下而上的团队要自上而下得多，只是表面上看起来像是自下而上的吧。我知道自下而上与自上而下，和功能工厂与赋能型产品团队之间是有区别的。但我想听听你的看法？

Marty Cagan： 首先，我想说他描述的正是我在优秀产品公司里看到的情况，完全一致。但我们不把它定义为自上而下。自上而下意味着完全不同的东西。事实上，把一个功能路线图交给一个团队，那才是真正的自上而下。另一个非常常见的误解——同样，很多敏捷教练误导了大量组织——那就是产品团队不做产品战略。产品领导者做产品战略。他们需要做产品战略。当然，我不是 Meta 最大的粉丝，但 Zuck 非常擅长做产品，非常擅长。这也是这个世界的问题所在——他太擅长了。但那就是他的职责所在：做出战略决策、聚焦决策、决定要押哪些注。然后在优秀的组织中，你把这些押注交给团队，并真正给予他们自主权去找到解决方案。

说实话，我已经有一段时间没跟 Facebook 合作过了，但他们当时有非常优秀的团队，非常优秀的产品团队——真正的跨职能团队，真正的工程师、产品经理和设计师，他们能解决非常难的问题，这正是他们优秀的原因。所以我不把它定义为自上而下。我把它定义为产品领导者做好了自己的工作，产品团队也做好了自己的工作。关于赋能到底意味着什么，很多人存在一个非常普遍的误解。赋能不是说你好不容易组建了一个产品团队，然后让他们自己决定做什么。不，那只是无政府状态。你会让 50 个团队做 50 件不同的事。相反，赋能意味着领导者做好自己的工作，提出要押的注，然后让团队有能力找到解决那些问题的最佳方式。

PM 角色的转型

Lenny： 太好了，这个澄清非常有价值。我觉得很多人并没有完全理解这一点，所以这对很多人来说确实很有帮助。说到 Meta，Meta 还有一位产品领导者。他其实是我之前的嘉宾，而且那一期也是最受欢迎的节目之一——Nikhyl Singhal。他和很多公司的 CPO 和产品负责人合作。他的观察是，过去几年里 PM 角色正在经历一次重启，因为某个时代的终结。他的看法是，过去十年里，PM 主要承担的是增长职责——他们在增长已有的产品，已经有了产品市场契合度（或者自认为有了），然后就是优化、扩展。而现在资金不再充裕了，大家又回到了构建、寻找产品市场契合度验证和发现的轨道上。我想知道你是否也看到了这个趋势？在过去几年里，你是否观察到 PM 应该做的事情发生了变化？

Marty Cagan： 可以说是也可以说不是。我认为他大体上是对的，但有一个非常重要的细微差别。很多还不够成熟的团队，做的正是他所描述的事情。他称之为 growth hacking，我称之为优化。他们做的只是那些低风险的简单实验。他们活在 AB 测试的世界里，比如”我们把这个行动号召按钮改一下，也许会有更多人注册”——就是这种测试。他们应该做这些吗？当然应该。但这算真正的产品工作吗？不算。那不是发现，那是优化。在很多公司里，他们做这些是因为拿到了一个全是功能的路线图，所以能塞进去的只有这些小优化测试。但在另一些公司里，是他们害怕做别的。他们真的不想搞坏什么东西。所以我觉得他描述的那种情况在很多需要转型的公司里确实存在。

我认为他看到的大多是正在学习从功能团队转型为产品团队的团队。那这种情况在过去两年是否更多了？我愿意这么相信，但我不确定。有些时候我觉得他说的对，有些时候我觉得不知道他在跟谁聊，因为那些人仍然困在优化工作上。这里面可能有很多细微差别。总的来说，我认为他说的没错，但我不认为这跟利率有关。我认为更多是跟领导力的质量有关，以及业务需要做比优化更多的事情。

PM 角色正在发生的大变化

Lenny： 我知道人们总问你这个问题，但我还是很好奇，你是否看到 PM 角色正在发生什么重大的变化？

Marty Cagan： 我们已经讨论了不少正在改变的重大动态。有意思的是，我们真正讨论的其实是 PM 角色的不同定义。如果我们把其中一个定义固定下来——比如说我们现在关注的是赋能型产品经理，就是你和我成长过程中接触的那种，他们对价值和可行性负责——总的来说，我认为原则是稳定的，而且会持续稳定。然而，具体技术正在经历一些根本性的变化，尤其是生成式 AI 的出现。别误会，我跟大家一样每天都在亲身经历这些。我还没有搞明白。事实上，我最近改变了我的建议，因为我以前会说，先用 ChatGPT 生成一个起点，然后在这个基础上优化。

但我不断看到的是，人们把 ChatGPT 给出的结果太当真了，太当回事了，赋予了太多价值，然后朝着错误的方向跑偏，还在那上面做优化。现在的情况很复杂，是一个不断变化的目标。你用哪个系统、今天是星期几，都会影响结果。总之，我现在给人们的建议是，先自己把答案想清楚。真的让他们去思考，把自己的想法写下来，然后再用 ChatGPT 看看能不能改进，能不能挑战自己的想法，能不能让论证更严密。所以我反转了我的建议，因为人们过于信任那些结果了。

Lenny： 你说的他们用什么开始，是指像”这是我在考虑的产品战略”这种，还是像 PRD 之类的？

Marty Cagan： 对，你当然可以用它来写 spec、PRD，当然也可以用来做战略，甚至用来给 bug 分类排序。很难想到有什么是用不了它的。但更难的问题是，它到底擅长什么？

AI 将如何颠覆 PM 的技能

Lenny： 我正想聊类似的话题。我一直在思考一个问题，也想写一篇文章，就是：产品经理的哪些技能最会被 AI 颠覆？我觉得短期内，沟通能力在提升——你可以改善你的写作和战略表达，比如”这是我的战略，给我一些反馈”。所以我觉得很多事情正在通过 ChatGPT 这类工具被优化。但放眼五到十年，有没有哪些技能可能会消失，或者 95% 都由 AI 完成？如果是的话，你认为最大的变化会发生在哪些技能上？

Marty Cagan： 绝对会。我认为这现在更多发生在工程端，设计端也是，但我完全预期它会继续发展。就像我一开始说的，我不知道具体时间——时机这个问题很难回答——但这也是我为什么跟人们说要提升自己技能的另一个原因。如果你本质上是一个 backlog 管理员，那就祝你好运了，因为已经有人在用 AI 做这些了。这只是一个时间问题，这些工作很快就会被很好地支持。那不是一个好的职业前景。然后我们再看看功能团队的项目经理，里面真正有附加值的东西很少。大部分都是行政类事务，至少可以借助 AI 大幅完成。所以如果我是功能团队的产品经理，我不会觉得自己能继续做这行很多年。

而对于赋能型产品经理，如果你的职责是价值和可行性——归结起来，这才是 ChatGPT 或 GenAI 留下的真正挑战——可行性变得更加重要。还有一些非常难的问题有待解决。所以设计师，我认为真正顶尖的产品设计师会变得极其重要，当然技术负责人也会比以往更加重要。但对于产品经理来说，特别是围绕可行性方面，我参加过很多这样的讨论，我们在讨论概率性软件与确定性软件的影响，以及什么是可以接受的。律师们已经在从法律角度介入了，还有伦理角度——以及如果这是关键任务场景，我们能接受一个概率性的答案吗？

我们不知道，还在摸索。那这本质是什么？这正是一个可行性和价值的问题。所以现在有更多责任明确地落在了产品经理身上，比过去一般情况要多得多。

Lenny： 你能谈谈可行性吗，让大家知道你说这个词是什么意思？用一句话定义一下可行性是什么？

Marty Cagan： 价值是对客户而言的，可行性是对你的业务而言的。也就是说，它对你的业务是行得通的——你能卖得出去，能推向市场，它是合法的，你能提供售后服务，符合合规要求——所有这些约束条件。回想一下 Airbnb，让人们注册并不难，难的是让房源在旧金山变得合法。那才是难的部分——合规层面。

关于《TRANSFORMED》这本书

Lenny： 我想谈谈你的新书。在进入这本书的话题之前，关于这些内容还有什么你觉得有趣、值得聊一聊的吗？

Marty Cagan： 差不多了吧。我们聊了很多，真的很多。

Lenny： 确实。我想我们已经涉及了你书中的一些要点，不过还是来聊聊这本书吧。这是你的第三本书，对吗？

Marty Cagan： 是的。

Lenny： 好的。是什么促使你决定再写一本书，为 Marty Cagan 的作品系列再添一部？这本书讲的是什么？

Marty Cagan： 不过这本不一样，是另一种类型。因为《INSPIRED》——希望大家知道——是写给产品团队和产品经理的，本质上是一本关于产品发现的书。而《EMPOWERED》则是关于产品领导力的——愿景、战略、团队拓扑、教练辅导，都是这些内容。这本来就是最初的设想：我们会分享这些方法，因为这就是我们所做的。但说实话，从《INSPIRED》第一版开始，我们被问到最多的一个问题是，人们读了这本书后会说，我非常喜欢这本书，我想这么做。但你见过我们公司吗？我们离那种状态差得太远了，简直是天壤之别。实际上很多人会直截了当地告诉我，他们公司根本不可能接受这种方式。所以他们问的是，到底怎样才能转型成那样工作？

为什么要写关于转型的书

这个问题我们被问了很多年。这也是我的合伙人 Christian、Jonathan、Christopher、Leah 所做的事——帮助企业转型，这就是我们一直在做的。但我们是一次一家地做，总共就我们五个人，能服务多少家公司呢？所以我们意识到这是一个全球性的问题。如果我们写了书来解释”也许你想这样工作”，却不解答”如何转变到这种工作方式”，那就把最难的部分留给人们去面对了。所以《TRANSFORMED》不同于其他书，目的是分享如何真正实现改变。《TRANSFORMED》里也有方法技巧，但都是转型方法论——变革的方法，比如使用试点团队，或者通过分而治之的方式来推进转型工作。

还有一点我们想做的——实际上我们给自己定了一条规矩。我们知道需要大量案例和实例，但我们也说，把硅谷公司拿来做例子太容易了。因为 Airbnb 从诞生就是这个模式，他们虽然背景是设计师，但终究是一家硅谷公司。这对 Airbnb 来说是巨大优势，相比之下，你随便挑一家银行，它们就不是在这种工作方式中诞生的。所以我们决定所有案例都来自硅谷之外，全部都是——其中大多数还是互联网时代之前的公司——那些不得不进行剧烈转型才能适应这种工作方式的公司。而且我们不仅要展示它们如何转型，还要展示转型后它们能做到什么。对我来说这是最精彩的部分——看到它们的创新。Lenny，说实话，其中一些创新和我在 Amazon 看到的任何东西一样令人印象深刻，这可不是随便说说的。

硅谷之外的转型案例

在我看来 Amazon 是顶尖中的顶尖。所以英国 Trainline 能做到的事情同样令人赞叹。还有一家公司，几年前我才第一次知道，在沙特阿拉伯，叫 Almosafer，是一家旅行社。他们占据了——我忘了具体数字——80% 以上的市场份额，超过 Expedia，超过美国那些巨头，因为他们真正学会了这些东西并付诸实践。我们有十几个来自世界各地的案例——巴西、弗吉尼亚，到处都是，不是硅谷。覆盖医疗、汽车销售、健身等各个行业。说实话，有几个原因。一是我们想让人们理解转型到这种工作方式到底意味着什么，不加粉饰，就是真实意味着什么。否则，如果他们连”那里”是什么样都不知道，怎么可能到达那里？二是我们想让他们相信转型是可能的。我们是最先说”这不容易”的人，但我们想让他们相信这是可能的。第三，我们想让他们对转型后能做到的事情感到兴奋。这就是我们在书里想做的三件事。所以这本书和其他书不同，但希望它能让其他书变得更易落地，读者能更多地应用它们。

Lenny： 你觉得这本书最适合谁读？是公司的领导者？还是 IC 产品经理，所有人？你觉得谁最能从中受益？

Marty Cagan： 这本书我们是有意为之的，同样不同于其他书。其他书是写给我们这样的人——你的听众、我的读者——产品人的。而这本也写给非产品人。所以 CEO、CFO、销售负责人，任何关心公司如何构建产品并希望推动变革的人，这本书就是为他们写的。这其实是写作中最难的部分之一——要纳入这类读者做评审，确保所有内容对他们来说是说得通的。

Lenny： 所以基本上，如果你正在听这个播客，心里想的是”我就处在 Marty 描述的那种团队里，我觉得这不是最优的，我们可以做得好得多，我们的功能团队可以做得更好”——那基本上就是把这本书递给你的 CEO？

Marty Cagan： 而且我建议他们自己也先读一遍，这样他们自己心里有数。因为我知道接下来我会更多地谈论这个话题，因为我觉得我需要这么做。我们行业里有太多人把自己看作公司的受害者——困在一个功能团队里，除了辞职什么也做不了。但他们要养家，不会辞职的。但我觉得并不是这样的，我觉得他们能做的事情其实非常多，希望他们能在书中看到这一点。他们能看到自己作为个人可以怎样推动公司朝这个方向发展，退一步说，至少这对他们的职业发展也有帮助。

产品运营模型

Lenny： 我一直很喜欢你传达的那种赋能和激励的信息——你其实是可以推动变革的，你并没有被困在这种工作方式中，我知道你一直在倡导这一点。这本书的正式书名是《TRANSFORMED: Moving to the Product Operating Model》。你说的……来了，我这边还没有样书，因为美国还没上市，不然我会把它放在手边。就是这个，绿色封面很漂亮，和之前几本的配色很搭配。太棒了，设计得真好看，不管是谁做的。好的，书名中有一部分是”Moving to the Product Operating Model”（迈向产品运营模型）。这是什么意思？

Marty Cagan： 这是写这本书最大的痛点所在。因为说实话，这个问题我回避了二十年。如果你看我开始写这本书之前的任何文章，我只是说，“你到底是想学最好的公司那样工作，还是和其他公司一样？“我们就是这样描述的——“最好的”与”其他的”——因为没有一个词、一个名称能够概括所有最优秀公司所共有的那些原则。所以我们只会说，你想不想像最优秀的那样工作？但当我开始写书的时候，我想，好吧，我不能只说”像最优秀的那样工作”，总得给这个东西一个名字。不过 Lenny，我不知道你是否也遇到过这种情况，能不发明新术语就尽量不要发明。

产品运营模型（续）

Marty Cagan： 要创造一个新术语真的很痛苦。我们合作过的一些公司使用”产品运营模型”（product operating model）这个说法。别误会，这并不是唯一的叫法。有些人用”产品主导型公司”（product led company）或”产品驱动型公司”（product driven company），但这两种说法我们都不喜欢，因为它传递了完全错误的信息，会让公司其他部门觉得这是在争权。所以我们想避开这些词。我们喜欢”产品运营模型”有几个原因。首先，它是一个模型，一个概念模型。它不是一个流程，也不是一个具体的东西，更像是一套原则。而且它对很多人来说不具有威胁性，它只是在说，“看，这些公司就是这么运营的。你可以自己看看，判断一下它是否也适合你。“所以我们采用了这个术语，简称”产品模型”。归根结底，它就是一套 20 条原则，这 20 条原则就是我们所发现的。

还记得我们一开始就说到的吗？我之前解释过，当我听你的嘉宾分享时，我在听他们各自公司有什么特别之处，但我真正在寻找的是共性。因为大多数时候，当我看到一家成功的公司，他们都在践行这些原则。比如你必须做实验，你必须拥抱实验精神。如果你不这么做，这里面大部分事情都不可能实现。或者你必须确保你发布的每一样东西都做了埋点监测，这样我们才能证明成果。诸如此类。方法、框架、工具、流程有千千万万，但真正重要的是那些原则。这就是我们所说的产品运营模型的含义。从高层级来说，我们谈论的是：你如何决定要做什么工作？你如何决定要解决哪些问题？

产品战略与产品模型的三大维度

这就是大多数公司在年度规划中做的事情，但本质上它就是产品战略。你的 Meta 那位朋友描述的就是领导者们在做的事情，那就是他们的职责。第二个维度是：他们如何解决问题？他们是否具备像我们讨论的那样的产品发现能力？如何真正想出既服务客户又服务企业的优质解决方案。这是产品模型的第二个大维度。第三个大维度是：他们如何实际构建、测试和部署产品并交付给客户？他们的做法是否可靠，是否可验证——你能证明这产生了所需的成果？这就是三个大的方面。然后还有一系列能力。其中有四项大多数公司不具备的新能力，但棘手的地方在于，他们有挂着这些头衔的人，却没有真正在履行这些职责的人。我们一直在讨论的就是产品经理。

Lenny： 最值得分享的是什么？你刚才提到强大的产品团队有 20 个特征。

Marty Cagan： 20 条原则。

Lenny： 20 条原则。我特别好奇这些原则都是什么，但我知道我们没有时间一一展开。你能分享其中几条吗？你刚才提到了实验精神是其中一条，或者分享一下你刚提到的这四项能力。我就是很好奇这些……

Marty Cagan： 好吧，你想听多少我就能分享多少。四项能力分别是产品经理——再说一遍，我们说的是真正的产品经理，不是产品负责人，不是功能团队的产品经理。产品经理；真正的产品设计师——包括服务设计、交互设计、视觉设计、用户研究，真正的产品设计师；真正的技术负责人；然后是真正的产品领导者——管理产品、设计、工程的管理者，知道如何辅导自己的团队，知道如何制定真正的产品战略，就是我们刚才讨论的那个。所以这就是四项新能力。对大多数公司来说，这些是新的，意思是他们可能有顶着这些头衔的人，但这些角色并没有被真正制度化。

Lenny： 很有意思，你是在经典的三人组基础上加上了上面的领导者。就像一个凳子上放了什么东西，或者说把凳子填满了。

Marty Cagan： 那就是三人组，这个词就是这么来的。“三人组”（triad）这个词就是指那三个角色。这不是我们发明的。

Lenny： 对。但我认为产品领导者的加入非常值得关注。你不能只是把团队放在一边，却没有产品领导者来统筹这些工作。

Marty Cagan： 这确实如此，因为在写《INSPIRED》的过程中我真正学到了一点：光让团队各尽其职还不够，他们还需要领导层各尽其职。两者缺一不可。这就是为什么我说我们不把它界定为自上而下或自下而上。我们界定的是每个群体各司其职。当这种情况发生时，其实是一件非常美好的事情。

Lenny： 我们会附上你写的那篇文章《Product Leadership Theater》的链接，里面讲了人们是怎么做错的，假装在做和真正做对分别是什么样子。

Marty Cagan： 好。

Lenny： 好。那这些原则有哪些？简单聊几条——

20 条原则

Marty Cagan： 随时叫停我就行。有一组原则偏向文化层面的，比如：创新比可预测性更重要。这是一条原则。学习比失败更重要。原则比流程更重要。诸如此类的例子。在团队方面，赋能型团队被赋予待解决的问题。这是你的基础原则之一。我们讨论过这个，就是真正的所有权、真正的归属感，让团队觉得这就是他们的事情。当然，在产品发现方面你会认出所有的原则——要解决产品风险，要拥抱快速实验，要负责任地测试想法。这些都是原则。然后我确实提到了几条交付层面的原则，比如小批量、高频次、解耦的发布。对大多数公司来说就是 CI/CD，所有东西都做埋点监测，所有东西都做监控。这些是交付原则。所以这些都不应该让你感到意外，因为它们正是我们所了解的优秀公司中一致存在的东西，但我们认为这些才是真正重要的。

Lenny： 太棒了。我想听到这段的人，如果他们属于你描述的那 10% 到 20% 做得好的公司，一定会说”当然如此”。然后其余的人会说”不可能，我们做不到”。

Marty Cagan： 你要意识到，在世界上大多数其他地方，他们是按月甚至按季度发布的。想想看，季度发布。想一想，你根本没法好好照顾客户，你也无法以所需的速度学习。顺便说一句，那种模式下质量也会很糟糕。

Lenny： 我不一定要跑这个题，但我知道在某些情况下，比如季度发布，Shopify 就是一个例子，他们有季节性发布，像冬季发布和夏季发布。

Marty Cagan： salesforce.com 也有大型发布。但不要把团队的实际发布和市场发布混为一谈。所以批量发布是非常正常的，而且我认为是明智的。因为你看，大多数产品团队每天大概发布 20 次。你要每天做 20 次市场发布吗？那毫无意义。所以定期集中进行信息发布是合理的，但在优秀公司里，到他们对外发布消息的时候，功能已经上线了。它一直在持续推出。我们可能以暗发布的方式上线了一些东西，正如你所知，但它已经在生产环境中稳定运行了。我们可能通过 A/B 测试验证了每一个功能。

产品运营

Lenny： Airbnb 其实也是同样的模式。他们每年几次对外宣布的大部分东西，对大多数人来说已经上线了或者已经在实验中了。有一点我想澄清一下，你把这个叫做产品运营模式（product operating model）。另外还有一个角色叫产品运营（product ops），你之前稍微提到过。你对产品运营有什么看法？我们这里有过几位嘉宾聊过这个话题。

Marty Cagan： 这个比较棘手。首先，有些人问我，产品运营是不是就是产品运营模式？不是。那只是一个很不巧的名称冲突而已。产品运营更类似于 DevOps 和 design ops，仅此而已。那么，你能在产品运营模式中使用产品运营吗？当然可以，前提是你采用的是该模式中所包含的那些定义。举个例子，在我所了解的优秀公司中，产品运营的核心是用户研究人员和数据分析师，唯一的区别是他们现在被统一归到一个产品运营负责人下面。就是这样。这有什么新鲜的呢，Lenny？已经超过 20 年了。公司一直都有用户研究团队和数据分析团队，分别在定性和定量层面帮助你做决策。所以这并不是什么新东西，但它的确是好的。我认为把这些整合起来是有一定价值的。

当然，有些公司对产品运营的解读和定义截然不同。不幸的是，很多公司把它理解为流程治理方面的东西。那是一个巨大的红旗，我会告诉人们，如果你看到的是那种情况，赶紧跑。还有一件在很多公司里发生的事，让我感到惊讶的是，公司在想方设法寻找理由来给产品经理配助手方面竟然如此有创造力，因为产品经理说工作量太大了。这在我看来非常讽刺，因为他们通常还是功能团队，我就会想，“你现有的工作本身都还不够充实呢。“但不管怎样，他们说，“工作量太大了。“然后就说，“我们需要帮助。“所以有一阵子，他们都会配一些 associate product manager。后来很多公司又有了一种做法，我们还配了产品负责人。

产品经理加产品负责人，这完全说不通。巨大的反面模式。如今很多公司用同样的借口，但变成了产品经理配有产品运营人员来做脏活累活。不行。说实话，我也不想当那些人中的一员，因为我认为他们现在的处境非常脆弱。

Lenny： 我对产品运营改变了看法。一个原因是，我以前也觉得，“我不需要在每件事上都多一个人参与。我只想要……”我也不知道为什么要那样做，尽管我有做不完的工作、工作到疯狂加班的地步。但我觉得我接触到的那些产品运营人员有一个很大的优点，就是他们人数不多。你通常只需要一个，能做大量的事，帮助很多不同的团队，所以它不会变成一个疯狂膨胀的团队。

Marty Cagan： 这正是我喜欢的。用户研究也一样，顺便说一句，你之前有一位很好的嘉宾也试图说明这一点——一个规模小但杠杆效应高的团队。这对数据分析师适用，对用户研究也适用，他们帮助各团队完成需要做的工作。但关键在于他们到底在做什么。我告诉你，我见过太多公司，产品领导者没有做好自己的工作，于是他们就雇产品运营来替他们做。结果变成由产品运营来负责培训产品经理。这真的很不好。

创业公司何时需要产品经理

Lenny： 在进入非常精彩的闪电问答之前，我还有几个问题。实际上，也许就再一个问题。看情况再说。我之前提到过，很多创业公司的创始人会说，“我根本不需要产品经理。我永远不会招他们。或者等我有了几百个工程师再说。“但后来我发现他们中很多人改变了想法，招了一个 PM，然后说，“哇，这太棒了。我怎么没早点这样做？这个人正是我需要的。“这些是我请到播客上的嘉宾，他们原本说”我们不需要 PM”，等真正有了一个之后就说，“好吧，我明白了。这很好。“对于那些目前处于”我不想要产品经理，他们会把事情搞砸，会拖慢进度”这种心态的创始人，你有什么建议吗？

Marty Cagan： 嗯，首先，我也是那些劝他们不要太早招产品经理的人之一，因为很多人确实犯了一个错误，就是招得太早了。另外要明白我们在这里讨论的——我们整个对话的又一个层面——我说的都是一个真正的产品经理。如果他们把产品经理当项目经理用——很多时候确实如此——那我会告诉他们，你在花冤枉钱，但好吧，你可以在项目管理方面获得一些帮助。毕竟那不应该是 CEO 花时间做的事。但如果是一个真正的产品经理，关注的是价值和可行性，那就是创始人自己的工作。创始人应该亲自做这件事，也需要亲自做这件事，如果太早引入一个真正的产品经理，通常会产生冲突。厨房里厨师太多了。

你需要达到一定规模之后，让其他人来负责价值和可行性才会有帮助。这整个前提是他们理解什么是真正的产品管理，否则会导致完全不同的症状。

Lenny： 所以我觉得这里的一个建议是，在达到产品市场契合度之后，是招产品经理的更好时机。否则他们就是横在你和产品之间的障碍，会让一切变慢，对吧？

Marty Cagan： 对。不过要记住，通常你一达到产品市场契合度，就在为其他产品和其他市场做同样的事了，所以这是一个持续的过程。但在规模还小的时候，通常最有效的参考指标是工程师人数。到了一定数量的工程师，通常是 20 到 25 人，如果联合创始人来担任产品角色，效果会好得多。

Lenny： 太好了。我本来想问你有没有关于工程师人数的经验法则，谢谢你先回答了。这基本上就是我想聊的全部了，Marty。在进入非常精彩的闪电问答之前，你还有什么觉得有趣想分享的或者想留给听众的吗？

Marty Cagan： 说实话，Lenny，我们聊了这么多大话题。我有点担心这会让人们感到信息过载，希望不会。因为你挑的都是最难的话题。

Lenny： 好吧，干得漂亮。你也干得漂亮。话不多说，我们进入非常精彩的闪电问答。准备好了吗？

Marty Cagan： 好的。

闪电问答

Lenny： 你最常向别人推荐的两三本书是什么？

Marty Cagan： 我很喜欢 Tony Fadell 的新书《Build》。这本书非常精彩，他描述的也是产品模式，但是针对硬件设备的，他的视角非常棒。他近距离参与了一些世界上最具标志性的产品的创造——iPod、iPhone、Nest 设备。我非常喜欢，一直在向各种各样的人推荐这本书。另一本我很喜欢的是，你知道 Tim Urban 吗，Wait But Why 背后的那个人？

Lenny： 当然知道。

Marty Cagan： 我非常喜欢这个人的思维方式。他写了一本叫《What’s Our Problem?》的书，我觉得非常有启发性。从一百个不同的角度挑战了我，非常喜欢。

Lenny： 我一直在读他写那本书的过程，他写了很多年，完成那本书的经历本身也是一段很漫长的旅程。你最近有没有特别喜欢的电影或电视剧？

Lenny： 你问错人了，我几乎什么都不看，所以这个问题我帮不上忙。

Lenny： 哈哈，我觉得这往往是件好事。你有没有最喜欢的面试问题——无论是自己用的，还是觉得在面试产品经理时特别有用的？

Marty Cagan： 嗯，鉴于我面试了那么多人，我已经不再公开我最喜欢的问题了，因为它们已经被传到了网上。不过我确实有一个开场问题，几乎对每个人我都会先问这个：我想看看他们能不能定义清楚产品经理这份工作是什么。

Lenny： 你从回答中能看出什么？你在找什么？是看他们的回答有多接近你对产品经理的定义吗？

Marty Cagan： 从他们的回答中，我能看出他们是从哪里学来的，仅此而已。他们不一定要给出我的答案。他们只是不应该给出那种老式功能团队的答案，就这样。

Lenny： 你有没有最近发现并特别喜欢的产品？不管是软件还是实体的东西，家里用的什么的？

Marty Cagan： 我最近买了一辆 Rivian，他们做得真的非常漂亮。这家公司可以说是汽车界的 Airbnb，因为创始人是一位设计师，想象一下由一位设计师来打造下一代汽车会是什么样子。他们做得非常出色。

Lenny： 哇，我刚才还在想你是说可以租别人的车，那听起来也挺酷的，但你的意思不一样。有意思的是，你和 Meta 的 [inaudible] 都把车作为最近最喜欢的发现。他选的是梅赛德斯-奔驰。我还开玩笑说我希望有一天能送出这些产品，结果把这些车算进去预算要爆了。

Marty Cagan： 我最喜欢的事情是骑摩托车。现在有一代新产品，说不定哪天能救我的命——就是那种无线安全气囊背心，穿在身上的，它使用 AI 技术和传感器来决定是否要弹出气囊。运气好的是，我的还从来没有触发过，但我知道对很多人来说确实救了命。这就是技术发挥作用的一个例子——没有这项技术的话，骑车是非常脆弱的……就算有了技术，依然很脆弱。

Lenny： 等等，你骑摩托车？

Marty Cagan： 骑的。

Lenny： 我完全不知道。你骑什么车？

Marty Cagan： 我有两辆，都是宝马的。

Lenny： 哇，我们得在哪看到照片才行。太厉害了，我完全不知道。最后两个问题。你有没有最喜欢的人生座右铭，经常回想起来的，会跟朋友或家人分享的，在工作或生活中觉得有用的？

写作与思考

Marty Cagan： 我其实没有什么人生座右铭，但我确实有一个经常跟人分享的想法。正如你可能想象的，我觉得写作真的帮助我思考，我也鼓励其他人发展自己的思考能力。Leslie Lamport 有一句很棒的话——这个人嘛……你可能年纪不够大不太知道，他发明了最早的文字处理软件之一，叫 LaTeX，我以前就用过。他的那句话是：如果你只是在思考而没有写下来，那你只是以为自己正在思考。

Lenny： 这句话有一个版本我也很喜欢，意思是类似的——我不知道自己是怎么想的，直到我把它写下来。我记得是 Joan Didion 说的。

Marty Cagan： 同一个意思。

Lenny： 我深有同感。这就是我开始写作的原因。我就是想弄清楚自己脑子里在想什么。把东西结晶成清晰的表述。最后一个问题。你做这行已经很多很多年了。你做了多少年了？

Marty Cagan： 43年。

Lenny： 43年。如果当初没有走上这条路，你现在会在做什么？

Marty Cagan： 哦，说实话，我会很乐意一直留在工程领域。我一直也很喜欢设计。我觉得做设计师我也会很快乐。不过不管怎样，我还是会一直在建造什么东西——不管是房子、汽车还是别的什么。我喜欢建造东西。

Lenny： 我喜欢这个回答。在这个梦想中，你本质上就是一个一人版的三人组。Marty，这次对话太精彩了，完全达到了我的期望。我们聊了好多内容。我觉得能帮助到很多人去实现转变。最后两个问题——大家在哪里能找到你的书？什么时候上市？如果想跟进的话去哪里找你？听众怎样能帮到你？

Marty Cagan： 这本书应该会在 3 月 12 日在全球发售，包括电子版、Kindle 版、有声版和精装版。希望如此，至少出版社是这么承诺的。关于我谈到的所有内容，我们所有的资料都在网站上免费提供，svpg.com，硅谷产品集团。如果你还不认识我们至少一位合伙人，你应该试着去认识一下。我们都喜欢跟社区交流，我觉得你会喜欢的。希望这些信息有用。

Lenny： 我们已经请过两位合伙人了，以后会慢慢把其他合伙人也请来。我想确保你回答最后一个问题——听众怎样能帮到你？

Marty Cagan： 说实话，我们写很多东西的灵感都来自于人们的问题。所以当有人读了我们的文章觉得有用，然后告诉我们，我们当然很高兴。但如果他们有后续问题，我们也同样欢迎——在线档案的一个好处就是我们可以直接去更新文章来回应这些问题。所以我们很欢迎这样做。

Lenny： 你也是这么做的。

Marty Cagan： 所以尽管问。

Lenny： 好的。太棒了。Marty，非常感谢你抽出时间来做这期节目，感谢你的到来。

Marty Cagan： 谢谢你，Lenny。

Lenny： 大家再见。非常感谢收听。如果你觉得这期节目有价值，可以在 Apple Podcasts、Spotify 或你最喜欢的播客应用上订阅。另外，也请考虑给我们评分或留下评论，这真的能帮助其他听众找到这个播客。你可以在 lennyspodcast.com 找到所有往期节目或了解更多关于这个节目的信息。下期再见。

术语表

原文中文
A/B testA/B 测试
agile coach敏捷教练
Airbnb of car companies汽车界的 Airbnb
anti-pattern反面模式
associate product manager助理产品经理
backlogbacklog（敏捷开发中的待办事项列表，保留原文）
Ben ErezBen Erez（产品经理，保留原名）
bottom-up自下而上
Brian CheskyBrian Chesky（Airbnb 联合创始人兼 CEO，国际知名人物但中文语境下通常保留原名）
business analyst业务分析师
buyer beware买者自负
ChristianChristian（Marty Cagan 的同事，保留原名）
CI/CDCI/CD（持续集成/持续部署）
Continuous Discovery HabitsContinuous Discovery Habits（书名，保留原文）
CPOCPO（Chief Product Officer，首席产品官）
critical thinking批判性思考
CSPOCSPO（Certified Scrum Product Owner，认证 Scrum 产品负责人）
dark release暗发布
delivery team交付团队
design by committee委员会式设计
deterministic software确定性软件
empowered赋能型
Epic WasteEpic Waste（Marty Cagan 文章标题，保留原文）
feature factory功能工厂
feature team功能团队
GenAIGenAI（生成式 AI）
go-to-market推向市场
growth hackinggrowth hacking（增长黑客，一种以数据驱动的用户增长方法论）
individual contributor个人贡献者
instrumentation埋点监测
Joan DidionJoan Didion（美国著名作家、记者，保留原名）
LennyLenny（播客主持人）
Leslie LamportLeslie Lamport（计算机科学家，LaTeX 的发明者之一，图灵奖得主，保留原名）
Nikhyl SinghalNikhyl Singhal（Meta 产品领导者，保留原名）
NVIDIANVIDIA
output vs outcome产出 vs 成果
PRDPRD（Product Requirements Document，产品需求文档）
probabilistic software概率性软件
product designer产品设计师
product leadership theater产品领导力剧场
Product management theater产品管理剧场
product market fit产品市场契合度
product ops产品运营
product owner产品负责人
product strategy产品战略
PSPOPSPO（Professional Scrum Product Owner，专业 Scrum 产品负责人）
RivianRivian（美国电动汽车制造商，保留原名）
SAFeSAFe（Scaled Agile Framework，大规模敏捷框架，通常保留英文）
salesforce.comsalesforce.com
Scrum MasterScrum Master（Scrum 框架中的角色，通常保留英文）
Shreyas DoshiShreyas Doshi（产品领域知名顾问/前 Stripe 产品经理，保留原名）
Silicon Valley Product Group硅谷产品集团
specspec（规格说明文档）
tech lead技术负责人
Teresa TorresTeresa Torres（产品发现领域知名作者/顾问，保留原名）
Tim UrbanTim Urban（Wait But Why 博客作者，保留原名）
time to markettime to market
time to moneytime to money
Tony FadellTony Fadell（iPod、iPhone、Nest 等产品的核心设计者之一，保留原名）
top-down自上而下
triad三人组（产品经理、产品设计师、技术负责人的核心组合）
Wait But WhyWait But Why（知名博客，保留原名）

此文档由 AI 分片翻译（translate_long_document）