如何构建你的产品战略栈 | Ravi Mehta（Tinder、Facebook、Tripadvisor、Outpace）

Ravi Mehta 2023-01-19

如何构建你的产品战略栈 | Ravi Mehta（Tinder、Facebook、Tripadvisor、Outpace）

如何构建你的产品战略栈 | Ravi Mehta（Tinder、Facebook、Tripadvisor、Outpace）

文字记录

Ravi Mehta：

我在指导产品负责人时喜欢用的一个框架，是想像一个矩阵。你的理想目标是以可扩展的方式领导团队——也就是说，你对团队的方向非常有信心，同时团队拥有朝着那个方向前进的自主权。还有一种非常有效的领导方式，就是选择性微观管理（selective micromanagement）——如果你对团队前进的方向没有信心，正确的做法不是放手不管、任由他们走错方向。正确的做法是去微观管理，但要做得非常有策略性、非常有临时性，帮助他们理解正确的方向是什么，然后你就可以退回来。

Lenny：

欢迎收听 Lenny’s Podcast。我是 Lenny，我的目标是帮助大家提升打造和增长产品这门手艺。我会采访世界级的产品负责人和增长专家，从他们在打造和扩展当今最成功公司过程中积累的宝贵经验中学习。

今天的嘉宾是 Ravi Mehta。Ravi 曾是 Tinder 的首席产品官、Facebook 的产品总监、Tripadvisor 的产品副总裁，现在他是一家名为 Outpace 的公司的联合创始人兼 CEO，稍后他会分享一些这家公司的情况。Ravi 是我最喜欢的作者和产品智慧分享者之一，他还参与创建并教授 Reforge 的产品领导力和产品战略课程，这也是我们今天花最多时间讨论的话题。我们聊了如何提升制定产品战略的能力、如何发展产品领导者的技能，以及在大公司做 PM 和自己创业之间的一些区别。就像我在开头说的，我觉得需要让更多人认识 Ravi，我很高兴能帮到这一点。好了，简短的品牌赞助之后，请出 Ravi Mehta。

[赞助商广告已跳过]

初识与致敬

Lenny： Ravi，欢迎来到播客。

Ravi Mehta： 谢谢邀请，很高兴来到这里。

Lenny： 我一直是你文章的超级粉丝。说出来可能有点奇怪，但我就是觉得了解你的人还不够多，我很期待向你学习，也让更多人分享到你的智慧。

Ravi Mehta： 哦，谢谢你，这对我来说意义很大。我也一直在关注你的工作，一直听这个播客，看到它这些年来的演变真的很棒。

Lenny： 太好了，伙计，真的很感谢。它还在不断进化中。那我们先用你的背景开个头，你能不能花一分钟大概讲讲你的职业历程，聊聊你做过的一些精彩的事情，然后谈谈你最近在做什么。

从编程少年到 Xbox Live

Ravi Mehta： 我在科技行业待了很长时间了，这会暴露我的年龄。我是九十年代中期入行的。我爸爸当时在美国运通工作，他刚完成了一次大规模的电脑采购，是他们最早的大规模电脑部署之一。他带回家一台 Apple TC 电脑，那时候电脑上除了学编程没什么可做的。所以我非常早就开始编程了，大概九岁、十岁的样子，真的深深爱上了技术，这份热爱一直延续到今天。

我在高中时创办了一家游戏公司，大学期间全职和兼职都在做这件事，中间还退学了一段时间。后来回去完成了学位。毕业后的第一份工作是微软，而且加入微软的时机非常有趣——他们当时正在对游戏进行一笔相当大的投资。我作为 Xbox Live 团队最早的一批成员加入，主要思考的是：一个将未来建立在互联网上的公司，如何看待游戏的发展方向。这和该领域其他公司比如任天堂或索尼对游戏的思考方式截然不同。

我在那里待了大约六年，平台端和内容端都做过。那是一段非常好的经历，但我知道自己想去更早期的阶段。离开微软后我直接去读了商学院，短暂尝试了管理咨询，但最终决定还是想亲手打造东西，于是商学院毕业后直接回到一家早期创业公司。我作为一号员工加入了一家 FinTech 创业公司。不久之后，我加入了 Brian Balfour——也就是 Reforge 的 CEO——在他的第一家创业公司工作。

近年角色与当前事业

我最近的几个角色都是在大型公司的产品领导岗位：在 Tripadvisor 负责消费者产品团队，在 Facebook 担任产品领导角色，然后是 Tinder 的首席产品官。过去几年我又回到了创业这一边，很乐意多聊聊这些。

Lenny： 好，我们先聊聊你现在在做什么，先把这部分聊出来，然后继续。

Ravi Mehta： 好的。我在大公司待了大约十年，与大型产品管理团队和大型工程团队合作。我发现这类工作非常令人充实，能够大规模地影响用户。但我也很想念从零开始打造新事物的感觉，想念去思考未来的发展方向，而不必去解决大型企业必须面对的那些历史遗留约束。所以我决定离开 Tinder，开始探索下一步想做什么。

Ravi Mehta： 我花了大约 18 个月的时间作为驻场创业者/驻场高管与 Reforge 合作，帮助他们搭建和推出了产品领导力项目，也帮助他们推出了产品战略项目。在这个过程中，我与几十位处于职业生涯中段的人进行了交流，发现了一个非常有趣的共同挑战——现在学习新技能的途径有很多，有很棒的播客和博客，也有像 Reforge 这样优秀的同期制课程。但在我的职业生涯中，有一件事对我的提升帮助极大，那就是一对一辅导。没有什么能真正替代与一个能提出正确问题、帮你看到拐角处风景、分享他们亲身经历的人对话的机会。而多年来，辅导并没有变得更普及。

大约 18 个月前，我决定创办 Outpace，这是一家致力于让顶尖专家驱动的辅导对所有人都触手可及的公司。我们通过专注于产品本身、运用大量系统和内容来结构化辅导流程，同时也利用 AI 来提高辅导师的效率，目标是让专业知识驱动的辅导对人们来说更加可及。

Lenny： 太棒了。我想先花点时间聊的第一个话题是，你之前谈到了自己的职业轨迹——你是 Tinder 的首席产品官、Facebook 的产品总监、Tripadvisor 的副总裁，现在又创立了公司，而且过去也创过业。听这个播客的很多产品经理都希望有一天能自己创业，他们可能正在某家大科技公司或其他地方工作，或者正在创业的过程中。我很好奇，你觉得在大公司做产品负责人和在创业公司——尤其是自己的创业公司——做产品之间最大的区别是什么？特别是，从大公司转型到创业的过程中，你感受到的最大意外是什么？

速度与延迟的区别

Ravi Mehta： 在过去 18 个月里，从产品领导角色转变为创始人角色，我经历了几个非常有趣的思维转变。第一个是关于速度的全新思考方式。我觉得有一种常见的——我会说是一种误解——认为创业公司比大公司更快。而我最初的感受恰恰相反，自己创办公司后事情反而感觉更慢了，因为我没有那么多的工程师可以合作，没有围绕各项工作组建好的团队，也没有现有用户的势能可以用来做研究和定向。

在过去 18 个月的旅程中，我逐渐意识到，创业公司所拥有的速度优势并不在于速率（velocity）。大公司总是能完成更多的事情，总是能投入更多的资源，总是能以更高的速率运转。小公司真正的优势在于延迟（latency）——你今天有一个想法，明天就能测试它，因此你可以在一个假设和验证这个假设之间拥有极短的周期时间。这在大公司里是做不到的，因为那里有太多的惯性。

我喜欢用的一个比喻是开车。如果一辆车开得非常非常快，它就不能那么快地转弯，转向半径是受限的。所以创业公司拥有非常紧凑的转向半径，而大公司拥有非常高的速率。因此对我来说，需要调整的一个方面就是，学会把大公司里那种宏大的计划拆解成更小的碎片，能够不断迭代，每天或每隔几周就能获得数据，而不是做一个可能需要一个季度才能完成的大型项目。

Lenny： 为了让大家更好地理解你的意思——速度和延迟之间这个有趣的区别。所以具体来说区别是什么？延迟基本上就是你做决策和调整方向的速度，对吗？你是这样理解的吗？

Ravi Mehta： 我认为速率是指工作的数量，而延迟是指你从一个想法到真正能测试这个想法并判断它是否正确的速度有多快。

Lenny： 明白了，很棒。

Ravi Mehta： 我喜欢用来测试延迟的一个问题是：如果你想对产品做一个非常简单的改动，比如改一个按钮，测试按钮上两种不同的文案，从”我们认为这个改动值得做”到”拿到结果判断这个改动是否正确”，需要多长时间？

Lenny： 明白了，很有意思。

决策方式：从实验导向到信念导向

Ravi Mehta： 第二个转变是关于决策方式的重新思考。我认为当今很多拥有大量用户的高效公司，都依赖一种实验化的决策方式——你把东西抛出去，跑一个实验，看统计数据是否显著，基于此获得一个非常好的方式来了解用户想要什么，并迭代出最优产品。

