流程人的通病 | Marty Cagan

Marty Cagan 2.0 2023-02-06

流程人的通病 | Marty Cagan

疫情期间的过度招聘

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

Lenny： 这本质上就是你所说的”戏剧化表演”，那些并不是真正的产品经理。

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

关于《TRANSFORMED》

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

Marty Cagan： 我们行业里有太多人把自己视为公司的受害者，好像被困在功能团队里无能为力，除了辞职别无选择。我认为这不是真的。他们能做的事情太多了。

节目介绍

Lenny： 今天的嘉宾是 Marty Cagan。Marty 在过去 20 多年里一直帮助产品团队和产品经理提升专业能力、改进流程和发展职业。他合作过的产品团队和产品经理比世上任何人都多。他还撰写了产品管理领域最受欢迎的两本书——《INSPIRED》和《EMPOWERED》，而本周他将发布最新著作《TRANSFORMED》。在本次对话中，我们讨论了一些辛辣且重要的话题：产品管理领域的发展方向，产品经理及相邻职能的过度招聘，他注意到的一种趋势——产品管理戏剧化表演（product management theater）。此外，为什么你在网上找到的大多数产品管理建议都是错误的，以及为什么会这样。为什么许多产品经理实际上只是项目经理，以及如何避免成为那样的人，还有如何避免招聘到那样的人。你需要培养哪些技能才能成为一名出色的产品经理，尤其是在 AI 时代。

如何让你的团队和公司转向更有自主权的工作模式。判断你所在的是功能团队的迹象，以及为什么你可能不想待在那里，还有更多内容。如果你关心产品管理领域及其未来走向，你一定会喜欢这一期。接下来，在简短的赞助商广告之后，我为你请出 Marty Cagan。

[广告已跳过]

回归与”辛辣”写作

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

Marty Cagan： 非常感谢，Lenny。谢谢你邀请我回来。

Lenny： 谢谢你再次做客。我们上次一起做的那期节目至今仍是我整个播客中最受欢迎的前五之一，这挺不可思议的，因为当时播客的规模比现在小得多。你还出了一本新书，我们会谈到。你最近的写作也变得越来越”辛辣”了。你写了产品管理戏剧化表演、产品领导力戏剧化表演等等。所以我迫不及待想深入探讨这些问题。我想先问问，是什么驱动了你最近写作中的这种辛辣风格？

Marty Cagan： 这是有意为之的。我发现自己——我也意识到自己——在逐步调高关于这些话题的措辞力度。说实话，这些话我其实已经说了很久了，而且都有记录可查。你可以去读十年前、二十年前的博客文章。但形势正在变化。首先，我应该说——我不知道你是不是这样，Lenny——但大多数像我这样的产品人都有一种危机感。所以我们总是在担心有什么东西会来抢走我们的客户、颠覆我们的产品。我知道自己也有这种心理。我一直在关注哪些因素可能真正在好的方面或坏的方面引发剧变。有些事情我长期以来一直非常担忧，我认为现在多种因素正在同时汇聚，而其中一个挑战在于——它们是同时发生的。

所以有若干事情正在并行发生，这是混乱和大量恐惧的温床。在产品社区、设计社区、工程社区，这种情绪都弥漫其中，你能感受到。和你一样，我几乎每天都在和人们交流。所以我确实对为什么会发生这些、人们怎样才能最好地保护自己、自己的职业和公司有很多思考。我很乐意分享这些看法，但这不是一个小话题，不是一个小的因素集合。不过在我展开之前，我觉得大家应该了解我的出发点，以及它和你的出发点有何不同，因为这个视角……说清楚，我认为我们都在试图帮助产品社区，但我们试图以非常不同的方式来做这件事。

SVPG 与 Lenny’s Newsletter 的不同定位

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，而他们已经有足够多的人可以胜任。而且，很多时候工程师或设计师会说：“我们宁愿自己来做，也不想跟这个自以为是、想当所有人的老板、却又没有真正贡献任何价值的人打交道。“在我看来这才是真正发生的事情。他们要么是交付团队，要么是功能团队，通常在这种模式下是功能团队。

我不怪那些人觉得产品经理没有价值。他们确实没有带来那样的价值。公平地说，他们确实带来了一点价值，但——这话很残酷——相对于他们提供的价值来说，他们的薪酬严重过高。另一方面，在一个真正的产品团队里，那是一份非常不同的工作，我没有看到同样的情况。事实上，我认为你提到的那个抱怨是最大的线索，说明他们很可能就是功能团队。然后我会去问他们的工作方式，那个人在做什么……当然，我问产品经理的第一件事就是：你怎么定义你的工作？我猜你已经听过一百种含糊其辞、模棱两可的说法——“我负责促进协作""我做一些沟通工作""我负责把猫赶到一起”——我听着这些心想，天哪，我可不想在 CEO 面前替这份工作辩护。