但在创业公司，你做不到这一点，因为你没有那么多用户来测试。我认为很多创业公司犯的错误就是过早地采用实验方法——要么花太长时间才能获得统计显著的结果，从而增加了延迟；要么结果不够可靠，因为你只能用很小的样本量。所以我不得不将心态从实验导向的决策方式转变为信念导向的决策方式。

我经常问自己这样一个问题：我们是否有足够的数据来形成有依据的信念，然后就应该向前推进，停止继续挖掘，朝着某个方向前进，再看结果是否正确？因为在创业公司里，你很容易陷入分析瘫痪——不停地分析市场研究，梳理所有可能的战略选项，思考所有可能的产品变体、所有的定价策略。而事实上，对创业公司来说更合理的做法是，到达一个你有信念的程度，据此执行，然后判断结果——如果是对的，就加倍投入；如果是错的，就迅速调整方向。

Lenny： 很棒。还有呢？

创业公司的人脉网络差异

Ravi Mehta： 另一件让我感到意外的事情是，人脉网络其实相当不同。这些年来我有机会与非常多优秀的人合作，当我开始创业时，我很兴奋地去联系他们，告诉他们我在做什么。其中有不少我曾经在大公司共事过的人，我也有意愿和他们一起合作。

Ravi Mehta： 但我发现，人们其实会围绕某个特定阶段来构建自己的生活方式和职业发展。确实有些人喜欢在不同阶段之间切换，但大多数人并不会。很多在大公司的人，他们喜欢大公司带来的福利，喜欢他们正在处理的那些问题的类型。然而还有另一个完全不同的社群，由那些热爱早期阶段工作的人组成。他们可能是创始人，也可能是喜欢帮助打造创业公司的自由职业者，还有投资者和天使投资人。所以这段旅程中一个非常有意思的部分，就是结识新的人，了解那些人脉网络，并开始建立起一群和我一样对早期阶段充满热情的人。

Lenny： 明白了。所以你的发现是，你在 Tinder 或 Facebook 积累的人脉网络，可能并不是那种创业型的人，也许不像你想象的那样在招聘等方面那么有用？这是你的发现吗？

Ravi Mehta： 对。我觉得很多在大公司的人，已经习惯了一种特定的工作方式。他们在自己的专业领域已经非常精通，在思考职业下一步的时候，他们更希望在自身专业上继续深耕。而喜欢早期阶段的人则更加通才化，他们不介意在某种程度上”倒回”到更基础的层面。在大公司，你不会找到很多愿意亲自写代码、写产品文档的资深工程负责人或资深产品负责人，但在那些创始人圈子和对早期阶段感兴趣的人脉网络中，你会找到这样的人。

Lenny： 这是一个非常有趣的洞察——你以为自己在大公司工作期间建立了一个庞大的人脉网络，但当你想创业时，它可能并不是你真正需要的那个网络。对于那些说”嘿，我想在未来几年内创业，目前还在 Facebook 或 Google”的创始人，你还有其他建议吗？你觉得他们现在可以做些什么来为未来的成功做好准备？

尽早融入早期阶段的人脉网络

Ravi Mehta： 我认为尽早接入一个早期阶段的网络非常重要。现在有很多不同的途径可以做到这一点。有专注于创始人匹配的社区，也有专门为创始人提供交流空间的社区。独立开发者社群以及一些相关社群中有非常棒的一群人。所以我认为，与那些对创业充满热情的构建者建立联系非常重要，不管是开发端还是运营端，也包括投资端。与天使投资人和投资者建立联系，他们能看到早期创业公司内部正在发生什么——大家最关心的是什么？有哪些技术趋势是人们正在积极利用的？

另一个非常有意思的差异在于，早期阶段公司的营销和增长方式，与预算充裕的后期阶段公司截然不同。所以那些在大公司擅长搭建营销活动的人，与那些更偏早期阶段的人会非常不同。早期阶段更多的是那些”黑客”型的人，他们会去探索各种有趣的新型分发渠道，或者在 TikTok 上运用有趣的技巧，或者利用各种有趣的 SEO 手段。这完全是两套不同的人脉网络，也是两套不同的知识体系。所以我觉得，对于最终想要创业的人来说，重要的是提前培育那个网络，这样在你准备好迈出那一步的时候，就能迅速接入那个社群。

Lenny： 有没有其他具体的社区浮现在你脑海中，是你觉得有价值的，或者你认为值得那些说”好的，独立开发者社区，我去看看”的人去关注的？现在有没有其他你觉得非常值得花时间的地方？

Ravi Mehta： 有的，我觉得最好的两个社区之一就是独立开发者社区。我非常喜欢这个社区的一点是，里面有很多在思考”我如何独自构建一样东西”的人。这与大公司的体验完全不同。如果你想象一个光谱：一端是大公司，中间是 VC 支持的创业公司，在那里你可以将大公司学到的一些思维方式加以运用，因为你有能力投入大量资源；光谱的另一端则是一个怀揣梦想的个人，他们想创业，他们在思考如何独自完成一切——他们完全是通才，既是构建者也是销售者，还要处理所有的后勤事务。所以我喜欢独立开发者社区。

另一个非常好的社区是 Everything Marketplaces。这个社区的创始人 Mike 在聚集一批创始人方面做得非常出色。他特别专注于市场型业务，这类业务有一些独特的运作机制，尤其是在非常早期的阶段。但即使你对市场型业务不感兴趣，我认为也值得去看看他们在做什么、举办的活动以及参与其中的人。他们在策划整个体验方面做得非常出色，为创始人提供了一个非常好的基础。

Lenny： 我也是这个社区的超级粉丝。我很喜欢 Mike，我们是网友。他听到这些会很开心。网站的地址应该是 everythingmarketplaces.com，大家可以去看看这个社区。如果不对的话，Google 一下就行，我们也会放在节目备注里。

产品战略栈

那么 Reforge，你之前提到了好几次，这也引出了我想花我们对话主要篇幅来聊的内容。你构建了 Reforge 的产品领导力项目和产品战略项目。所以这两个领域是你花了很多时间思考的——产品领导力和产品战略。

先聊产品战略。每个产品经理、每个创始人、每个领导者都会说自己想在战略上做得更好。我敢保证，如果我问每个产品经理”你想在产品战略上做得更好吗？“百分之百的人会说当然想。但”战略”是一个非常模糊、含混、笼统的概念——我要在战略上做得更好，我要变得更好，我要更有战略性。你有一个非常酷的框架和思维模型，你称之为产品战略栈。所以我想花一点时间聊聊这个概念是什么，它如何帮助你思考战略、使命、愿景，以及这些东西之间如何协同运作。我们就从最基本的问题开始：什么是产品战略栈？

Ravi Mehta： 产品战略栈的目标是帮助人们把一组通常被混为一谈的概念——比如目标（goals）、路线图（roadmap）、战略（strategy）——拆分成定义清晰的组成部分。我最初开始使用这个概念的原因是，经常有产品经理来找我，他们不知道应该在 A 和 B 之间如何选择。可能有两个功能，机会规模大致相当，他们不知道应该先做第一个功能还是第二个功能。

产品战略栈的构成

很多时候，当我和团队交流、帮助诊断这个问题时，归根结底是对战略缺乏足够深入的理解。那么，究竟什么框架才能真正指导优先级排序？因此我经常看到，优先级排序的困难以及日常工作中浮现的战术问题，往往可以追溯到产品经理个人在战略理解上相当根本的缺失。而且这些缺失往往不仅仅是因为某个人可能不理解战略，也可能是因为战略本身还没有被完整地定义出来。

Ravi Mehta： 所以产品战略栈是一个帮助人们理清自己所使用的决策框架、以及什么能为业务创造价值的系统。栈的顶端是公司使命，而公司使命是公司希望为世界带来的改变。它本质上是一个关于公司目的的、定性的、令人向往的陈述。在某些情况下，它可能不是一家公司，而可能是公司内部的某个团队，或者是某个子公司，具体取决于你所处的环境。但它基本上是一个统领全局的使命，帮助引导前进的方向。

第二层是战略。使命是令人向往的，而战略则是严谨的逻辑。战略是公司将用来实现那个使命的逻辑计划。所以它必须非常具体，必须非常严谨，本质上是公司用来在实现使命方面取得进展的计划方案。因此，公司层面的使命和战略真正定义了公司试图达成的目标。产品战略栈的下一层是产品战略。产品战略是连接”公司试图达成什么”和”产品团队日常在做什么”之间的纽带。在产品战略之下，产品战略指导路线图，而路线图最终指导目标。

这五个部分——公司使命、公司战略、产品战略、产品路线图和产品目标——作为一个系统协同运作。如果产品经理要定义战略，可以自上而下地推进；如果要诊断战略问题，可以自下而上地排查。所以如果你在达成目标方面遇到困难，可能是因为路线图的设定并没有推动那些目标前进。如果路线图有问题，可能是因为产品战略没有被清晰地阐述出来。如果产品战略有问题，可能是因为团队对公司战略、产品如何融入其中，以及公司试图推进的使命缺乏足够深入的理解。

使命与愿景的关系

Lenny： 非常棒。我有一堆问题。一个是，很有意思的是，“愿景”（vision）在栈里没有出现。它是归到……

Ravi Mehta： 对。

Lenny： ……某一个层级里了吗？还是说你觉得愿景根本不需要？

Ravi Mehta： 我把愿景看作使命的一部分。

Lenny： 好的，我也是这么想的。

Ravi Mehta： 我一直搞不清楚愿景和使命之间的区别到底是什么。所以最初做这个框架的时候，有一个版本是把使命和愿景放在一起的，也有分开的版本。我通常听到的区分是：愿景是公司对未来的图景，而使命是在那个愿景之下公司所承担的使命。我觉得你完全可以将两者合二为一，用一个声明同时描述那个世界和公司在其中所扮演的角色。这通常就足够了，可以帮助推进工作并开始定义战略。

Lenny： 好的。

Ravi Mehta： 但我知道你也写过相关的内容，并且特别强调了愿景。所以我很好奇你是怎么看待使命和愿景之间的关系的。

Lenny： 对。我觉得最重要的是人们经常在这上面卡住，试图把它们定义得完美无缺。我认为最关键的就是不要想太多。只要写出一个听起来差不多对、能让团队兴奋的东西就行了。这是最重要的。我的理解是，使命就是你在这个世界上试图达成什么？而愿景是，一旦你达成了，那个世界会是什么样子？对未来的图景是什么？使命是你在这个未来中试图做什么。所以这是我的理解——你想做什么？它长什么样？但我觉得把它们合为一个东西也挺好的，只要有效就行，没有唯一正确的方式。

用视觉化方式定义战略

Lenny： 我也知道你在思考愿景、定义愿景时，非常主张要让愿景非常视觉化，而不只是一份文档。你能谈谈这一点吗？

Ravi Mehta： 这个框架最初起源于我在 Tripadvisor 的时候，当时我们需要为旅行规划制定一个战略计划。这对公司和对产品来说都将是一个非常大的新功能。旅行规划是那种老大难问题——有不少创业公司就是从旅行规划起步的，但没有人真正做好它。当时 Google 也有一个旅行规划应用，有一些有趣的元素，但并不清楚他们是否真的做好了。所以我们知道这里既有一个非常有价值的问题需要解决，也有一个非常困难的问题。我们希望采取端到端的方式来解决这个问题——不是自下而上地通过实验逐步推进，那样可能无法对齐到一个清晰的产品战略——而是自上而下地工作，定义我们想要达成什么、打算如何达成、以及将采取哪些增量步骤来达到目标。

我们确定的一个原则是：没有线框图的战略文档就不算完整。这是我们在战略语境下第一次这样做。我们真正想解决的问题在于，很多时候当你仅仅用文字来谈论战略时，每个人对战略的理解都不一样；而当你能向人们展示战略实施后产品会是什么样子的线框图时，它能创造高得多的对齐度。

我喜欢用的一个类比是，这有点像和建筑师合作。你绝不会和一个不给你提供建筑蓝图的建筑师合作，因为仅仅用文字来描述一栋房子是不够的，每个人离开后对需求的理解都会有所不同。但一旦你能看到蓝图——蓝图不需要是高保真的，它是一个概念性的框架，展示各部分如何布局——它就能帮助你理解各部分将如何组合在一起。大多数产品最终都是以视觉形式呈现的，它们是屏幕上的像素。所以理解这些像素将如何组织是很重要的。

Ravi Mehta： 我觉得一个很有趣的试金石问题是——很多移动应用的导航栏上只能放四五个项目。这四五个东西是什么？如果你只是用文字描述战略，不同的人可能会设计出完全不同的导航栏。结果就是，到了实现移动应用的时候，你会发现大家对什么对公司有价值、功能应该如何组织，有着完全不同的理解。所以，设定战略、然后用线框图将其非常清晰地定义出来的这个过程，能帮助你非常具体、非常明确地理解你要构建什么、什么能实现战略、以及为了让它落地你需要做哪些取舍——因为屏幕上的像素永远是有限的。

没有设计师怎么办

Lenny： 我想正在听这个的产品经理可能会觉得：“好的，没错，我很乐意在我所有的愿景文档里放上线框图，放上我想要做的所有东西的高保真设计。这就是我正在做的事。“但我猜他们通常没有设计师可以配合，也没有为了某个即将到来的评审而准备好各种清单。你对这些人有什么建议？是不是说作为产品经理，简单画个草图也比什么都没有强？当没有人能帮他们把这件事做好时，你有什么建议？

Ravi Mehta： 如果能和设计师合作当然很好，但我同样认为产品经理理解设计、理解 UX 和 UI 非常重要。如果你没有设计技能，完全可以就在纸上画草图。在我的职业生涯中，我一次又一次地回到 Balsamiq，这是一个非常好的线框图工具，已经存在一段时间了，操作速度极快。通常一个下午你就能创建出一组高层次的概念线框图，放在人们面前，能让他们对你试图构建的东西有比仅仅分享一份纯文字规格说明清晰得多的理解。

所以我建议，学一学怎么画草图，学一学 Balsamiq。能够在概念层面思考 UI 和 UX 如何运作，我认为这是做产品经理的一个关键能力。如果你现在还不具备这个技能，有很多很好的资源可以帮助你提升。而且我认为这也会让你作为产品经理感觉更有掌控力——你不需要觉得每次都得依赖设计师才能把产品视觉层面想清楚。

Lenny： 好。产品经理们，别找借口了。

Ravi Mehta： 没错。

产品战略栈的实际案例

Lenny： 好。回到产品战略栈，你能不能分享一个你工作过的公司的例子，展示这个栈是如何运作的？就是一个例子，回顾一下它的使命战略、产品战略、路线图、目标。趁你说的时候，我要尝试一个新东西——我要拉出一个窗口，展示你做的这个可视化图，它应该会出现在我的屏幕上。你看。所以如果你在 YouTube 上……或者现在 Spotify 上也可以看这些视频了，可能有些听众已经注意到了……

Ravi Mehta： 哦，很酷。

Lenny： 这是他们刚给我的播客解锁的新功能，这些视频在 Spotify 上也能看了。可以去 Spotify 或 YouTube 上看看。但回到你的问题——你能不能分享一个例子，也许来自 Tinder 或 Facebook 之类的，展示产品战略栈的实际运作？

Ravi Mehta： 文章本身有一个例子，我现在不展开了，是 Slack 和 Discord 的对比。我觉得这是一个非常有趣的例子，因为这两个产品如此相似，但公司战略和使命却如此不同。它们服务着极其不同的用户群体，尽管这两个团队路线图上的很多项目很可能是相同的——消息串、表情回应、频道、视频聊天等等。我觉得我过去经历中一个非常有意思的例子，是比较 Tinder 和 Hinge。

Lenny： 怎么说？

Ravi Mehta： 它们都是约会应用，但使命截然不同。Hinge 的使命几乎是对 Tinder 的回应而生的。Hinge 的使命是”被设计为被删除”。这贯穿在它所有的营销中——来用我们的应用吧，我们知道如果我们的应用对你有效，你会找到那个人，开始一段长期关系，然后你会删除我们的应用。我们认为这就是成功。而 Tinder 的使命则是让单身生活更有趣。Tinder 的使命是成为一款在人们单身时一直在手机上的应用，通常贯穿他们的 20 多岁一直到 30 岁出头。所以这两个使命非常不同。一个是临时使用场景，另一个是持续使用场景。因此，尽管它们服务于相同的基础需求——帮助人们相互认识——它们的使命却截然不同。

公司战略也有相当大的不同。在应用如何变现方面有一些相似之处——两个应用都是免费增值（freemium）模式，你可以免费使用产品，然后有特定的付费功能，付费功能之间也有一些共同点。所以在变现模式上有一定的共同性。但在用户获取模式上有非常大的差异。Hinge 很大程度上依赖电视广告，这帮助他们触达可能使用他们产品的受众。Tinder 则更依赖网红营销和活动营销。所以这两家公司的战略有一些有趣的相似之处，也有一些有趣且重要的差异。

Tinder 和 Hinge 的产品战略实际上非常不同。Tinder 是最早的基于滑动的约会应用，被设计为一个非常轻量的体验——滑动非常快，匹配非常容易，聊天也非常容易。而 Hinge 是第一批真正成功的后滑动时代的约会应用之一。它们故意没有围绕滑动这个机制来构建产品，而是希望人们在彼此的个人资料上花更多时间，希望为这些资料创造更多工具。所以 Tinder 的个人资料非常简单，Hinge 的个人资料则有互动提示项。这些提示项让人们能够相互了解，激发有趣的对话，促成更深入的交流，最终导向长期关系。因为产品战略上的这个差异，产品路线图上有一些不同，但也有相似之处。Tinder 和 Hinge 在疫情后都在视频聊天上做了重大投入，因为他们知道人们在线下见面之前会花更多时间在线上，所以都需要让人们能够在产品内通过视频与对方交流。