功能团队与有自主权的产品团队

Lenny： 我知道你经常谈论团队和产品团队。我想很多人可能还没有百分之百确定你说这些的时候具体是什么意思。所以我们花点时间聊聊——当你在功能团队、功能工厂，和一个有自主权的产品团队，分别是什么样的？

Marty Cagan： 线索当然有很多。最简单的几个是：在功能团队里，你基本上会被给到一张产出的路线图。关键就在这里——是产出。换句话说，他们的功能就是项目，可能来自高管，可能来自大客户，可能来自任何地方。但就是一堆功能，你被要求去设计、构建、测试、部署这些功能。通常还会给你日期和时间节点。这就是功能团队。你负责交付。别误会，那也是工作，但那是产出。交付产出比交付成果要容易得多。而产品团队，有自主权的产品团队，他们不会被给到那样的功能路线图，而是被给到需要解决的问题。这些可能是客户问题，可能是业务问题，或者两者兼有，但他们被给到的是一个问题去解决。通常一个季度一到两个，当然还要加上每个人都在做的”维持运转”类的工作，但他们被给到的是真正的难题去解决，衡量标准不是”把东西上线”，而是”它是否解决了问题”。这就是为什么一家真正强大的产品公司与其它公司之间最大的区别在于——强大的产品公司理解一切都在于成果。你不会因为上线了什么而得分，你因为交付了价值而得分。

我交流过的很多 CEO 和 CFO，当我把它表述为”关键在于从立项到收益的时间，而不是从立项到上线的时间”时，他们最有共鸣。我们知道怎么做从立项到上线。如果你坚持要的是从立项到上线，我们知道怎么做。那些技术是众所周知的。更难的部分是从立项到收益，我知道那才是他们关心的，那确实更难，而那才是产品团队真正做的事。

真正的产品经理何时被需要

Marty Cagan： 只有当你对成果负责的时候，你才需要产品经理。我应该说，在硅谷的意义上，那就是你需要产品经理的时候。因为如果你被要求去解决这些问题，那意味着你必须想出一个解决方案，它不仅要可用和可行——那是功能团队做的事——还要有价值、商业上可行。而这意味着你需要一套你的工程师和设计师几乎从未具备的技能。这不是在贬低他们。那是非常不同的技能组合。所以你需要这样一个既深入理解客户又深入理解业务的人。这正是产品经理角色的由来。在一家优秀的产品公司里，这仍然是他们负责的事情。所以这是一个非常不同的工作。而且，如果一个人在扮演那种产品经理的角色，他几乎不可能还有闲工夫去对着设计师指手画脚，替他们画线框图，或者去烦开发人员。他们有自己的工作要做。

Lenny： 这本质上就是你所说的戏剧化表演，对吧——那些不是真正产品经理的人在做一些产品管理的活动。你能具体说说那是什么样的吗？

Marty Cagan： 最典型的例子就是，他们顶着产品经理的头衔——因为很大程度上整个世界，多亏了你，都知道这个头衔很酷——但他们并没有做这个角色的任何工作，也不具备任何相应的技能。当然，真正让我困扰的是，如果他们有动力的话，这并不难。对他们来说培养这些技能并不难，这就是我跟人们谈论的内容。你可以提升自己，让你真正能在这一层面上做出贡献。这是你为了自己的职业生涯应该做的事，而且顺便说一句，并非偶然的是，这也是你的公司需要你做的事。

价值与商业可行性

Lenny： 对于正在听这个节目、想知道自己需要培养哪些技能才能成为真正的产品经理的人——我记得你经常说，主要聚焦在价值和商业可行性上，这也是很多——

Marty Cagan： 价值和商业可行性就是产品经理负责的事情，就像工程师负责可行性一样——解决方案必须能够被构建和交付。而产品经理负责的是价值和商业可行性。另一种我喜欢的说法是：在一个真正有自主权的产品团队上，产品经理是创造者，不是协调者。每次有人告诉我”我的工作是说清为什么”的时候，我都会尴尬得不行。我就想，“那除了说清为什么所花的那十分钟，你这一周剩下的时间都在干嘛？“太荒谬了。但人们真的这么认为。不过你知道吗，在功能团队里，当你到处搜肠刮肚想给自己找个存在的理由时，出现这种情况也不太意外。但事实上，“为什么”本来是来自产品战略的。你连”为什么”都不是你定的。

产品经理是创造者，所以你要和设计、工程并肩创造，一起想出这些解决方案。现在，为了做好你的工作，代表价值和商业可行性，你需要一些真正的技能。首先，你必须真正成为你的用户和客户的专家。我知道我当年不被允许担任产品经理的角色，直到我亲自拜访了三十个客户——十五个在美国，十五个在欧洲。那只是当时指导我的人的规矩。我只知道那三十个客户改变了我的人生，因为我以为我了解我们的客户，但其实并不了解。另一个方面是你应该成为数据的专家。我们的产品如何被使用？使用方式如何随时间变化？如何被购买的？这很重要。还有一大块——你是团队中代表合规问题、销售问题、营销问题、财务成本问题、变现问题，以及整体上市策略的那个人。

产品经理的真正技能

所有这些都是法律约束。这都是产品经理的事。试想一下，如果团队里没有这个人，你又想让这个团队有自主决策权，你怎么办？靠拍脑袋吗？或者他们通常的做法是——叫上二十个利益相关方一起开会，试图决定这些事情，然后你就回到了委员会设计的模式。所以不行，产品经理需要把这些知识带到团队中。他们还需要对市场有深入的理解。所以当我向一个典型的 product owner 描述这些事情时，他们的反应是”我们完全不在同一个星球上”。他们在 CSPO 或 PSPO 课程里学的是如何在 Jira 里管理 backlog，这在我看来非常类似于学习如何操作 Google Docs。当然，那不是这个工作。那是我们每天做的事，但它不是这个工作，就像……

开发人员每天都在用 Jira。那意味着那就是他们的工作吗？当然不是。他们的工作是构建。所以这就是产品经理所贡献的。如果你把它看作一个光谱——product owner 是一个极端。说实话，那是交付流程中的一个角色。它根本不值得设一个专职人员，真的不值得。而且我认识的大多数团队里，资深工程师做那件事反而做得更好。光谱的另一端就是我们正在讨论的——有自主权的产品经理。而功能团队的产品经理则介于两者之间。他们做的比管理 backlog 多一些。他们做很多项目管理。别误会，项目管理很重要，但它不是产品管理。而且，在我见过的几乎所有配备功能团队产品经理的公司里，他们本来就有一大堆项目经理。

即将到来的清算

所以你可以听出我语气中有些无奈，因为我觉得这些道理长期以来已经相当清楚了，但大多数公司对此充耳不闻。他们不在乎。我对原因有一些理论，但那挺让人沮丧的。不管出于什么原因，我觉得我现在在提高音量，因为人们现在正在以艰难的方式看到这一点——因为很多公司在裁员，而这些角色很容易成为公司里最脆弱的人群。

Lenny： 让我实际上读一段你的原话，你正好谈到了这一点。你写道：“我多年来一直在警告，交付团队的 product owner 和功能团队的产品经理很可能面临一场清算，因为公司会意识到这些角色并不是他们以为的那样。据我所知，那场清算已经开始了，而且我预计 GenAI 只会让这个问题更加严峻。”

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

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

Lenny： 我猜很多人在想，我该怎么做？我知道你写过书，应该也有课程，还有各种资源。如果你能给人们几个建议，告诉他们如何在这一点上做得更好、应该聚焦哪些技能，你能分享一个简短的建议吗？

Marty Cagan： 这可能是我最感挫败的事情了。实际上，我之前应该在你问我是什么让我变得”辛辣”的时候回答这个问题——是什么把我推到了那个临界点。也许那天我心情不好，我不知道。但就是那篇在网上广为流传的文章，来自大概是产品经理领域最大的认证机构。他们发了一篇大文章，说”这就是产品经理做的事情。“配了一张大图，我看着它心想，我不敢相信他们居然把这个公开说了出来。这百分之百就是项目经理，百分之百。他们甚至都没有假装加一点产品的东西进去——大多数人当然比这更有创意，他们会稍微弯一下腰，让它看起来像产品经理，但这连边都沾不上。

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

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

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

社区的自我延续困境