最后是关于目标。两家公司最终在目标上非常相似，都是以有意义的对话来衡量成功。他们都希望人们匹配、希望人们互相聊天，但促成这些对话的具体产品机制是不同的。所以高层次的产品目标非常相似，一些更细节的产品目标则非常不同。通过战略栈，你可以很好地理解战略在哪里影响了特定的决策，什么时候一个决策应该和竞争对手相似，什么时候一个决策应该与竞争对手或可比公司不同。

筛选功能的产品哲学差异

关于 Tinder 我有很多问题。它真的是一家非常有趣的公司，经历了一段很有意思的旅程，产品也很特别。我的一个问题是，你之前分享了一些因为特定战略而构建的产品功能案例。还有没有其他例子让你想到——我们做了这个功能，而 Hinge 永远不会做，因为我们的战略如此不同？

Ravi Mehta： 有一个反例我觉得特别有意思。几乎每个约会应用都有筛选功能，一整套筛选条件——你可以按职业、收入、宗教、身高、是否吸烟等来筛选。Tinder 现在也有一些筛选能力，但很大程度上一直抵制把这些筛选功能加进去的冲动。原因在于，从产品哲学的角度，他们希望人们去互相了解、去聊天，而不是让 Tinder 变成一个”人的搜索引擎”，你输入一堆条件，进入一个筛选后的列表，只去见那些你想见的人。

这一点在产品体验中也真正体现出来了。很多人喜欢使用这款产品，因为他们会遇到自己说Otherwise绝不会遇到的人。因为如果给他们设置条件的能力，他们当然会填入自己的条件，然后去看一个经过筛选的、更窄的人群。所以通过保持产品体验非常轻量、非常注重偶然性，他们创造出了一种与其他约会产品非常不同的相识方式——其他产品更像是”人的搜索引擎”。

Tinder 难忘的记忆与故事

Lenny： 回想你在 Tinder 的时光，有没有什么记忆、故事或者疯狂的经历浮现在脑海里？

Ravi Mehta： Tinder 在产品发现方面一直很有意思。我在的时候我们做了很多焦点小组。我们让人一对一以及分组讨论他们的约会偏好，这些讨论总是能引发非常有趣的对话。其中让我最惊讶的一件事是，我在那里的时候，我们注意到有一小批用户在 Tinder 上花费很高。你会经常在社交游戏中看到这种行为——有些用户本质上是”鲸鱼用户”（whales），你的平均 ARPU（每用户平均收入）可能是 30 美元，而一个鲸鱼用户会花 200 或 300 美元。我们发现，按次付费（a la carte）的收入，也就是微交易收入，有相当大的比例来自极小的一个位数百分比的用户。当我们看人们花了多少钱的时候，我们的假设是，这些人一定是高净值人群，想要炫耀自己的财富，不太在乎这点钱。

Lenny： 顺便说一下，他们具体在买什么？因为我已经很久没用过 Tinder 了。在 Tinder 里你能买什么？那些微交易是什么？

Tinder 的变现模式

Ravi Mehta： Tinder 的变现模式有两个部分。一个是订阅制，有几个不同的订阅层级。基础订阅叫 Tinder Plus，然后主要订阅产品叫 Tinder Gold。Tinder Gold 的优势在于，它本质上让你可以打破 Tinder 的规则。在正常的 Tinder 里，你无法看到谁滑了你，只有当你向右滑了某人、对方也向右滑了你的时候，你们才能匹配。Tinder Gold 让你能看到所有向你右滑的人，所以你可以浏览这些人，决定要不要和他们匹配。这是一个非常基础的能力，人们愿意为此付费。

在此之上，还有一组按次付费的产品，你可以批量购买，也可以用一次买一次。其中两个主要产品是 Super Like（超级喜欢）和 Boost（提升）。Super Like 允许你向某个人发送一个超级喜欢。如果你发送了 Super Like，对方和你匹配的概率是普通的三倍。所以这是一种非常好的方式，可以非常有针对性地表达你想要认识和匹配某人。

另一个产品是 Boost。Boost 的工作原理和 Facebook Boost 或其他任何 Boost 产品一样——你的资料会在信息流中出现一定的次数，如果你付费 Boost，它就会出现得更频繁。我们注意到有一批用户每个月在 Boost 和 Super Like 上花费数百美元。于是我们决定找出其中一些用户，组织可用性研究，和他们交谈，了解他们为什么使用 Tinder，为什么愿意花这么多钱。

“鲸鱼用户”的真实画像

结果我们发现，实际情况和我们的假设非常不同。这些用户基本上是在说：“我真的想认识某个人。“他们有特定的使用场景。有些是军人，经常搬家；有些是销售，经常去不同的城市；还有些是刚搬到一个新城市的人。他们并不是高净值人群，收入并不比普通 Tinder 用户更高。他们只是有一个更强烈的使用场景——他们想要认识人。他们衡量 Tinder 费用的参照物，不是其他订阅服务的价格，而是约会的成本。他们会说：“如果我每个月出去约会几次，大概要花两三百美元。“取决于你是在纽约还是其他地方，可能还会更多。所以他们把每个月在 Tinder 上花的那几百美元看作一笔小小的投资，用来确保自己能和想约会的人约会。

这是一个非常有趣的例子——我们从数据中定量地发现了一个非常有趣的现象，我们知道它可能是推动业务增长的杠杆。但我们对这个使用场景背后的原因的假设是错误的。当我们最终去和用户交谈时，我们得到了一些非常令人惊讶和有趣的发现，也重新校准了对这些人想要解决什么问题的理解。他们真正想要解决的是更高效地认识人，减少在这方面花费的时间。而且他们对价格的认知框架也与普通用户非常不同。

Lenny： 我一直很喜欢这种例子——你在数据中看到某个现象，以为是某个原因，结果和用户聊完之后发现完全是另一回事。你能分享一下因为这个发现你们在产品上做了什么改动吗？还是说这是保密的？

Tinder Platinum 的诞生

Ravi Mehta： 可以说。这些对话产出了两个成果。一个是 Tinder Platinum，这是产品的第三个层级，价格稍微高一些，附带一些额外功能，以及一组可以在产品内使用的消耗品——额外的 Super Like 和 Boost。

Ravi Mehta： 另一个由此诞生的功能，有点像超级滑动。它让你不仅可以发送 Super Like，还可以附上一条留言发送 Super Like。所以它的价格比普通 Super Like 高得多，但本质上它允许你打破 Tinder 的另一条规则——匹配之前不能聊天。这个功能让你在匹配之前就能给对方发送第一条消息，基本上是为了表明你真的很有兴趣和这个人匹配，进一步提高匹配成功率。而且我们能够把价格定得比我们预期的要高得多，因为我们知道用户对这个功能效用的认知和我们完全不同。

Lenny： 太棒了。多么成功的产品案例——产品团队经历了用户发现研究、数据分析、设计、上线、创收的完整闭环。干得漂亮。

Ravi Mehta： 确实很棒。那位 [听不清] 负责这个项目大约一周时间，每次和这些用户通完话都会跑来我办公室好几次，分享她的发现。以上就是主要的收获，但深入了解这个用户群体本身也非常有趣。然后就是和用户交谈。我觉得很多时候人们没有花足够的时间拿起电话，与产品用户进行一对一的对话，去真正理解他们的心理、他们获得的价值，以及如何真正为此做优化。

（跳过广告段落）

Lenny： 我觉得做 PM 经常是一件吃力不讨好的工作，而这些时刻正是你作为 PM 最渴望的——就是这种成功的故事。

Tinder 带来的真实影响

Ravi Mehta： 完全同意。我加入 Tinder 后一个意想不到的事是，每周总有几次，我遇到的人或者打车时 Uber 司机会告诉我，人们会分享说”我在这个平台上认识了我的男朋友或女朋友”，或者”我认识了我的妻子或丈夫”。听到这些故事真的非常棒。还有一个我之前没意识到的——Tinder 极其轻量的设计，使其能够比其他约会产品更好地服务 LGBTQ 群体。所以我最有满足感的一些对话，就是和那些觉得没有 Tinder 就不可能遇到另一半的人交谈，因为没有其他地方可以做到这一点。

Lenny： 哇。有成就感、有影响力、有趣、令人惊喜。多么棒的一个角色。我自己其实是在一个已经关闭的约会网站叫 howaboutwe.com 上认识我妻子的。你听说过这个吗？

Ravi Mehta： 没有，我都没听说过。

Lenny： 它太好了，匹配效率太高了——就像它太完美地实现了 Hinge 的愿景，以至于没人需要继续留在这个平台上。我们没在上面花太多时间，但它的核心理念是”不如我们去……？“——它以约会概念为核心。所以不是浏览个人资料，而是浏览约会点子，然后你说”嘿，我想和你一起进行这个约会，我们出去试试吧。“结果对我们来说很成功。

Ravi Mehta： 真的很酷。这里还有很大的机会，我觉得有很多非常好的约会产品想法还没有被探索过。

Lenny： 嗯。有意思。好的，很好的投资建议。回到产品战略栈，回到正题。你的产品战略栈中有一个很有趣、有点反主流的地方——你把目标（goals）放在了路线图（roadmap）之后。我很好奇为什么？为什么你认为目标应该在有了路线图之后再确定？

目标为何排在路线图之后

Ravi Mehta： 是的，这确实是一个反主流的观点。有几个人为此跟我争论过。通常情况下，目标几乎是战略过程的起点而不是终点。公司会说”我们需要把收入提高 X”，或者”我们需要把留存率提高 Y。我们有什么策略来实现这个？“而这些年我发现，这种目标优先的方式会把产品团队的所有精力都集中在推动目标数字上，却没有任何关于成功是什么样以及为什么的结构。

我喜欢用的一个类比，有点像自驾游时一上来就说”嘿，我们需要开 250 英里”。不对，如果你要去自驾游，你首先要决定你想开到哪里去。如果你在洛杉矶，你可能会自驾去拉斯维加斯。所以我们的目的地是拉斯维加斯，而我们会知道自己是否到达了那里——如果我们开了 250 英里的话。因为那个 250 英里的目标是在一个目的地的语境下的。

所以我看待战略栈中所有组成部分的方式是，要非常清楚地明确你在追求的终点目的地是什么，然后你应该围绕帮助你到达那个目的地来制定目标。如果你发现实现目标实际上偏离了你的目的地，那就需要进行一次非常重要的对话——我们是否放弃这个收益，因为它与我们的目的地不一致？还是我们需要改变我们的目的地？我认为太常见的情况是，人们从目标出发然后创建路线图，结果目标占据了主导地位，却没有任何最终驱动它的背景或原则。于是关于产品方向的决策就这样来来去去，甚至没有被注意到，因为没有可以用来校准的东西。

Lenny： 所以我百分之百同意战略应该排在目标之前。但有趣的是，如果你的方法是先定战略，然后确定要构建什么，再确定目标，那你怎么排定路线图的优先级？因为在我看来，应该是先确定战略——我们如何到达我们要去的地方。目标对我来说是我们衡量向那个方向进展的方式。然后路线图从”什么能帮助我们实现这个目标”中产生，并根据什么最能影响我们设定的目标来排定优先级。那么如果你没有目标，你怎么排定优先级、选择路线图中的内容？是更像是”这是主要 KPI”，或者你对要关注和使用的 KPI 及指标有一个大致的感觉，以此来排优先级？还是你怎么考虑这个问题的？

Ravi Mehta： 对，我认为作为战略的一部分，你通常会有一些可量化的元素。比如，对于 Tripadvisor 来说，我们的旅行规划战略是希望用户直接来到 Tripadvisor 并在上面花更多时间。当时的情况是，大多数用户对 Tripadvisor 的使用都是穿插在访问 Google 之间的。人们会搜索”波士顿酒店”，来到 Tripadvisor，然后可能觉得不行，想看看纽约的，于是去 Google 搜纽约酒店，再回到 Tripadvisor 来看。而实际上 Tripadvisor 完全有能力让用户不用再回到 Google，因为我们了解他们的偏好、他们的状态、他们可能和谁一起出行。所以更多的规划活动可以直接在产品内部完成。

但问题在于，像 Tripadvisor 这样一家非常注重实验、非常数据驱动的公司里，产品团队一直在优化的是当下能驱动预订量的东西。而从 Google 访问进来能驱动预订的东西，自然会推动用户沿着交易路径往下走，促成预订，而不会让他们中途停下来设置行程、往行程里添加东西、创建心愿单。那些事情反而会妨碍交易本身。所以在缺少”我们实际上希望用户更频繁地直接来到 Tripadvisor”这个战略的情况下，我们做了很多事情，最终都削弱了这个战略，让用户从产品中跳过了，而不是留在产品中。

所以这是一个非常好的例子——如果我们知道要建立与用户之间那种长期持续的关系，从路线图的角度来看，我们可以做一系列事情来实现这一点。我们可以对这些事情排定优先级，可以用数字去衡量，可以做机会估算，然后据此排优先级，之后可以衡量我们是否取得了进展——而这一切都是基于我们想去哪里的那个战略性的、非常概念化的理解。

Lenny： 所以最大的收获，我想我们俩完全一致的一点是，战略应该在制定目标、确定目标、对齐目标之前。这一点毫无疑问。

说到目标，你对于如何制定目标、对齐和设定目标的最佳实践也有一些非常精彩的见解。我想深入聊聊这个话题，然后我还有另一个话题想讨论。

Ravi Mehta： 好的，听起来不错。我写过一些关于目标的文章，出发点是……我曾在多家实践 OKR 的公司工作过，过程中遇到了很大的困难。我也和很多产品团队聊过，他们都遇到了困难。所以我开始问的问题是，为什么公司在 OKR 上会遇到困难？到底是什么阻碍了团队设定他们真正知道如何达成的目标并实现这些目标？

我发现的其中一件事——我认为这是很多公司正在发生的一个第一性原理层面的问题——就是这个总是关注结果（outcomes）而非产出（outputs）的理念。这出发点是好的，最终来说——我也认为确实如此——一个产品经理需要根据是否为业务创造了有价值的结果来衡量自己的成功。但这并不意味着在本季度我们就必须承诺一个具体的结果，或者我们应该承诺一个我们可能并不知道如何推动的结果。

所以我认为最终目标确实是驱动结果，但很多时候在此之前还有一些事情需要先解决，这样你才能真正理解实现那些结果的计划是什么样的。我把这称为”理解前沿”（frontier of understanding）。团队所知道的和团队所不知道的之间存在一个交汇点，也就是这个前沿。实际上可能是我们不知道什么能驱动留存。如果你让我提升留存，我可以头脑风暴出 10 个实验，但我其实并不知道人们为什么会持续使用我们的产品。那么这时候承诺一个留存目标就没有意义，因为你会像是把意面甩到墙上，搞一堆实验，看哪个能粘住，也许你能推动那个指标，但你不会确切理解为什么，或者你推动指标的方式可能与你作为一家企业的战略并不挂钩。

所以第一类风险是理解风险（understanding risk）。如果你不知道如何推动某个特定指标，那正确的目标应该是设定一个增进理解的目标，而不是去推动那个指标。一旦你理解了如何推动该指标，你的团队可能能够很好地执行，也可能不能。它可能无法执行那些实验，可能没有执行所需的资源。那这时候你可能想设定一个执行目标——比如我们本季度要完成 20 个实验，如果你能完成这 20 个实验，你就知道你的执行非常好。即使这些实验不奏效，那也把这个前沿往前推进了一点。

最后最终的 frontier 是战略风险（strategic risk）。我们理解了如何推动留存，或者我们认为理解了。我们会做一系列事情来推动留存，然后要么我们会发现我们的理解是正确的，这种情况下我们可以更多地拉动那个杠杆；要么我们发现理解不正确，这种情况下我们需要回到理解阶段，并据此设定目标。

Lenny： 这真的很有意思。你用的术语是”理解前沿”，对吧？

Ravi Mehta： 对，没错。

Lenny： 你刚才描述了四种类型的目标。能再说一遍吗？

Ravi Mehta： 好。四个类别是，首先是理解风险，就是我们有一些想做的事情，但不太理解杠杆在哪里。然后是依赖风险（dependency risk），就是我们理解我们认为的杠杆是什么，但可能没有推进所需的工具。接下来是执行风险（execution risk），就是我们拥有所需的全部资源，有一个很强的假设，然后可能能也可能不能针对这些假设执行。最后一个就是战略风险，就是我们有一个假设，但结果可能发现那个假设是错误的。

Lenny： 天哪。我本想转到另一个话题的，但我想再深入聊聊这个，因为它真的很有趣。很多人的产品经理领导不会说”好，让我们花一个季度来理解能不能推动这个指标”。这似乎需要一个非常成熟的领导者才能接受这一点，或者说花一个季度做这件事本身是不是就不是一个好主意？你怎么看待不去设定一个推动人们关心的指标的目标，而是专注于理解、把这个理解前沿往前推，与推动人们实际上希望你推动的指标之间的取舍？

Ravi Mehta： 可能按照公司的运作方式和当前重点，你这个季度确实需要承诺一个提升留存率的目标，或者提升关注者数量的目标，诸如此类。有两种做法。一种是你承诺这个目标，然后三个月后听天由命，做一堆你觉得可能能推动杠杆的工作。另一种做法是，通往那个特定目标的旅程，我们可以把它拆解开来。一开始先花几周时间做理解——跟客户交流，做一些分析，形成一些真正扎实的假设。然后基于这些假设，开始搞清楚需要执行什么来验证它们。接着就可以去执行并验证这些假设。