Marty Cagan： 事实上，最让我感到挫败的事情之一就是社区。社区有很多优点……你有当今最大的社区之一，产品领域还有很多这样的社区、产品子社区。我喜欢它们的一点是，你遇到的几乎每个人都真心想要帮忙。真的是每个人。但问题是，有人发了一个问题——每天都会发生很多次——大多数出于好意的人就会跳出来，用他们在自己那家糟糕公司里学到的东西来回答。我看着这些对话，提问者说”非常感谢，现在我知道该怎么做了。“我心里想，“哦不，又毁了一个。“它变成了自我延续的。你能怎么办？难道有人要去监管这些成千上万的帖子，比如一个 Lenny 认证的人或 Marty 认证的人？我不想做这件事。你大概也不想做。

Lenny： 不想。

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

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

培养批判性思维

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

Lenny： 有意思。我确信你也遇到过这种情况，我就分享一个我想起来的事情。我在 Airbnb 工作的时候，读你的文章，心里想：“谁会这样工作啊？他说的那些公司，居然只是被给一张 roadmap 然后照着做。“我想：“不可能。这不是真的。他在写什么呢？“那是因为我在一家做事方式正确的公司工作——我知道你对后来的发展有不同看法。但不管怎样，所以我猜很多听这段话的人会想，我不相信大多数公司是这样运作的。你在说什么？然后我也猜，有相当比例的人在功能工厂工作，他们会说：不，挺好的。实际上不是你描述的那样。所以这对来说一定非常令人沮丧。

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

但我确实有过完全一样的对话。你刚才说的让我想起 Shreyas Doshi 第一次跟我说同样的话时的情景。他当时问我——因为他认识我——他说：“我知道你写这些东西，但我真的很难相信人们是这样做的。“我说：“Shreyas，我但愿那不是真的。“但他今天已经不再怀疑了。

Lenny： 对，因为他现在也在做很多这方面的工作。我很好奇，如果有人在功能团队里待着，觉得挺好的，一直待下去，这样可以吗？实际上今天 LinkedIn 上就有一位 PM 发了一篇帖子，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 和高管们决定我们在做什么、我们的战略是什么、我们的重大赌注是什么。所以在他看来，那比自下而上要自上而下得多，但表现出来可能像是自下而上。我知道自下而上和自上而下的区别，与功能工厂和有自主权的产品团队之间的区别是不同的。但我想听听你的看法？

Marty Cagan： 首先我想说，他描述的正是我在优秀产品公司中看到的，完全一致。但我们不把它定义为自上而下。自上而下其实意味着完全不同的东西。事实上，把一个 feature roadmap 交给团队，那才是非常自上而下的。还有一个非常普遍的误解——同样，很多敏捷教练误导了大量组织——产品团队不做产品战略。产品领导者做产品战略。他们需要做产品战略。说实话，我不是 Meta 最大的粉丝，但 Zuck 在产品方面非常厉害，非常厉害。这也是这个世界的问题所在——他太擅长了。但那就是他的工作——做出这些战略决策、聚焦决策、以及要下哪些赌注。然后在一个好的组织里，你把这些赌注交给团队，并且真正给予他们空间去找到解决方案。

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

PM 角色的演变

Lenny： 太好了，这个澄清非常到位。我觉得很多人并没有完全理解这一点，所以这番话对很多人来说确实很有帮助。说到 Meta，Meta 还有另一位产品领导者。他实际上是我之前的嘉宾，也是最受欢迎的一期节目的嘉宾——Nikhyl Singhal。他与很多公司的 CPO 和产品负责人合作。按照他的描述，他注意到过去几年 PM 角色正在经历一次重塑，因为那个（不可辨别）时代结束了。他的看法是，过去十年里，PM 主要承担的是增长相关的工作。他们在增长已有产品，产品已经找到了产品市场契合点，或者自认为找到了，然后就一直在优化、扩展。而现在资金退潮了，人们回归到真正去构建、去寻找产品市场契合点的验证和产品发现。我很好奇你是否也看到了这个趋势。在（不可辨别）之后的这几年里，你是否看到 PM 应该做的事情发生了转变？

Marty Cagan： 算是有也没有。我觉得他大体上是对的，但有一个非常重要的细微之处。很多还不够成熟的团队，做的正是他所描述的事情。他把它叫做增长黑客，我把它叫做优化。他们所做的就是那些低风险的简单实验。他们活在 AB 测试的背后，做的就是比如”我们改一下这里的行动号召按钮，也许会有更多人注册”这类测试。他们应该做这些吗？当然应该。这算是真正的产品工作吗？不算。那不是产品发现，那是优化。在很多公司里，他们之所以这样做，是因为上级给了他们一个全是功能的 roadmap，所以他们真正能塞进去的就只有这些小小的优化测试。但在另一些公司里，他们是不敢做别的。他们真的不想搞砸任何东西。所以我觉得他所描述的那种情况，在许多需要转型的公司里都存在。