根据季度中事情在哪个环节开始偏离轨道，你就能感知到那个理解前沿在哪里。当你没有达成目标时，你可以回到团队或领导层说：“我们没达成目标，但我觉得我知道原因。这是我们在季度内做的事情，这是事情开始偏离轨道的地方。这是我建议下个季度我们承诺做的事情，这样我们就能更有把握地达成目标。”

领导层始终是结果导向的，但他们也希望对你能否达成那些结果有充分信心。所以如果你能清晰地传达你的学习成果，并提供一条让他们建立信心的清晰路径，他们往往会比你预想的更加包容。我觉得那种总是要设结果导向目标的冲动，其实只是”我们希望你推动数据变化，希望你朝这个方向思考”的简写。这不意味着你可以在缺乏深入理解和精细打磨执行流程的情况下去做这件事。所以用这种方式来处理，可以帮助你改变对话的方式，让讨论更加具体。

Lenny： 你也有一篇关于这个话题的文章，对吧？

Ravi Mehta： 对，我在 Reforge 博客上写过一篇文章。标题我记不太清了，好像是”用 NCT 代替 OKR 来设定更好的目标”。

Lenny： 好的，很酷。如果你的老板不认同你说的，可以把那篇文章分享给他看看能不能改变他的想法。你第一个观点是说最差的情况就是听天由命——你知道自己的理解前沿还没那么远，但还是设一个有雄心的结果导向目标，然后期望一切顺利。但现实是这可能并不现实。

Ravi Mehta： 我觉得可以把它想成一个二乘二的矩阵。矩阵的一个轴是：我们是否达成了目标？另一个轴是：我们知道为什么吗？归根结底你想处在右上角的象限——既达成了目标，又知道为什么达成。有些团队处在达成了目标但不知道为什么的象限，眼下是好的，但迟早会出问题。另一件重要的事情是，如果你没达成目标，至少要确保你在理解为什么，或者至少在理解原因上有所进展。我觉得太多团队过于关注目标本身，反而对学习不够重视。

产品管理能力模型

Lenny： 好的，最后一个话题——产品管理能力模型。这是你很久以前写的一篇文章，也是你在网上众多作品中我分享最多的一篇。我现在要把这张图调到屏幕上——再次安利一下，去 YouTube 或 Spotify 上看视频版。你能谈谈这是什么吗？为什么产品经理（PM）用这个视角来思考自己的职业发展很重要，以及总体上理解一个优秀 PM 由哪些要素组成？

Ravi Mehta： 当然。这个框架是我们 Tripadvisor 时开发的。我加入 Tripadvisor 的时候，公司刚上市不久。作为一家新上市公司，公司希望快速扩张各个团队，包括产品团队。我们发现从行业内招聘产品经理——当时我们在波士顿——在波士顿招一个经验丰富的 PM 需要三到六个月，这个周期太长了，无法满足我们在团队规模和编制方面的增长目标。

于是产品负责人提出了一个叫”产品轮岗项目”的项目。我们会直接从商学院和本科毕业生中招人，让他们进入第一个产品岗位，不管他们之前有没有产品经验。他们会经历两年的轮岗——四次为期六个月的轮岗，分别参与从零到一的团队、增长团队或基础设施团队。目标是大约两年内让一个人体验产品管理的各个不同方面，最终使他们具备成为高级产品经理所需的技能。

因此，我们非常需要清晰地定义什么是产品管理，如何帮助人们识别成为有效 PM 所需的技能，并为他们提供培养这些技能的计划。这就是这个框架最初诞生的由来。

这个框架包含四个领域的 12 项能力。这些能力对 APM 和 CPO 来说都是一样的，我可以稍后谈谈它们在人变得越来越资深时如何变化。但无论你处于产品管理旅程的哪个阶段，这 12 个领域都同等重要。具体内容可能变化，但整体结构是相同的。

第一件非常重要的事情是产品执行（product execution）。PM 需要能够与他们的团队一起构建产品，这可以分解为三个子能力。第一个是功能规格（functional specification），也就是与团队协作定义 PRD 或功能规格文档的能力，明确要构建什么。第二个是产品交付（product delivery），即与工程、设计及其他团队协作，把规格说明变成可运行的产品。第三个部分，我以前叫质量保证（QA），现在改为产品质量（product quality）——确保你构建的东西是高质量的，不仅从技术角度，还要从设计角度、可用性角度和业务角度。

归根结底，成为一名成功的 PM 的基础就是能够执行。这对 APM 如此，对 VP 或 CPO 同样如此。APM 会从日常个人贡献的角度来思考产品执行。但 CPO 会从系统角度来思考产品执行——他们创建的系统使团队能够定义出优秀的规格说明、高效地交付产品、完美地执行，并交付质量标准非常高的产品。

第二个领域是客户洞察（customer insight）。除了能够构建产品之外，你还需要理解客户，这样才能决定构建什么。这里包含三个子项。第一个是数据素养（fluency with data），即利用手边所有数据来做出关于客户需求的决策的能力。第二个是客户之声（voice of the customer），即与客户进行对话的能力，使产品经理能够作为客户代言人贯穿整个公司，同时也是产品内部的客户代言人。

第三个是用户体验设计。这就回到了我们之前关于线框图的讨论。我认为，成为一名真正优秀的 PM 的一个基本素养，就是能够非常细致地思考用户体验，确保你不只是在定义功能，而是真正清楚地理解这些功能如何转化为用户体验。这里非常明确地是用户体验设计，而不是用户界面设计，因为你的产品体验可能各不相同。如果你在构建 API，那么你的体验实际上就是 API 规格。如果你在构建 ML 模型，那么你的体验可能是训练模型，或者是你用来评估这些训练模型效果的其他系统。所以这是一项可以广泛应用于许多不同产品角色的技能。

产品战略

第三个板块是产品战略，它分解为三个部分。第一个是能够对业务结果负责。从把产品理解为发布功能，转变为驱动业务结果，这一点非常重要。这项能力关乎理解你的产品或你正在开发的功能如何嵌入到业务中并驱动业务价值。第二个能力是产品愿景和路线图制定。这是把你正在为产品做的各项工作整合为一个连贯的愿景和路线图的能力，使你能够随着时间的推移朝着产品战略和公司战略推进。第三个是战略影响。就像产品路线图是一系列功能的序列一样，我把战略影响看作一系列业务结果的序列。所以最初要真正专注于对业务结果负责并交付业务结果。但最终真正重要的是，这一系列业务结果是否推动了战略前进，是否帮助你对该战略产生了影响？

领导力

第四个也是最后一个板块，全部都是关于领导力，即影响他人。第一个能力是利益相关者协调，即能够与组织中所有不同的人合作，使他们围绕你所做的工作凝聚起来。第二个是团队领导力。这个能力实际上在你有直接下属之前不会发挥作用，但一旦你有了直接下属，能够帮助这些直接下属成为非常优秀的 PM 就是一项关键技能。最后一个，对 PM 来说始终非常重要的，是能够向上管理，从而赢得组织领导层的支持。

Lenny： 太厉害了。产品管理这个工作也太疯狂了吧。

Ravi Mehta： 确实很疯狂，不是吗？

Lenny： 你看看这个东西。

Ravi Mehta： 把这些都做好，你就没问题了。

Lenny： 天哪。这是一个令人难以置信的框架。我从未见过一个更简洁、更优雅、非常清晰、易于消化和分享的关于 PM 角色的版本。如果有人正在寻找灵感，想在公司内部定义 PM 角色、搭建职业阶梯，我总是会把他们指向这个框架，我们一定会在节目笔记中附上链接。谢谢你做了这么出色的讲解。这里面信息量很大。

Ravi Mehta： 当然。在我的网站上，我有一个可下载的工具包，里面有用于自我评估的工具，对每个能力都有更详细的说明，还讨论了一些不同的原型。你会发现某些风格的 PM 拥有特定的能力集群。如果你是增长 PM，你可能有特定的侧重，可能包括对数据和结果责任的大量关注。如果你更偏向产品发现或产品创新型的 PM，你可能拥有一套不同的技能。所以能够将自己映射出来，会帮助你理解你想在哪里成长，以及哪些类型的角色最适合你。

Lenny： 顺便推广一下你的网站吧。他们具体在哪里能找到这些内容？

Ravi Mehta： 可以在 ravi-mehta.com 找到。M-E-H-T-A。

指数级反馈

Lenny： 顺便说一下，你有一个指数级反馈（exponential feedback）的概念，和这个框架有些关联，也部分涉及了为什么这对 PM 来说如此重要。你能谈谈这个吗？

Ravi Mehta： 当然。这是我们在产品领导力项目中讨论的内容。我认为对 PM 和产品领导者来说，最有挑战性的事情之一就是弄清楚如何成长自己、如何培养团队。而实现这一目标的一个关键方式就是反馈。给人们提供好的反馈来帮助他们了解如何成长，这一点非常重要。但问题在于——无论是一次轻松的一对一谈话，还是年度绩效评估，都是如此——人们提供的反馈往往非常表面化。它可能关注的是特定的症状，而不是根本原因。