所以我认为他看到的，主要可能是那些正在学习从功能团队向产品团队转变的团队。那这种情况在过去两年里是不是更多了？我愿意相信是这样，但我不确定。有些时候我觉得他说得对；有些时候我觉得我不知道他在跟谁聊天，因为那些人还在困在优化工作里。这里面可能有很多细微的差异。总的来说，我觉得是的，但我不认为这跟利率有关。我不认为跟那个有关。我认为更多是跟领导力的质量有关，以及业务需要做的不仅仅是优化。

PM 角色正在发生的大变化

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

Marty Cagan： 我们刚才聊了不少正在变化的大趋势。有趣的是，我们真正在讨论的其实是 PM 角色的不同定义。如果我们把其中一个定义固定下来——假设我们现在关注的是有自主权的产品经理，也就是你我成长过程中所了解的那种，他们的职责是保障价值和可行性。总的来说，我认为这些原则是稳定的，而且会持续稳定。不过，具体的技术方法正在经历一些激进的变化，尤其是在生成式 AI 方面。别误会，我每天都在亲历这些，我们大多数人都是。我还没有完全搞明白。事实上，我最近改变了我的建议，因为我过去常说，先从 ChatGPT 开始，从那里出发，然后我来帮你做好，我们从那里继续。

而我不断看到的情况是，人们把得到的结果太当真了，太当回事了，赋予了太大的价值，然后朝着错误的方向越走越远，还开始对那个方向进行优化。现在情况很复杂，这是一个不断移动的靶子。取决于你用的是什么系统、今天是星期几，你的状况都会不一样。不管怎样，我现在给人们的建议是，先自己把答案想清楚。真的让他们去思考，写下一些东西，然后再用 ChatGPT 看看能不能改进，看看能不能挑战自己的想法，看看能不能让你的论证更加严密。所以我改变了方向，我这样做是因为人们过于信任那些结果了。

Lenny： 你说他们一开始用它来做的那个东西，是指比如”这是我在考虑的这个产品的战略”之类的东西吗，还是说像 PRD 那种？

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

AI 将如何颠覆 PM 的技能

Lenny： 我正好想聊聊这个方向。我一直在思考一个问题，我想写一篇相关的文章——产品经理的哪些技能会被 AI 最大程度地颠覆？我觉得短期来看，沟通能力在提升。你可以改善你的写作和战略。比如”这是我的战略，给我一些反馈”。所以我觉得很多东西正在通过 ChatGPT 和类似工具被优化。但如果看五到十年，有没有哪些技能可能会消失，或者其中 95% 会被 AI 完成？如果是的话，你觉得这个变化主要体现在哪些技能上？

Marty Cagan： 绝对会。我认为这现在在工程端发生得更多，在设计端也一样，但我完全预期它会继续发生。就像我一开始说的，我真的不知道什么时候会发生，因为时间点是个很难回答的问题，但这也是我向人们论证为什么需要提升自己技能水平的另一个原因。如果你本质上是一个 backlog 管理员，祝你好运能保住这个职位，因为人们已经在用 AI 做这些了。这被 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： 你觉得这本书最适合谁读？是公司领导者，还是产品经理，还是所有人？你觉得谁能从中获益最多？

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： 这本书最大的难点就在这里……因为说实话，这个问题我回避了 20 年。如果你翻看我开始写这本书之前的任何文章，我只是说，“你想像最优秀的公司那样工作，还是像其他公司那样？“我们一直是这样称呼的——最优秀者与其他者——因为没有一个词、一个名称能够概括所有最优秀公司共同遵循的原则。所以我们只会说，你想不想像最优秀的公司那样工作？但当我开始写这本书的时候，我想，好吧，我不能只说”像最优秀的公司那样工作”，总得给这个东西起个名字。Lenny，不知道你有没有遇到过这种情况——如果可以避免的话，你不会想创造一个新术语。

产品运营模型的含义