所以这个框架可以提供帮助的一种方式是，我经常鼓励刚开始使用这个框架的人，只需逐项评估每个能力，将自己标记为需要提升、步入正轨或表现优异，就能快速了解自己的定位。你也可以请你的经理做同样的事情，五到十分钟就能完成。然后，你和经理达成共识的地方以及你们看法不同的地方，就会成为深入对话的触发点。

我认为这是提供指数级反馈的入口。我把指数级反馈理解为具有复利回报的反馈。如果你针对某个特定症状给某人反馈，或者针对某个战术层面的事情给反馈，他们在那一刻修正了它，反馈的结论就此发生、然后就消失了。但如果你帮助一个人理解导致那种情况的潜在行为，他们就可以专注于自我成长，也可以更有效地诊断自己的表现，这就会带来复利回报——他们会随着时间推移不断变得更好。

所以，把能力框架作为一个透镜来使用，可以帮助你跳出那种抽象的、表面化的反馈，进入对一个人可能需要改进的方面的非常具体的分类，我认为这触及了一个人可以成长的根本原因，最终带来更有效的、具有复利回报的反馈。

Lenny： 顺着这个话题，也许可以问最后一个问题。如果你的经理不擅长这个，没有给你这种反馈，你对如何从这样的人、导师或其他人那里获取反馈有什么建议吗？如果你的经理就是没有在扮演这个角色。

Ravi Mehta： 如果你身处产品岗位，有一件事是可以做的——请你的经理做这个练习并评估你。你的经理几乎肯定对你的表现有某种印象，只是不一定……如果他们没有主动做这件事，他们可能凭直觉就有判断。帮助他们把这些落在纸面上、变得更加具体，可以是开启对话的一个很好的方式。这是你可以做的一件事。

主动获取反馈的方法

Ravi Mehta： 第二件事是，我觉得很多时候人们不愿意给出反馈，是因为他们觉得那会显得冒犯。所以你可以主动邀请你的经理：“我真的很想提升自己，请随时给我反馈。你可以实时告诉我，不用斟酌措辞，我只想确保自己在进步。“和经理达成这个共识，允许他们给你反馈，会确保反馈的数量大幅增加——先从数量开始，最终才能到达质量。

Lenny： 听你说这些，我想起了 Jules Walter 几期前在这档播客里分享的建议——当你收到反馈时，不管内心感受如何，不管你是不是内心在崩溃，都要非常热情地说：“非常感谢！这真的很有帮助。”

Ravi Mehta： 这点非常关键，因为你这样奖励了对方给你反馈的行为——即使内心很痛——然后他们下次还会愿意这样做。

Lenny： 对。在我们进入非常精彩的快问快答环节之前，还有什么想聊的或者想分享的吗？

选择性微观管理

Ravi Mehta： 我经常听到从产品经理转向领导角色的人面临的一个挑战是，他们担心对团队进行微观管理。我观察到首次担任领导角色的人通常有两种失败模式。第一种是确实进行了微观管理，不给团队成员应有的自主权去探索前进方向。这有两个问题：一是会让对方觉得你不信任他们；二是这会限制你能管理的团队规模，因为你只能在有限的人身上这样做，超出这个范围你自己的精力就耗尽了，通常也就几个人。所以这是一种失败模式——把自己的第一批直属下属当作自己的延伸。

第二种常见的失败模式是完全放手的领导方式。领导者信任新人，给了他们很大的自主权，但同时没有给他们所需的上下文。这个人也许能成功，但实际上缺乏引导其努力的护栏和框架。所以我认为正确的解法是——其实微观管理并不是一件坏事。科技行业一些最具创新力的领导者就是出了名的微观管理者。Steve Jobs 是微观管理者，Elon Musk 是微观管理者，Mark Zuckerberg 也是微观管理者。作为产品构建者和产品创新者，细节至关重要，有时候你需要深入到某个按钮上的文字应该怎么写，而且你可能对此有强烈的看法。在那个层面参与是完全没问题的。

我经常鼓励产品领导者这样看待自己变得更资深的过程——不是越来越只关注高层战略，而是扩大自己的动态范围。一个 CPO 并非从不考虑战术问题，而是他们花大量时间在战略上，同时也能深入到具体问题。所以我喜欢用我和辅导的产品领导者使用的一个矩阵框架来思考这个问题。你的理想目标是以可扩展的方式领导团队，也就是你对团队的方向非常有信心，同时团队拥有向那个方向前进的自主权。

还有一种非常有效的领导方式，就是选择性微观管理——如果你对团队前进的方向没有信心，正确的做法不是放手让他们继续朝错误方向走，而是进行微观管理，但要以非常战术化、非常临时性的方式进行，帮助他们理解什么是正确的前进方向，然后你再抽身。而两种失败模式是：如果你完全放手，让团队偏离轨道，这种放手式领导在短期内可能感觉很舒服，短期内帮你避免了微观管理，但最终会导致团队到不了他们应该到的地方。

然后我们通常理解的微观管理，我更愿意称之为”微观误管理”——你觉得自己对团队的工作没有掌控感或信心，团队觉得自己没有自主权，看不到明确的终点，最终领导者和团队都很沮丧。所以我认为两种真正有效的领导方式是：可扩展式领导——团队有自主权，你有信心；以及选择性微观管理——在短暂的时间内你可能拿走团队的一部分自主权，把他们引回正轨，但目标始终是回到可扩展式领导的状态。

Lenny： 我非常喜欢这个话题，感觉这可以单独展开聊很久。沿着这条线快速问一个问题——你把它叫做选择性微观管理？

Ravi Mehta： 对。

Lenny： 你有没有什么经验法则来界定这在实践中意味着什么？比如每 10 个决策中大概有 1 个你会推动他们往你需要的方向走？你怎么判断什么是”选择性”的？或者根据你的经验？

Ravi Mehta： 我认为关键在于，当你发现问题时，要在那个时刻进行适度深入的干预。用一切必要的手段帮助团队回到正轨，包括你可能需要对团队正在做的决策进行非常细致的介入。但在这样做的过程中，你要把你用来帮助团队做决策的框架也教给他们，让团队理解这个框架。随着时间的推移，目标是把你主动介入引导团队决策的做法，替换为团队自己拥有一个真正理解的框架，这样他们就能做出与你认为正确方向一致的决策。最终的成功状态是——你给了足够的框架，团队有足够的自主权，他们得出的答案甚至比你亲自做的还要好。这会让团队获得巨大的成就感，也让你作为领导者对团队能力产生极大的信心。

Lenny： 明白了。对，这让我想到作为产品领导者，大部分时候你需要推动团队去做你认为是正确的事，偶尔让他们犯错、从中学习。但不是反过来——不是”让他们随便犯所有错，偶尔纠正一下”。毕竟如果他们浪费了时间和资源却失败了，担责的是你。所以你的工作就是确保他们朝着正确的方向前进。

对齐与信心框架

Ravi Mehta： 在产品领导力中我们还讨论过另一个与这个话题相关的框架。作为与经理共事的人，你一直在追求两件事：一是你与经理的对齐程度，二是经理对你的信心程度。如果对齐度很高、信心也很高，你就会获得全力支持。但可能存在对齐度不高的情况——你想走一个和你经理不同的方向——但如果你有他们的信心，你就会获得他们的许可和支持去走那个方向。

Ravi Mehta： 所以，时刻清楚自己在这个雷达上的位置，对于理解你手里有多少”筹码”来推动事情朝你认为是正确的方向前进，非常有帮助。如果你既没有领导的信心，又和他们不对齐，那可不是成功的配方。其中之一必须改变——要么你去做与他们方向一致的事，要么你通过行动赢得他们的信心，让他们相信你有能力另辟蹊径。

AI 在产品管理中的角色

Lenny： 这个框架很好。最后一个完全跑题、突如其来的问题。我笔记里记着你一直在辅导工作中做一些 AI 相关的事情。所以我想问你，你认为 AI 将如何与 PM 以及职场中的专业人士协作？你到目前为止在这方面有什么发现？

Ravi Mehta： 当我们创办 Outpace 时，我们就知道 AI 会持续进步，最终我们会想把 AI 作为一种方式来增强教练、帮助他们更高效、更有效地工作。我们原本以为这是一个多年的旅程，会在未来的某个时点推进。但今年非常令人兴奋，OpenAI、Stable Diffusion、Midjourney 以及各种不同的模型都取得了巨大进展。

所以我们实际上大幅加速了围绕这方面的路线图。我们有一个有趣的机会在产品中使用 AI——Outpace 与其他辅导平台的不同之处之一在于，我们同时提供内容和教练。每周学员会完成一个 20 到 30 分钟的会话，包括一段简短的音频课程，然后是互动练习，帮助学员把课程中学到的东西应用到实际工作中。