Marty Cagan： 创造一个新术语真的很痛苦。我们合作的一些公司使用了”产品运营模型”（product operating model）这个说法。别误会，这不是唯一的叫法。有些人用”产品主导型公司”（product led company）或”产品驱动型公司”（product driven company），但这两个我们不太喜欢，因为它们传递了错误的信息，会让公司其他人觉得这是在抢权。所以我们想避开这些说法。我们喜欢”产品运营模型”有几个原因。首先，它是一个模型，一个概念模型。它不是一个流程。它不是什么具体的东西，更像是一套原则。而且它对很多人来说不具有威胁性。它只是在说，“看，这些公司就是这样运作的。你可以看看，然后决定你觉得它对你是否也适用。“所以我们采用了这个术语，简称”产品模型”。它的本质其实归结为 20 条原则，这 20 条原则就是我们发现的……还记得我们一开始就说过的吗？我解释过，当我听你的嘉宾分享时，我在寻找他们各自公司有什么特别之处，但我在寻找的是共性。因为大多数时候，当我看到一家成功的公司，他们都在践行这些原则。比如你必须做实验，你必须拥抱实验。如果你不这样做，大多数事情都不可能实现。或者你必须确保你发布的每一项功能都埋好数据监测，这样我们才能验证成果。类似这样的事情。市面上有无数种方法论、框架、工具和流程，但真正重要的是那些原则。这就是我们所说的产品运营模型。在高层次上，我们把它分为：你如何决定要做什么？你如何决定要解决哪些问题？这是大多数公司在年度规划中做的事情，但本质上这就是产品战略。你那位在 Meta 的朋友所描述的、领导者们做的事情，那就是他们的工作。第二个维度是他们如何解决问题？他们是否具备我们所说的产品发现能力？如何真正找到既对客户有效、也对业务有效的好的解决方案。这是产品模型的第二个大维度。第三个大维度是他们如何实际构建、测试并向客户部署产品？他们是否以可靠的方式来做，是否能够展示这确实产生了你需要的成果？这就是三个大的领域。

四项关键能力

然后还有一些能力要求。有四项大多数公司不具备的新能力，但棘手的是，他们有具备那些头衔的人，却没有真正做那些工作的人。我们一直在讨论的一个就是产品经理。

Lenny： 最有意思的分享什么？你说一个有自主权的产品团队有 20 个特征。

Marty Cagan： 20 条原则。

Lenny： 20 条原则。我很好奇这些原则是什么，但我知道我们没有时间全部过一遍。你能不能分享其中几条？你已经提到了实验作为其中一条，或者你刚刚提到的这四项能力。我只是很好奇这些……

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

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

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

Lenny： 对。但我觉得产品领导者的加入是一个非常有意思的补充。你不能只是把这个团队放在一边，却没有一个产品领导者来监督他们的工作。

Marty Cagan： 确实如此，因为我从《INSPIRED》中真正学到的一件事是，光有团队做好自己的工作是不够的，还需要领导层做好他们的工作。两者缺一不可。这就是为什么我说我们不把它框架为自上而下或自下而上。我们把它框架为每个群体各司其职。当这些都能做到的时候，效果真的很美妙。

Lenny： 我们会附上你写的那篇文章的链接，《产品领导力戏剧化表演》，讲的是人们如何把这个做砸，以及假装在做和真正做对分别是什么样子。

Marty Cagan： 好。

20 条原则概览

Lenny： 那么这些原则有哪些？简单触碰几条就好——

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

Lenny： 太棒了。我想听这个播客的人，如果他们处于你所说的做得好的那 10% 或 20% 的公司里，大概会觉得——当然如此。而其余的人大概会觉得——不可能，我们根本做不到那样。

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

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

Marty Cagan： 还有 Salesforce 也有大型……但不要把团队的实际发布和营销发布混为一谈。所以批量发布是很正常的，而且我认为是明智的。因为你看，大多数产品团队每天发布大约 20 次。你要每天做 20 次营销发布吗？那毫无意义。所以定期进行信息传达是有道理的，但在优秀的公司里，当他们对外发布消息的时候，功能已经上线了。它一直在持续出来。我们可能做了一些灰度发布，如你所知，但它已经在生产环境中稳定运行了。我们可能通过 AB 测试验证了每一项功能。

关于 Product Ops

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

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

当然，一些公司对 product ops 的理解和定义截然不同。其中很多不幸地将其等同于——他们把重点放在了流程和治理上。那是一个巨大的红色警报，我会告诉人们，如果你看到这种情况，赶紧跑。不要慢慢走开，要跑。另一个在很多公司中出现的情况是，让我感到惊讶的是，公司能多么富有创造力地去找到各种理由来给产品经理配备助手，因为产品经理说工作太多了。这对我来说真的很讽刺，因为说这话的通常是功能团队，而我心想，“你本职工作都还不够做的。“但不管怎样，他们说，“工作太多了。“于是他们说，“好吧，我们需要帮助。“所以有一阵子，他们都有那种初级产品经理。然后很多公司还有，哦，我们还有 product owner。产品经理加 product owner，这根本说不通。巨大的反面模式。如今很多公司用同样的借口，但变成了产品经理配 product ops 人员来做脏活累活。不行。说实话，我不想成为那些人中的一员，因为我认为他们现在非常脆弱。

Lenny： 我改变了对 product ops 的看法。一个原因是，我之前也觉得，“我不需要在每件事上再多一个人参与。我只想……”我都不知道为什么要那样做，即使我有做不完的工作、每天都在疯狂加班。但我认为和我交流过的 product ops 从业者有一个很好的特点——他们人数不多。你通常只需要一个人来做大量的事情、帮助很多不同的团队，所以它不像一个疯狂膨胀的团队。

Marty Cagan： 这正是我喜欢的。用户研究也是一样，顺便说一下，你之前有一位非常优秀的嘉宾也试图说明这一点——一个小的、高杠杆的团队。数据分析师也是如此，用户研究也是如此，他们帮助各个团队完成需要做的工作，但关键取决于他们在做什么。我告诉你，我见过太多公司，产品领导者没有做好自己的工作，于是他们招 product ops 来替他们做。现在是 product ops 负责培训产品经理。这不太好。

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

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

Marty Cagan： 好的。首先，我也是那些试图劝阻他们不要太早招产品经理的人之一，因为他们中很多人确实犯了招得太早的错误。现在要意识到我们在这里讨论的是什么——结合我们之前所有的讨论，这是又一个层面——我说的是一个真正的产品经理。如果他们把产品经理当项目经理用——很多时候确实如此——那我会告诉他们，他们付高了工资，但好吧，你可以在项目管理方面获得一些帮助。那不是 CEO 时间的好用途。但如果是一个真正的产品经理，关注的是价值和可行性，那是创始人的工作。创始人应该做这件事，也需要做这件事，通常如果太早引入一个真正的产品经理反而会导致冲突。厨房里厨师太多了。

你需要达到一定的规模之后，让其他人来负责价值和可行性才会有帮助。这一切的前提是他们理解真正的产品管理，否则会导致截然不同的问题。

Lenny： 所以我认为这里的一条建议是，达到 product-market fit 之后再招产品经理是更好的时机。否则，他们就是横亘在你和产品之间，拖慢一切，对吧？

Marty Cagan： 对。记住，通常你一达到 product-market fit，就开始为其他产品和其他市场做同样的事了，所以这是一个持续的过程。但在规模还小的时候，通常最管用的方式就是看工程师的数量。到了一定数量的工程师——通常是 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： 我一直在读他多年来写那本书的写作过程记录，他为了让那本书问世经历了一段相当不寻常的旅程。你有最近特别喜欢的电影或电视剧吗？

最喜欢的面试问题

Marty Cagan： Lenny，你问错人了，我几乎什么都不看，这个问题不适合问我。

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

Marty Cagan： 考虑到我做了那么多面试，我已经不再透露我最喜欢的问题了，因为它们会被放到网上。不过我确实有一个几乎对每个人都会用的问题作为开场，我想知道他们能不能定义产品经理的工作职责是什么。

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

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

最近喜欢的产品

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

Marty Cagan： 我最近买了一辆 Rivian，他们做得非常漂亮，令人惊叹。他们简直是汽车界的 Airbnb，因为创始人是一位设计师，想象一下如果由一位设计师来设计下一代汽车会怎样。做得极其出色。

Lenny： 哇，我刚才还在想你是不是说可以租别人的车，听起来还挺酷的，但你是另一个意思。有意思的是，你和 Meta 的 [听不清] 都把车作为最近最喜欢的产品发现。他选了奔驰。我之前还开玩笑说希望有一天能送出这些产品，结果预算因为大家都选车而暴涨。

Marty Cagan： 嗯，我最喜欢的事情是骑摩托车，现在出现了一代新产品——谁知道呢，也许有一天能救我的命——就是无线安全气囊背心，穿在身上的，它使用 AI 技术和传感器来决定是否应该弹开。幸运的是，我的还没有弹开过，但我知道对很多人来说它救了他们的命。这就是技术的一个例子，没有这项技术的话，骑摩托是非常脆弱的……即使有，也还是脆弱的。

Lenny： 等等，你骑摩托车？

Marty Cagan： 骑的。

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

Marty Cagan： 我有两辆，都是 BMW。

Lenny： 哇，我们得在哪看到一张照片才行。太厉害了，我完全不知道。

人生格言与写作

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，Silicon Valley Product Group。如果你还不认识我们任何一位合伙人，你应该试着去认识一下。我们都喜欢和社区的朋友交流，我觉得你会喜欢的。希望这些信息有用。