我们拥有的一个优势是，Outpace 的所有参与者都会提供文字内容——他们对非常具体的问题给出非常具体的回答。我们利用这些内容来提示 OpenAI，为教练生成建议。教练可以进入系统，说”帮我生成一个建议，告诉我应该给这条回复什么反馈”，然后根据自己的了解对建议进行调整。最令人惊叹的是，我们能够通过使用不同类型的提示词来模拟不同的领导风格。比如我们可以生成非常行动导向的建议，提供下一步行动清单；也可以生成更有同理心的建议，关注对方的感受；还可以生成更具探究性的建议，提出追问；以及信息性的建议，提供框架和建议。

所以这项技术已经发展到相当了不起的程度。我知道我们现在正处于一个有趣的时期，接下来事态如何演变会很值得观察。我觉得最有趣的一点不在于 AI 取代人，而在于 AI 作为一种增强人类、让人更高效的方式。我认为我们会在图像生成和文本生成方面看到很多这样的例子——与其说是 AI 完成所有工作，不如说是 AI 提供一个非常好的起点。

Lenny： 我很喜欢这个想法——人们对产品未来五到十年的发展方向有愿景，结果这个愿景这么快就实现了。这感觉一定很棒，但紧接着你就得重新思考：“天哪，以这个速度，我们新的未来愿景是什么？”

Ravi Mehta： 确实非常令人兴奋。我很久没有对科技这么兴奋了。我们知道需要转型来更深入地拥抱这项技术，而这完全合理，与我们已经在做的事情非常契合。

闪电问答环节

Lenny： 好了，现在进入我们非常精彩的闪电问答环节。我有六个问题，我会快速过一遍，你想到什么就直接说。准备好了吗？

Ravi Mehta： 准备好了。

Lenny： 好的。你向他人推荐最多的两三本书是什么？

Ravi Mehta： 我很喜欢《Hooked》。我知道这本书几年前就出了，但我发现那个模型对于思考如何打造有吸引力的产品真的非常有效。我也很喜欢《Working Backwards》。我认为亚马逊构建产品的方式非常独特，而且他们对这个流程中什么重要有非常鲜明的立场。能有一个非常详细的窗口来了解这些做法太棒了。我一直很好奇它是怎么运作的，而《Working Backwards》很好地帮助我理解了这一点。

Lenny： 对此感兴趣的听众，我们之前邀请过 Ian McAllister 来播客详细聊过这些内容。所以如果你对《Working Backwards》感兴趣但不想读那本书，有一期播客适合你。说到播客，除了你现在正在录的这档，你最喜欢的播客是什么？

Ravi Mehta： 我最喜欢的之一是 The Ezra Klein Show。我喜欢他讨论各种不同的话题，而且他经常有反主流的观点。他最近刚发了一期对 AI 持怀疑态度的节目，我非常不同意其中的观点，但从不同角度思考这件事确实很有意思。

Lenny： 关于这档播客我收到过最好的夸奖之一，是有人告诉我他们只听两个播客，就是这两个，每次早上去散步时总是要二选一。

Ravi Mehta： 几个月前你和我聊过，其实我也是这种情况。我一直听你的播客，也听 Ezra Klein 的，然后还有几个其他的混着听，但遛狗时反复回去听的，就是这两个。

Lenny： 太梦幻了。

Ravi Mehta： 谢谢你的邀请。

Lenny： 哎，还没结束呢。下一个问题。最近最喜欢的电影或电视剧？

Ravi Mehta： 我非常喜欢《Andor》。大约一周前刚看完。我觉得它不仅是一部优秀的星战作品，更是一部出色的科幻作品。最近很多科幻变得千篇一律、非常反乌托邦。而这部作品是对当下现实的有趣映射，对未来的可能性有非常深刻的思考，对宇宙的扩展也做得很好。所以它在很多层面上都很出色。

Lenny： 我也太爱《Andor》了。强烈附议。你最喜欢问的面试问题是什么？

Ravi Mehta： 我最喜欢的面试问题是，告诉我一个你喜爱的产品。这个问题我可以让它持续五分钟，也可以让它持续六十分钟。这通常是我在筛选面试中问候选人的第一个问题。我非常刻意地使用”喜爱”这个词。我想看到他们生活中真正被吸引、真正投入、愿意用”喜爱”来描述的产品。这帮助我很大程度上理解他们看重什么。然后我会问一系列问题：你为什么喜爱它？你认为其他人为什么喜爱它？你希望它在未来有什么变化？为那个产品选一个你想开发的功能。你为什么认为那是个好功能？你会如何衡量那个功能的成功？

Ravi Mehta： 我用这个问题已经很多年了。它真的是一种非常好的方式，帮助你理解一个人具备的产品直觉，也能更好地了解这个人。当有人选择实体产品时，总是很有意思——你能看到他们的兴趣爱好和生活方式。

五个 SaaS 产品推荐

Lenny： 你在公司或团队中常用的五个 SaaS 产品是什么？

Ravi Mehta： Airtable 非常棒，是一个极其强大的工具。我们刚刚用 Airtable 重建了会计系统。Webflow 我们也在不断使用，它真正改变了我们思考产品构建的方式。我们现在会问，这件事需要写代码吗，还是可以用 Webflow 做出来？我们还在用 Superhuman。我一天大部分时间都在 Superhuman 里度过。它是一个极快的邮件客户端，所以我很高兴团队里有它。团队中很多人现在在用 Descript 来编辑视频。他们发现这个工具比之前的音视频编辑解决方案好用太多。另外，我一直很喜欢 Balsamiq。我大概用了十年了，每当我遇到用户体验方面的问题卡住时，我就会进去创建一些线框图，总是能帮到我。

Lenny： 我们在这个播客上也用 Descript——我也不知道该怎么发音。强烈推荐。最后一个问题。你正在创建一家帮助人们找辅导的公司。对于那些正在和潜在辅导沟通、试图判断是否匹配的人，你有什么建议？他们应该问些什么？

Ravi Mehta： 我觉得有一个问题非常有帮助：告诉我你最引以为豪的那个客户。他们当时面临什么挑战？你是怎么帮助他们克服的？当然，对方不需要透露任何保密信息。但我觉得这个问题妙在，它能让你深入了解对方看重什么。你能看到他们的骄傲来自哪里，了解他们与被辅导者互动的方式。然后你就可以判断，这是否与你在辅导中寻找的东西相匹配。

结束语

Lenny： Ravi，这次对话完全达到了我的期望。我学到了很多，也聊得很开心。最后两个问题。大家如果想在网上找到你、了解更多，去哪里找？听众可以怎么帮到你？

Ravi Mehta： 我的创业公司叫 Outpace，可以在 outpace.co 找到。我们发布了很多免费资源。我们刚刚发布了一份你帮我们做的资源，Lenny，叫”Unlock Your Product Manager Potential”。我们还有一个问答服务，你可以向辅导提问。Outpace 的目标是让更多人体验到辅导，无论是在主动的辅导关系中，还是仅仅与辅导进行一次简短的对话。所以欢迎来 outpace.co，这对我们很有帮助，希望对你也很有帮助。另外，如果你想关注我，我在 LinkedIn 上，你也可以在 ravi-mehta.com 读到我的文章。

Lenny： 太棒了。Ravi，再次感谢你的到来，我们会在节目说明中分享你提到的所有链接。再次感谢。

Ravi Mehta： 好的，非常感谢你的邀请。这次对话很棒。

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

术语表

原文中文
AirtableAirtable（低代码平台，保留原文）
Andor《Andor》（星战题材剧集，保留原文）
APMAPM（Associate Product Manager，保留原文）
BalsamiqBalsamiq（线框图工具，保留原文）
blueprint蓝图
Brian BalfourBrian Balfour（Reforge CEO）
coaching辅导
conviction-oriented approach信念导向的方式
CPOCPO（Chief Product Officer，保留原文）
customer insight客户洞察
dependency risk依赖风险
DescriptDescript（音视频编辑工具，保留原文）
entrepreneur in residence / executive in residence驻场创业者/驻场高管
execution risk执行风险
experimental-oriented approach实验导向的方式
fluency with data数据素养
freemium免费增值
frontier of understanding理解前沿
functional specification功能规格
Hooked《Hooked》（产品设计书籍，保留原文）
Ian McAllisterIan McAllister（前亚马逊高管，保留原文）
latency延迟
NCTNCT（保留原文）
Nintendo任天堂
outcomes结果
OutpaceOutpace（辅导平台，保留原文）
outputs产出
PRDPRD（Product Requirements Document，保留原文）
product delivery产品交付
product execution产品执行
product quality产品质量
product strategy stack产品战略栈
roadmap路线图
selective micromanagement选择性微观管理
Sony索尼
strategic risk战略风险
SuperhumanSuperhuman（邮件客户端，保留原文）
The Ezra Klein ShowThe Ezra Klein Show（播客节目，保留原文）
TripadvisorTripadvisor（旅游平台，保留原文）
understanding risk理解风险
velocity速率
voice of the customer客户之声
WebflowWebflow（网站构建平台，保留原文）
wireframes线框图
Working Backwards《Working Backwards》（亚马逊工作方法论书籍，保留原文）

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