Lenny： 我们之前已经请过两位合伙人了，剩下的我们会慢慢请过来。我想确保你回答了最后一个问题，听众怎样才能帮到你？

Marty Cagan： 说实话，我们很多写作的灵感都来自大家的问题。所以当有人读了我们的东西觉得有用，告诉我们，我们也非常开心。但如果他们有后续问题，在线归档的好处就是我们可以直接更新那篇文章来回应这个问题。所以我们很欢迎提问。

Lenny： 你也是这么做的。

Marty Cagan： 所以尽管问。

Lenny： 好的，太棒了。Marty，非常感谢你抽出时间来做这次访谈，感谢你的到来。

Marty Cagan： 谢谢你，Lenny。

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

术语表

原文中文
AB testAB 测试（A/B 测试，对比两个版本效果的实验方法）
anti-pattern反面模式（指常见但有害的做法）
backlogbacklog（待办事项列表，保留原文）
Ben ErezBen Erez（产品经理，保留原文）
bottom-up自下而上
Brian CheskyBrian Chesky（Airbnb 联合创始人兼 CEO，保留原文）
buyer beware买者自负（ Caveat emptor ，指消费者需自行判断信息可靠性）
ChristianChristian（Marty Cagan 的 SVPG 同事，保留原文）
CI/CDCI/CD（持续集成/持续部署，保留原文）
CPOCPO（Chief Product Officer，首席产品官，保留原文）
CSPOCSPO（Certified Scrum Product Owner，认证 Scrum 产品负责人，保留原文）
dark release灰度发布（功能已部署但对用户不可见，逐步开放）
design by committee委员会设计（指多人集体决策导致设计平庸的现象）
design opsdesign ops（设计运营，保留原文）
DevOpsDevOps（开发运维，保留原文）
empowered有自主权的
feature factory功能工厂（指只按需求清单交付功能、缺乏产品思考的团队或公司）
feature team功能团队
GenAIGenAI（生成式人工智能，保留原文）
go to market上市策略
individual contributor独立贡献者
instrumentation数据监测（在产品中埋点以收集使用数据）
Joan DidionJoan Didion（美国作家、记者，保留原文）
Leslie LamportLeslie Lamport（计算机科学家，LaTeX 排版系统的创造者，图灵奖得主，保留原文）
Nikhyl SinghalNikhyl Singhal（Meta 产品副总裁、前 Google 产品总监，保留原文）
NVIDIANVIDIA（保留原文）
outcomes成果（相对于产出的实际业务影响）
output产出（交付的工作量或功能数量）
PRDPRD（Product Requirements Document，产品需求文档，保留原文）
process people流程人（指过度依赖流程而忽视卓越产品工作的人）
product leaders产品领导者
product leadership theater产品领导力戏剧化表演
product management theater产品管理戏剧化表演
product operating model产品运营模型（Marty Cagan 提出的产品组织运作方式）
product opsproduct ops（产品运营，保留原文）
product ownerproduct owner（敏捷框架中的角色，通常负责管理 backlog，保留原文）
product strategy产品战略
product-market fitproduct-market fit（产品市场匹配，保留原文）
PSPOPSPO（Professional Scrum Product Owner，专业 Scrum 产品负责人，保留原文）
RivianRivian（美国电动汽车制造商，保留原文）
roadmaproadmap（产品路线图，保留原文）
Shreyas DoshiShreyas Doshi（产品管理领域知名顾问，前 Stripe、Twitter、Google 产品负责人，保留原文）
specspec（规格说明文档，保留原文）
stakeholder利益相关方
SVPGSVPG（Silicon Valley Product Group，Marty Cagan 创办的产品咨询机构，保留原文）
tech leadstech leads（技术负责人，保留原文）
Teresa TorresTeresa Torres（产品发现领域专家，《Continuous Discovery Habits》作者，保留原文）
Tim UrbanTim Urban（Wait But Why 博客作者，《What’s Our Problem?》作者，保留原文）
Tony FadellTony Fadell（iPod、iPhone、Nest 核心设计师，《Build》作者，保留原文）
top-down自上而下
triad三人组（指产品经理、产品设计师、tech lead 构成的核心团队）
ZuckZuck（Mark Zuckerberg 的简称，保留原文）
增长黑客增长黑客（growth hacking，通过快速实验驱动用户增长的方法）
概率性软件概率性软件（probabilistic software，输出结果具有不确定性的软件）
确定性软件确定性软件（deterministic software，相同输入始终产生相同输出的软件）

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