产品运营终极指南 | Melissa Perri 和 Denise Tilles

Melissa Perri + Denise Tilles 2023-11-16

产品运营终极指南 | Melissa Perri 和 Denise Tilles

Melissa Perri： 你是想招聘一万个产品经理，让他们都把这些事情挤在工作间隙做，然后只花30%的时间专注在战略工作上？还是想让他们把大部分时间都用在战略工作上，然后围绕他们组建一个产品运营团队，打造共享系统和基础设施，帮助他们更好地工作？

嘉宾介绍

Lenny： 今天的嘉宾是 Melissa Perri 和 Denise Tilles。这是罕见的双嘉宾一期。Melissa 和 Denise 是一本出色新书的作者，书名叫《产品运营：成功的公司如何大规模打造更好的产品》（Product Operations: How Successful Companies Build Better Products at Scale）。Melissa 在产品管理领域是一位传奇人物。她是基础手册《逃离构建陷阱》（Escaping the Build Trap）的作者，经营着一个名为 Produx Labs 的产品管理培训机构，在哈佛大学教授产品管理，并与数百家公司合作优化其产品管理职能。Denise 是一位产品领导者、教练和顾问，帮助公司进行产品愿景、战略和执行方面的工作，并与 Melissa 一起在 Produx Labs 共事。

在我们的对话中，我们非常深入地探讨了产品运营这个正在崛起的角色。正如你将听到的，过去几年里，这个角色几乎从不存在发展到大约一半的规模化科技公司至少拥有一名产品运营人员。这个新角色可能是当前产品管理领域变化最大的事情。这次对话之后，我确信这是一件好事。

我们将聊到这个角色具体做什么，它与产品管理和项目管理有何不同，招聘第一位产品运营人员时应该看重什么，如何推行产品运营职能，为什么产品经理不应该害怕这个角色以及你的生活会因此变得多么美好，还有她们在一家大公司推行产品运营职能的案例研究，以及更多内容。接下来，请收听 Melissa Perri 和 Denise Tilles。

（跳过赞助商广告）

Lenny： Melissa、Denise，非常感谢你们来参加节目。欢迎来到播客。

Denise Tilles： 谢谢。

Melissa Perri： 谢谢邀请我们。

Lenny： 你们是我播客上第二个双人嘉宾组合。Melissa，这是你第二次做客节目了，你们俩出了一本新书，我手边就有一本，叫《产品运营：成功的公司如何大规模打造更好的产品》。今天我想利用我们的时间，帮助大家从各个角度全面理解产品运营这个角色，尽可能在一个小时内讲清楚。怎么样？

Melissa Perri： 听起来很棒。

Denise Tilles： 好的。

Melissa Perri： 开始吧。

产品运营角色的普及程度

Lenny： 太好了。第一个问题，先为这个角色设定一点背景——目前这个角色有多流行、多普遍？我快速浏览了一些优秀的公司和非常成功的公司，似乎每一家现在都有产品运营的岗位。OpenAI、Uber、Stripe、Ramp、Deal，这些只是我看到的几个。你们观察到的也是这样吗？大家应该如何看待这个角色现在有多流行、多普遍？

Melissa Perri： 我觉得在过去几年里，我们确实看到了产品运营开始蓬勃发展。它最早就出现在你提到的一些大公司，比如 Uber。Uber 的产品运营负责人、也是开创这个角色的人 Blake Samic，是我们书中的案例研究对象，他后来也在 Stripe 做这件事，现在在 OpenAI 做。所以你提到这三家公司还挺有意思的，因为那正是 Blake 做的。我们看到产品运营从一个大家只是私下议论的东西，发生了很好的转变。我知道当我在2018年写第一本书《逃离构建陷阱》的时候，我在里面提到了这个概念，因为当时我们刚刚在 Athenahealth 开始做这件事。

我当时就看到，在尝试构建一个完整的产品管理职能时，尤其是在规模化阶段，这是一个非常大的问题。我们有365个产品团队。我们当时在思考这一切如何整合到一起，而对我来说，产品运营是其中的关键组成部分。所以当我最初把它写进那本书的时候，很多人说：“哦，这是什么？我觉得我们需要它。我们需要更多吗？“这也促使我们开始写这本新书。从那以后，我看到越来越多的公司站出来，要么是将此前就开始的、更加成熟的产品运营团队进一步发展，要么是现在正式引入这个职能。

Lenny： 也许只看科技公司的话，如果要你给出一个大致的比例——那些有趣的、快速增长的、超高速增长的创业公司中——你能给出一个大概百分之多少已经拥有产品运营人员的数字吗？

Melissa Perri： 我得说我们没有一个非常确切的数字，但我们确实观察到了一些趋势。让我们以我比较了解的一个样本来说。当我在教 CPO 加速器课程时，当我教这些学员群体的时候，在每期20到25人中，我估计至少一半的人有某个人在做产品运营相关的工作。可能还不是一个成熟的职能，可能只有一个人在做，但至少一半的公司已经有人在做相关的事情了。

Denise Tilles： 这是一个很好的衡量标准。我为 Produx Labs 和 Melissa 一起教授一门产品运营大师课，这很有意思。我会做一些课前调研，了解学员在产品运营方面处于什么阶段。当我们在2020年开始开设这门课的时候，大约60%的学员是”对产品运营感兴趣”。随着时间的推移，这个比例明显下降了，人们开始引入这个角色，他们只是想了解优化它的最佳方式。所以我估计，现在大概有60%的人已经有了这个角色，然后想了解如何优化它。

产品运营的兴起时间

Lenny： 你们有没有感觉到这个趋势是从什么时候开始拐点上升、变得这么普遍的？我做产品经理的时候，根本没有什么产品运营人员。所以对我来说，了解这个角色的崛起非常有趣。我知道可能没有一个具体的日期，但听起来可能是在你上一本书出版之后。这个角色是在什么时间段成为一件事的？是你提到的那位现在在 OpenAI 的人开始推广它的吗？

Melissa Perri： Blake，我想，是早期最积极谈论产品运营的人之一，他做了很多推动产品运营、向人们介绍它的工作。这很好。我知道 Pendo 也在更多地谈论产品运营，我就是从那时开始注意到它在逐渐升温的。我想大概是2019年左右，Pendo 开始谈论产品运营。所以大概是在我的书出版之后不久，我看到越来越多的人开始讨论它，现在他们在琢磨，“我们要不要标准化？我们需要什么？在组织中它具体应该长什么样？“但我觉得，到现在大概已经有五年左右的时间，能听到人们在实时地做这件事了。

Lenny： 很棒，听起来可能也就是最近几年它才真正开始爆发式增长。我们大约一年前请过 Pendo 的 Christine 来播客聊产品运营。所以这期是对那期内容的一个很好的延续。在我们讨论什么是产品运营、它的职能是什么之前，你们认为一家公司拥有产品运营角色最大的好处是什么？以及，什么信号表明你大概应该认真考虑引入一个产品运营人员，开始在这个领域投入了？

Denise Tilles： 核心就是帮助产品经理专注于他们真正被雇佣来做的事情——战略性工作。我在运营端管理团队的角色中，以及 Melissa 也是一样，越来越多地看到产品经理在承担数据方面的工作——采集数据、做实施，就为了让数据能跑起来，他们要花掉20%、30%的时间。那么，如果他们被充分赋能，拥有所有这些优质的输入，真正专注于公司增长、实现价值、达成公司的规模化目标，那会是什么样子？所以归根结底就是帮助他们专注于他们被雇佣来做的事。

Lenny： 再说一次，我做产品经理的时候，根本没有产品运营人员。读了你们的书之后，我发现基本上产品运营做的所有事情，都是产品经理历史上一直在做的事。对我来说，把所有这些东西交出去、放到别人的盘子上，是有点可怕的。理想情况下当然觉得，“哦，太好了，我不用做这些事了，我可以专注在我真正感兴趣的事情上。“但同时也会有一种新的恐惧，“哦，别人要来接手这些事情了，也许他们做得没我好。还有新的流程我要去适应，新的沟通链路要建立。“那么，对于一个刚开始接触产品运营概念的产品经理，面对这种恐惧——“天哪，我的工作要变得很奇怪了，多了个新搭档要天天打交道，以前这些都是我自己做的”——你们最有力的说辞是什么？你怎么让一个产品经理对此感到兴奋？

Melissa Perri： 产品运营不会夺走产品经理的决策权。它的作用是为产品经理提供信息支撑。如果你衡量自己作为产品经理是否成功的标准是”嘿，我自己写 SQL 查询，我自己花50个小时去安排所有这些客户访谈和通话”，那在我看来这些都是非常偏运营流程类的工作，而不是能帮你做出产品决策的工作。这就是为什么我们要关注产品运营团队，因为我看到产品经理们在桌子旁边挤时间做这些事情——我也是过来人。我之所以对这个话题感兴趣，是因为在我产品经理生涯早期在 OpenSky 的时候，我得去学 MongoDB 才能从数据库里取数据。我当时坐在 MongoDB 的课堂上学怎么搞这个。我懂 SQL，但那时我们用的不是 SQL 数据库。我得去学 MongoDB，这样就不会总去打扰工程师，能自己衡量我的产品和功能到底有没有做对。

我花了大量时间在这上面，而不是花在做好功能开发、理解客户、与开发人员合作、搞清楚我们到底要构建什么上。相反，我在外面学这个编程语言——顺便说一句，之后再也没用过，再也没用过。对我来说，这就是产品运营要从产品经理身上拿走的东西。

但我不断从产品经理那里听到的是，“我太忙了，我没时间把该做的事做好。我光忙着安排客户访谈就焦头烂额了，“或者”我光是从系统里导出数据就耗尽精力了。我每天都在为获取做好本职工作所需的东西而奔波，以至于我没有时间去做好本职工作。“而这正是我们想要帮他们解决的问题。所以我觉得不必害怕产品运营的介入。它不应该是增加额外负担的东西，它应该是某种更解放的力量，帮你从所有那些繁杂事务中解脱出来。

Lenny： 这个说辞很有说服力。我一直觉得产品经理这个角色简直疯狂，事情多得离谱，所以大家总是在倦怠和焦虑。你确实有太多事情要做。所以我完全理解为什么会出现这种情况，也理解为什么现在会发生这种变化。我很高兴你们在帮助人们弄清楚如何真正把它做好。我们接下来就深入聊聊这个角色到底是什么。我觉得这是一个很容易让人困惑的角色。很多人听到产品运营，但每个人对它的理解都不一样。也许有研究综合，有一些数据相关的工作。那么，最简单地理解产品运营人员的一般性一致职能是什么，他们能为公司做什么？

Denise Tilles： 我们的思考框架围绕书中谈到的三大支柱来组织。第一个是业务与数据洞察，偏量化的一面，确保产品经理拥有所有这些用户活跃度和收入方面的输入，从而做出明智的决策。第二个是客户与市场洞察，偏质化的方面。我们之前聊到过一点，关于找到合适的人来交流，确保你不仅仅是在跟一个客户对话。第三个支柱是流程与实践。所以基本上就是围绕这几个领域展开，具体取决于你们公司需要什么，以及最大的机会和挑战在哪里。

Lenny： 好的。三大支柱，就复述一下你刚才说的——产品运营的三大支柱：业务、数据与洞察；客户与市场洞察；以及构建产品的流程，帮助企业以更高效的方式运营产品构建过程。

Denise Tilles： 你说出来的感觉真好。是的。

Lenny： 我手里有笔记，你们书中正是这样描述的，写得非常清楚。这三大支柱中有没有一个你觉得最重要、影响最大的？还是说完全取决于业务和他们的需求，或者产品经理想做什么？你怎么看，我不知道，这三者中有没有一个可能是最重要的，还是说完全因情况而异？

Melissa Perri： 我们通常看到高增长公司从业务数据与洞察入手，确保他们能够真正监控自己正在做的事情，获取战略性的输入。我们看到大型公司和企业更多地向流程与治理方向倾斜，尤其是当它们正在进行转型的时候，因为它们缺乏运行良好产品实践的基础设施。大概可以这么说。它们通常刚起步，刚组建团队。比如说它们刚培训完产品经理，然后就在想，“除了培训产品经理之外，我们还需要做什么才能让这一切运转起来？“所以它们需要一个运营模型，而它们通常没有一个产品运营模型。

大型企业的流程与治理需求

Melissa Perri： 在这种情况下，它们甚至在考虑”我们如何跨组织做路线图，这样作为首席产品官或产品副总裁，我就能真正清楚地了解各个团队在做什么？” Jira 对此并不适用。你需要一个项目组合工具，把这些信息汇总成有意义的东西。这同样帮助我作为副总裁或首席产品官做出战略决策，也帮助我监控团队，理解”我们到底有没有把钱花在正确的地方？我们在做正确的事吗？“所以它们往往更偏向流程与治理这一侧，但这所有的一切都是为了能够快速做出战略决策，把好的产品推向市场。

Lenny： 这种区分方式非常实用。我来复述一下你刚才说的——对于高增长公司，在这三大支柱中，产品运营最能帮忙的通常是业务数据与洞察，帮助它们理解正在发生的事情、更快地做出决策，这很合理。而对于正在进行数字化转型的大型成熟企业，往往是在流程方面帮助它们，提升运营效率。那中间那个支柱，客户与市场洞察，有没有单独的一类对应场景，还是说它是分散在两边的？

Denise Tilles： 那是中间最模糊的一块。我在授课时会问大家对产品运营的印象是什么，从来没有人会想到这一块。所以我认为在许多公司，这恰恰是一个有待发展的领域。

客户与市场洞察

Lenny： 这一部分跟用户研究以及那个团队是怎么配合的？

Melissa Perri： 我们看到了那个团队做的很多工作。他们跟用户研究团队合作。现在，在一些组织中——这种情况在很多组织里存在但并非全部——产品部门同时管辖设计、用户研究和 UX，这时整个事情就变得很顺畅，因为你可能会有一位通常有用户研究背景的产品运营人员，来帮忙做我们讨论的这些事情以及客户与市场洞察这块工作，也就是把所有已经做过的研究——客户访谈、所有这些内容——汇总到一起，形成类似发现数据库（findings database）这样的东西。现在市面上有很好的工具比如 Dovetail，但你也可以自己搭建。核心就是把所有访谈或客户研究汇总起来，让员工可以查询，开始了解”我们已经知道了什么”，这样就不会重复做一堆研究。

同时这也涉及寻找愿意参与研究的用户。要确保让客户知道，“我们可能会联系你做客户访谈，这是原因。你愿意参与 alpha 和 beta 测试吗？如果愿意，具体流程是这样的。“如果我们能建立一个由愿意参与这些活动的客户组成的数据库，产品经理联系他们就会更容易——“顺便说一下，我们有一个 beta 版，你愿意试试吗？“客户知道这是什么，也对此有预期。他们了解研究者联系他们的节奏，用户研究人员也可以使用这个数据库。

需要指出的是，客户与市场洞察这块，负责梳理这些活动、搭建这些系统的人，通常不是做用户研究的同一个人。所以这不是要把用户研究从产品经理或用户研究人员手中拿走，而是帮助他们更高效地做这件事，让洞察更有效地传播到全公司，同时也帮助他们更好地触达用户、获取反馈。

产品运营如何打通销售与产品的信息流

这部分我们谈到的另一个内容是从销售和支持渠道获取定性洞察。我们经常听到销售团队这么说，这也是经典的”产品经理不重视我的反馈”的紧张关系。客户经理会说：“产品经理根本不听我的”，或者”我五个月前就告诉他们这几个客户有流失风险，因为存在某个问题。“但我们没有开发那些功能。客户与市场洞察这个职能要做的，就是帮助把这些信息有效地传达给产品团队。

然后它也帮助向销售团队反馈，“让我们在如何使用这些反馈上更透明一些。“这样我们可以通过战略层面来沟通。让销售知道我们在处理这些想法、解决客户问题方面进展到了哪一步。但通常情况下，大量定性信息被埋在组织的各种系统里——可能在 Salesforce 里，可能在客服工单里，可能在某人 Google 文档里的客户访谈记录中——我们要做的就是把这些信息从各自的孤立系统中提取出来，放到一个许多人都能获取的地方，让大家可以基于这些定性洞察进行学习和参考。

产品运营是产品管理的未来

Lenny： 大家总问我”产品管理正在发生什么变化？产品管理的未来是什么？“我总是说，“没什么变化。基本还是老样子。这个角色永远不会被完全定义清楚，会继续做一个奇怪的角色。“但我觉得，这可能才是真正的答案。产品管理正在发生的变化就是产品运营这个角色正在崛起，接管了很多产品经理不一定想做、也不一定擅长的事情，给他们更多空间去做真正想做的事。所以我觉得这很了不起。如果回顾一下时间线，你说五年前还没有真正意义上的产品运营。如今，大约一半的公司已经有了产品运营岗位。我猜再过几年这个比例会高得多。所以这真的很有意思。

Melissa Perri： 我也很兴奋。我觉得我们之前看到的情况是，正如你所说，产品管理长期以来就是一个模糊的角色，但现在我们正在标准化——产品经理到底做什么。不过我认为正在发生的是，产品经理变得越来越普遍，人们意识到这是一个对公司至关重要的角色，无论你是一家软件公司还是一家银行。在当今世界，我们基于软件构建业务，如果你不开发软件，你就落后了。随着我们推出的软件越来越多，产品经理没有时间再顺带处理这些事情了。在你还是个小创业公司的时候这还好。我以前也做过这些。就像我说的，在小公司的时候我还得去学 MongoDB，然后我们开始扩张，我承担的产品责任越来越多，我就觉得”我现在没时间去学 MongoDB 了”。正是在这种时候，人们开始倦怠，开始沮丧，就像你说的。

我们有越来越多的系统，越来越多的软件工具供产品经理使用，要跟踪的东西太多了。所以对企业来说，要么你雇佣一万个产品经理，让他们都顺带处理这些杂事，然后只有 30% 的时间专注于战略工作；要么你让他们大部分时间都专注于战略工作，然后围绕他们搭建一个产品运营团队，创造共享系统和基础设施，帮助他们更好地工作。

产品经理到底应该保留什么

Lenny： 我觉得这是一种非常有启发性的思考方式。我能想象正在听的产品经理听到你说”不用再学 MongoDB 和 SQL 了”会怎么想。不过不对，我觉得那样想也不对。他们确实应该学会 SQL，学会自己跑数据。但我认为这里的关键是，理论上当然很好，但随着规模扩大，你要处理的事情越来越多，就越来越难有时间去做这些了。你总会有其他更需要你去做的工作。所以理论上，产品经理能自己跑查询、自己做研究、搭建整套流程当然最好，但现实中会越来越难做到。

这让我想起很多公司试图推迟招聘产品经理，把这个角色交给工程师和设计师。我的反馈始终是，“只要他们愿意做那些通常不是他们喜欢做的事情，那当然没问题。“比如工程师未必喜欢主持开会、写一页纸文档、写策略文档、做会议纪要。我觉得这是类似的情况——当然挺好的，直到你发现自己并不想做这些，或者没时间做这些，而你还有本职工作要完成。

Denise Tilles： 那才是你的全职工作，你的 OKR 和目标真正围绕的是公司的成果，而不是”我今年写了 20 个脚本”。所以我们需要帮助他们专注于那些被期望交付的价值。

Melissa Perri： 我还觉得有趣的是，那么多人想做产品经理，直到他们意识到产品管理到底意味着什么。这种情况非常普遍，我在哈佛的 MBA 学生身上也看到了。我们有一整门课，让他们扮演产品经理。课程结束后很多人都放弃了做产品经理的想法。他们会说，“我没想到产品管理是这样的，我没想到要做这么多事情。“我觉得让他们感到吃不消的还有产品经理需要的频繁上下文切换。即使只考虑基本职责，你就已经要做太多不同的事情了——用户研究、跟设计师协作、跟开发协作、跟高管沟通、跟不同的利益相关者打交道。你需要不断切换上下文才能与所有人沟通协作，需要对各种不同的人产生共情，需要完成各种不同类型的任务才能做好这份工作。

然后你还得去找用什么模板来放你的路线图，而且这个模板很可能跟团队里其他 80 个产品经理用的都不一样，因为没有人站出来说，“我们就用这个。“对我来说，这类工作纯粹是在分散注意力。让一个产品负责人说”我们用这个模板”，这很难吗？不难。但如果这个产品负责人还要去培训其他 80 个人使用这个模板，确保它持续更新，确保格式正确，确保放在正确的软件里——这就是额外开销的来源。现在很多产品负责人就在做这些事情，而我们要做的是解放个体产品经理，同时也解放这些产品领导者。

我和很多 CPO、产品 VP 合作，他们……我看到他们根本没有在做战略。我问，“你们为什么不在做战略？“他们说，“我没时间。我在到处灭火，我在纠结路线图该用什么模板。“就像我说的，这并不难，他们知道该用什么模板。但想想看，如果你能把这件事交给别人，说”我要用这个模板，你去推广，去培训所有人，去找合适的软件，把这些都做了”——这就能解放那些领导者去做战略工作。毕竟，你花那么多钱请一个产品领导者，不就是为了这个吗？你花那么多钱请一个产品经理，不也是为了这个吗？所以对我来说，这些事情并非做不到，关键是我们有没有让合适的人来做这些事。

产品经理不应外包决策权

Lenny： 对于那些正在弄清楚自己到底还应该保留哪些工作的产品经理来说，哪些事情是他们应该自己留着、不应该交给产品运营人员的？

Melissa Perri： 他们不应该外包决策权。你永远不应该把决策外包给产品运营人员。这不是他们的职责。他们是”产品经理的产品经理”——我是这样理解的。所以他们的决策应该是围绕”如何在这里实现卓越的产品运营”，而作为产品经理，你不应该让他们替你做任何关于产品的决策，那不是他们的工作。如果他们跑来跟你说”你应该做这个功能”，那也不是他们该做的事。

所以做出实际决策，然后把这个决策落实到团队中去执行——这是产品经理应该牢牢把握的工作类型。虽然产品运营人员可以帮你指明方向，比如帮你找到客户，甚至帮你联系客户、发邮件邀请他们参加会议，把这些流程运营起来——最好能自动化——我很希望产品运营人员能把这类事情自动化。但用户研究是你自己要做的。你可以去找产品运营人员说，“我们发现这类问题”，也许他们能在组织内找到其他相关信息带给你，但他们不会替你阅读分析所有这些信息然后告诉你”你应该做这个”。

他们也不会是你说了”我做了这个构建决策，已经告诉团队了，团队已经开始工作了”之后，你让他们去监督开发人员确保按时交付的那种角色。不，他们不是项目经理，他们不会盯着你的开发人员看他们怎么构建东西、确保一切按时发布。那也不是他们的职责。他们也不会替你处理关于权衡取舍的棘手利益相关者对话——所有这些你都需要自己保持主导权，因为归根结底，作为产品经理，你的工作是产出成果，你需要确保自己在监控这些成果并朝着它们推进。你不想把这个责任外包出去。

Lenny： 我记了几条关于产品经理继续拥有的职责——当然，加个引号，没有人真正”拥有”任何东西——战略、愿景、优先级排序、资源分配、权衡决策、围绕权衡的艰难对话、利益相关者意见整合等等。在”产品经理继续负责的事情”这个类别里，还有其他我遗漏的吗？

Denise Tilles： 还有一大块我们没提到的——上市（go-to-market）。在连接这些团队方面，产品运营可以发挥很大作用，同时作为销售团队接触产品团队的第一联系人、产品团队接触销售团队的第一联系人，通过一些流程或方法上的改进来提升效率，帮助打破部门壁垒。

我现在正在仔细翻译这段播客片段。

Denise Tilles： 我目前正在合作的一家企业就面临这个巨大挑战——那是一家大型企业级公司。我们怎么打破各个部门、团队负责人之间的部门壁垒？所以核心就是，“这是我们推进的方式，这是我们在培训销售、培训产品团队时会用到的一些简单模板，“然后将其落地实施。在写书和做调研的过程中，这是一个反复出现的共同主题——我们采访的很多人都说上市（go-to-market）是一个很大的痛点。

Melissa Perri： 我觉得 Denise 说的还有一点很关键——产品运营会承担大量这类协调工作，制定标准化模板，但作为产品经理，你在提供上市方案输入信息方面的角色并没有改变。你仍然需要把你的输入放进去。所以也许产品运营会提供——比如模板，帮助你说”好，做一份上市计划需要这些不同的部分”，“这是模板，这是我从大家那里收集到的信息”——但作为产品经理，你仍然需要填写属于你的那部分。

你仍然需要去跟销售人员沟通，仍然需要和市场团队协作确保定位准确。但产品运营人员可以帮助做项目管理层面的工作——把这些人聚到一起、维护统一的模板、建立定期评审的节奏、确保所有内容对齐且集中在一个地方、而不是到处散落。然后确保整个组织的上市流程是一致的，这样就不会像 Denise 说的那样——每个人都在重复造轮子，上市团队的某个人还得跟不同的产品团队用不同的方式去做上市。

项目管理 vs 产品运营

Lenny： 太好了，这是非常实用也很重要的补充。你提到了项目管理（project management）。我猜很多人会以为产品运营也承担项目管理的职责。你怎么理解项目管理和产品运营之间的关系？还有项目管理（project management）和项目群管理（program management）也有区别。你对这些角色有区分方式吗？

Denise Tilles： 我喜欢这样理解——无论他们在做什么，围绕产品运营的三个支柱，核心思路都是像我之前说的那样，提高决策的速度和质量，三个支柱都服务于这个目标。项目群经理（program manager），我认为更多是在思考公司层面的大型倡议，他们的工作是持续进行的、没有固定截止日期的；而项目经理（project manager）则负责具体的有时间盒和明确结束日期的项目。不过老实说，这些角色之间确实有些模糊地带。

深入三大支柱：商业数据与洞察

Lenny： 我想快速回到三大支柱，再深入一层，帮助大家理解它们具体包含什么、产品运营人员到底做哪些工作。我们可以简短一些——就说说商业数据与洞察（business data and insights），产品运营人员在你的公司里具体会做哪些职能和工作？

Denise Tilles： 很多公司会有数据科学团队或商业智能团队，你不需要重新造轮子，不需要在内部产品运营里再建一个数据智能团队。关键在于把这些连接起来，确保你用产品的视角来看待这些数据，尤其还包括财务数据。你不想让所有产品经理都去找 CFO 问当月的营收数据，或者带着各种问题去问。所以核心是获取所有这些输入，用产品的视角来加工，然后确保产品经理真正知道该怎么使用、能够据此采取行动。

Lenny： 所以本质上就是替你跑查询、生成图表和可视化，然后根据数据呈现的情况给出建议。基本上就是产品经理本来要做的所有数据相关的工作。这个支柱里还有别的吗？

Melissa Perri： 也在为领导者服务。我们刚才一直从产品经理的角度来谈，但我觉得这个支柱对领导层和高管来说尤为关键。很多时候，我坐在董事会会议上，我们讨论 ARR，讨论留存率，讨论净留存率，讨论所有这些商业指标——它们对于监控业务健康状况很有用，但产品运营在商业数据与洞察方面真正发挥作用的地方在于：我们如何监控产品的健康状况。

作为首席产品官，ARR 对我有意义，但我更关心的是按客户细分拆分的 ARR。我更关心按产品线拆分的 ARR。我更关心把这些数据再叠加留存率，或者按产品或功能集拆分的采用率，或者按客户细分再按产品拆分的采用率。当我们加上这些视角之后，它们就变成了真正有力的战略洞察。

所以我认为这些人做得很好的是——即使在高管层面，他们也能帮你做到——你作为产品领导者说”我需要这类洞察，这对我的决策有帮助，这是我们的业务运转方式，这是我制定战略的依据”，这些人帮你搭建仪表盘，帮你建立可重复的洞察机制。然后理想情况下，他们对数据足够了解，对你的业务也足够了解，能够主动挖掘出你没想到的其他数据机会，或者找到你没有注意到的有趣趋势。

他们非常像深入挖掘数据的人，只是他们更多是以产品的视角来做这件事，而不是像 Denise 说的那样以公司整体指标视角。这不仅仅是服务于产品经理的。我想特别指出这一点，因为我认为这对领导者来说极其重要——如果领导者不理解这类指标，他们就无法真正监控自己的战略执行情况。他们没法回过头说”我们决定向上市场进入企业级客户”——好，我们有企业级客户的收入，但你有没有真正去看不同企业级客户对各个产品线的采用情况？有没有看企业级客户如何使用不同功能，以及某些使用特定功能的企业级客户是否更不容易流失？我认为正是这类洞察，在这个视角下尤为重要。

Lenny： 作为产品经理，听到有别人会做这件事，感觉挺奇怪的。这感觉是产品经理非常核心的工作——花大量时间与数据打交道，寻找机会，发现哪些在变好、哪些在变差。但我想这里传递的信息同样不是说你不应该做这些，也不是说你擅长这个就不好——而是你可能根本没那么多时间把它做好。如果你能找到一个真正擅长这个、也有时间、不用同时处理成千上万其他事情的人，你实际上会发现更多有趣的结果、更有价值的洞察。你可能正在错过很多东西，因为你真的没那么多时间。你们大致是这个理解吗？

Melissa Perri： 是的，而且我觉得还有一个要点——做商业数据与洞察的人，他们不会是产品方面的专家，几乎从来都不是。我们在 Produx Labs 有几个分析师，之前来自麦肯锡、德勤。他们对产品一无所知。所以我们教他们产品的那部分，由我们来告诉他们”这些是我知道我需要看到的有趣数据”，然后他们能够把这些东西整合成我们可以深入分析的视图。但这其实是定量研究的起点——我们看完数据会说”好，现在需要去做定性研究了。“

产品经理仍需具备数据能力

Melissa Perri： 我觉得对于产品经理来说，你仍然需要对数据非常熟悉。如果你看不懂这些图表，看不到或看不透趋势，而且很多时候，如果你把这些东西放在 Looker 或 BI 工具里，理想情况下你应该能自己拉取临时报告。只不过你不需要手写 SQL 查询来做这件事。你仍然需要理解数据和产品之间的关系，你仍然需要知道什么样的数据是好数据。你还需要理解因果与相关的关系，你需要理解”如果我在周四做了一场大规模营销推广，那就是为什么我们周四突然获得了一百万注册用户，而周三没有。” 他们仍然需要理解所有这些，而且我认为这件事的重要性不会降低。理解和解读趋势作为产品经理工作的核心部分，其重要性不会减少。我只是觉得关键在于把数据更快地放到产品团队手中，这样你就不必在公司里为了拿到数据而去跟官僚流程抗争。

用产品运营提高数据可复用性

所以产品运营可以帮助我们精简那些我们知道会反复查看的东西。有很多东西我们知道应该去看，那就把它们放在仪表盘里——“为什么我每次都要临时去拉那个报告？” 把它们放在仪表盘里，放在报告里。董事会幻灯片也是一样。我们有位朋友是 Forsta 的首席产品官 Brian Bhuta，他说：“我喜欢产品运营，因为当我们准备董事会会议时，我知道有一套固定的信息需要整理出来，而当我们手动去做的时候，等董事会开完数据就已经过时了，然后我又得重新来过，为接下来的三个月做准备，再开一次董事会。” 所以你不希望你的数据是过时的。对于那些可重复的事情，你希望用一种可重复的方式来呈现，但这并不代表你就不需要去主动寻找趋势和洞察了。

产品运营会被软件取代吗？

Lenny： 我们之前请过一位嘉宾 Casey Winters，他有一个观点：当你有运营人员的时候，这通常意味着某些事情效率不够高，可以用软件和产品来提升效率。虽然不是所有事情都能产品化，但你对这个观点怎么看——运营是否往往是软件有朝一日可以自动化的领域？

Melissa Perri： 你仍然需要人来监督这些项目。所以我不认为它们会被完全淘汰，不会是整个角色彻底消失。但他们应该是那些思考”我们该怎么做来优化和精简这件事”的人，而不是用人力来堆。我觉得这也是为什么产品管理的思维方式能很好地适配产品运营职能——因为你会想”我怎么用软件、工具、流程或框架来填补这些空白，把它标准化，然后让它自动运行？“这就是我之前说的共享服务模式的意思。

如果你真的是按照那种思路来想的，那不是”嘿，我需要一万个产品运营人员”。我觉得如果你这么做，方向就是错的。它应该是一个运行良好的精益团队，思考如何利用工具来做这些事，或者自己构建工具，或者为产品团队构建产品，这才是正确的做法。所以我说它不应该有一天被完全淘汰——如果你在为产品团队构建产品，你仍然需要有人来监督那个产品，确保它是相关的。在当今一切飞速变化的节奏下，很多东西和五年前已经完全不同了，你需要有人来监督这些，确保它们仍然是最新的、仍然相关、仍然适合我们公司，但你会用更少的人来做这件事。不应该是”哦，每个产品经理都需要配一个产品运营团队”。绝对不应该是这样的。

产品运营与产品经理的人数比例

Lenny： 我想这番话会让很多人安心不少。你有没有什么经验法则或者思路，来衡量你需要多少产品运营人员对应多少产品经理、多少团队？有没有一个简单的经验法则来判断你可能需要多少人？

Melissa Perri： 这个我没有硬性规则，但我可以说如果你们的比例是一比一，那你的做法就是错的。绝对是。

Denise Tilles： 如果比例是一比一百，那也是错的。

Melissa Perri： 对，那也是。我还觉得……所以当我们之前谈到混合模式与共享服务模式的时候，如果你用的是混合模式，比如说，这通常是一个症状，说明你的数据埋点做得不好。我这么说吧，有时候你需要一个过渡性的权宜之计，直到你把数据埋点做好，而对某些公司来说这可能需要很长时间。在这种情况下，就像我们说的，你可能会安排一个商业数据与洞察的人对应每一位管理多个 Scrum 团队的产品总监，也可能安排一个对应每一位产品副总裁，取决于你需要多少帮助来从系统中提取产品数据。

而如果你的数据集埋点做得非常好，就像我们之前谈到 Doodle 的那种情况，你可能需要的人会少得多，因为产品经理自己就能进入系统拉取查询、自己做临时研究——因为你让数据变得可访问了，你让他们可以自己去做了。

所以我确实认为这之间存在一个平衡——你们公司在所有这三个方面的数据埋点做得有多好，相对于你的产品运营团队的规模。在起步阶段可能需要更多的人力来推动，但理想情况下，你会精简这个团队，让它变得相当精干，他们负责监督多个能自动运行的项目或软件系统。

产品运营团队的起步规模

Lenny： 这让我很有信心，产品运营不会变成公司里又一个庞大的组织。看看像 Ramp 和 Deal 这样极其高效的公司，员工很少，产品经理也很少，但他们有产品运营人员。这说明一个人——也许就一两个人——就能产生巨大的杠杆效应，大概不需要一支规模很大的产品运营团队。

Melissa Perri： 我们也建议，从一个人开始。我们在书中描述了这三大支柱，并且在全书反复强调：“聚焦当下对你最重要的、最能帮到你的那个部分”，我们会在书中引导你分析，然后只派一个人去做这件事。通常，仅此一人就能带来巨大的杠杆效应，释放出大量精力让你去做需要完成的事情。然后等你准备好了，看到了下一个瓶颈，而且不是第一个人能接住的，这时候你可以再加一个人。

这三大支柱所需的专长各不相同，负责人的背景也需要区别对待，这一点需要考虑进去。就像我们说的，在商业数据与洞察方面，那个人通常不是产品专家。他们 hopefully 能在与你合作的过程中逐步上手，但他们通常并不是产品出身。很多时候这些人没有产品管理背景。而我会找来帮助治理和产品部分的人，实际上是另一种人。那个人需要有产品背景，因为他们通常要负责推行路线图相关的工作，辅导大家怎么做，帮助定义产品运营模型中所需的各种系统和流程。如果他们完全没有产品管理经验，这件事对他们来说会非常困难，结果可能也不会太好。

我们也确实看到一种趋势——企业往这个角色上堆敏捷教练，而敏捷教练如果从来没做过产品经理，在一家运营良好的公司里会很吃力，因为他们会退回到敏捷流程的思路上去，去优化 Scrum 之类的东西，但不会做这个角色本该做的事——帮助产品管理流程。我们通常不需要再来一个敏捷教练教我们怎么开站会。我们需要的是有人进来帮我们理清楚：这些跨职能路线图评审会该邀请谁？需要什么输入？会上要做出什么决策？以及如何用正确的粒度向高管层沟通，这样我们就不至于在 CEO 面前打开 Jira 一个个看。CEO 才不关心 Jira 里有什么。嗯，至少他们不应该关心。这么说吧。

Denise Tilles： 不应该关心。

Melissa Perri： 他们想知道的是：“我们在推进哪些重大举措来帮助实现战略目标？” 所以这个角色需要帮助大家对齐到合适的沟通粒度，了解不同的跨职能团队，了解产品经理日常在做什么、什么对他们来说是重要的——这在那个角色中非常关键。所以我认为，从”不止一个人”的角度来看，你的团队可能会稍微大一些。我不是说几百人，但可能需要几个人，因为各个角色的定位确实不同。在市场研究和客户研究方面，你可能需要一个有用户研究背景的人。做过研究运营（research ops）的人是非常合适的人选。

Denise Tilles： 我觉得很少见到公司一上来就组建一整个团队。我跟 Sam’s Club 合作过，他们原本计划这样做，但大多数情况下我们看到的是自下而上地生长。我想就像之前有人提到的，作为一个产品经理感受到痛点，怀着共情心想把它变得更好——这些角色通常就是这样产生的。可能是某个人从产品经理的角色中被部分调配出来，然后发现自己真的很喜欢这种赋能型的工作，团队就从那里慢慢长出来。

如何开始推行产品运营

Lenny： 好。那我们就深入聊聊在公司里怎么开始推行这个话题，你们已经提到了不少建议。顺便说一下，如果你们买了这本书，在书的最后有一个特别漂亮的小东西——来，对着镜头展示一下——一条黄色砖路，标出了推行产品运营的全部步骤。

Denise Tilles： 对，就像 Candy Land 棋盘游戏那样。

Lenny： Candy Land。回到”从谁开始”这个话题，听起来你们建议从一个人开始，我听到的是——从这三大支柱中选一个你认为杠杆效应最高的、最能从产品管理层面上卸载下来的部分。对吗？

Denise Tilles： 对。

Lenny： 那么在开始推行这个角色、开始搭建这个团队的时候，大家还应该考虑些什么？

Denise Tilles： 这个问题很好。我们的案例研究中有一位是 Amplitude 的 Shintaro Matsui，他在 Amplitude 创建了这个角色。你想想看，Amplitude 本身是 Meta 级别的公司——他们打造的正是一个有助于产品运营的工具，同时他们内部也在推行产品运营。他在这方面做得非常出色，是真正的思想领袖。我们与他讨论的案例重点就是：如何引入产品运营、如何启动、如何建立势头并展示快速胜利。他最重要的建议是——首先要确保你理解了需求，你可能对最大的痛点有自己的判断，但要做倾听之旅，做用户研究，做一些研究冲刺，去真正理解问题。也许你发现了一个巨大的机会，但它听起来对一个人的团队来说太庞大了——那你在哪里能最快地创造最大价值？在哪里能产生最大的影响？

识别出这些快速胜利，庆祝这些成果，确保所有人都了解。然后画出一条线——线以上是一个人能做到的事情，线以下是目前做不到但如果我们考虑扩充团队就能做到的事情——同时管理好各方的期望。

Lenny： 你们建议应该尽量招一个已经做过产品运营的人吗？还是说招一个没做过的、然后让他成长为产品运营也可以？这个经验有多重要？

Denise Tilles： 我觉得如果你能找到一个已经做过产品运营的人，那当然很好。如果有人在其他地方搭建过这个体系……看看 Blake Samic，从 Uber 到 Stripe 再到 AI 领域，显然他已经摸索出了一套非常成功的模式。所以如果能招到一个 Blake Samic 这样的人，我肯定建议招。

Lenny： 要把他从 OpenAI 挖走可不容易。

Melissa Perri： 我觉得他现在不会走的。刚去，还有很多活儿要干。

Lenny： 他的 LinkedIn 好友请求现在估计爆了。来了来了。

招聘产品运营的决策

Melissa Perri： 可怜的 Blake。抱歉，抱歉塞满了你的收件箱。我觉得这也取决于你是否全力投入。如果你只是在争取支持，假设这个想法来自首席产品官或产品负责人，说”嘿，我们开始做这个吧”，但公司还没有准备好全面投入，你可能会从其他职能调一个人过来，让他做产品运营，快速展示价值。如果你是首席产品官或领导者，你说”我有预算，我知道这很重要，我完全认可，开干吧”，那你可能最好直接招聘一个做过这件事的人，一个有经验的人，而且是一个能担任产品运营 VP 或总监的人，然后由他去做招聘和规划，“我们要不要从其他职能调人过来并理顺流程？“这样也能解放领导者，不用亲自去找——不会是八千人，但可能是八个人来承担这个职能。

所以这也是一种思路。如果大家还没有完全被说服，你可能想从一个职能开始，找出最紧迫的问题在哪里，展示价值，证明这是值得真正投入的事情，然后再考虑引进一个负责人或从那里开始组建团队。

Lenny： 感觉第一个招聘非常重要，因为如果这个人做得不好，产品运营这个角色在公司里就会开始蒙上不好的色彩。所以确保第一个人成功有很大压力。也许这更说明了为什么要买你的书，确保他们做对了。

Melissa Perri： 如果你作为领导者觉得可以辅导产品运营人员，你有时间来辅导这个人，引导他成为一个合格的产品运营人员并开展工作、给予方向指导，那你可能适合招一个没有经验但具备正确技能组合的人，然后你来教他。如果你完全没有时间辅导这个人，而他也不太自我驱动——比如他不会主动去上课、读书、做那些事情——那你可能需要招一个做过这件事的人，至少在那方面有经验，然后那个人可以帮着辅导其他人，发展这个职能。

产品管理也是一样的。我们看这些团队，尤其是在很多转型公司里。有很多从未做过产品经理的人被放在产品经理的位置上，还有很多从未做过产品经理的领导者，他们问我：“我应该招有经验的领导者吗？“我说：“如果那些产品负责人需要去辅导其他产品经理，那你就需要有经验的人。你需要知道怎么完成这项工作的人。如果他们没时间学，如果你没有时间线去教这些人这些东西并让他们上手，那你就需要一个来了就能跑的人。”

所以我会从这些角度考虑：我们有多少时间来展示价值，有多少辅导资源可以帮助这个人建立正确的心态和技能来执行。我觉得这几乎适用于每个角色，不只是这一个。

寻找产品运营人才的关键

Denise Tilles： 我想补充一点，关于招聘产品运营人员时——是招有产品运营背景的还是产品管理背景的人——目前市场上拥有产品运营头衔的人并不多，但你在寻找的时候要深入挖掘，因为这个人可能作为产品经理或在那个头衔下已经做了很多这类工作。所以外面有很多人可能符合这个画像，只是没有正式的产品运营头衔。

Lenny： 你觉得找到这个人的关键技能是什么？特别是如果他们没有这个角色的经验。我猜这取决于支柱方向，是数据方向的、研究方向的还是流程方向的。你建议在招聘这个人时要注意看什么？

Melissa Perri： 在商业数据与洞察方面，你要找的是一个非常擅长解读数据、用数据讲故事的人，一个善于向不同类型的利益相关者沟通数据并将其转化为有用形式的人。我不会为这个角色招的第一个人是数据库工程师。那不是我们要做的。我们不是在写 SQL，把东西整理到正确的 SQL 表里。我们是要从 SQL 表中提取信息并赋予意义。

实际上我们发现咨询背景的人非常擅长这个，因为他们通常在为私募基金、风投公司以及各种客户产出这类报告。最理想的是这个人同时有大量使用 Looker 或 Tableau 等 BI 工具的经验并且能熟练使用。当然不是每次都能找到。有时候这些人非常擅长 Excel 和 PowerPoint，但在 Looker 和 BI 方面不太行。但如果你能找到兼具两者的人，那就是全垒打了。

所以这个人大概是数据分析背景。我们也确实见过商业智能背景的人，就像你之前提到的，类似这样的背景适合商业数据与洞察这个角色。不一定要是产品经理。我觉得你可以帮助他们、引导他们朝正确的方向去思考需要回答什么问题。他们不应该独自想出所有需要回答的问题。如果他们能主动发现一些洞察当然很好，但基本上是你提出问题，他们去找答案。

Lenny： 另外两个支柱呢？

Denise Tilles： 在流程和实践方面，我觉得这个人需要有极高的情商，能够理解各方的需求，同时也要有很好的直觉判断——我们需要引入多少方法论，以及如何引入才能让它不是强制命令，而是关于我们如何工作的建议。通常产品经理对此会比较开放，因为如果他们说”我不知道路线图模板是什么，我不知道路线图的节奏是什么”，然后有人说”这里有一些指引”，他们会说”太好了，现在我不用想怎么做，直接做就行了”。

所以我觉得需要一个有很多经验来理解深层张力和机会的人，然后能很好地理解并实施系统思维，同时也要理解这不是设好就忘的事——他们需要不断重新评估流程、工具，“这些对我们有用吗？“然后更广泛地理解，“当首席产品官准备董事会会议时，他需要什么输入？当我们准备 QBR 时，产品经理们准备好了吗？我们有没有连贯的故事？有没有人花时间看过所有不同的演示文稿，确保我们传达的是一致的视角，或者都在朝着某个大家都聚焦的战略方向推进？“这就是我的建议。

客户与市场研究人才画像

Melissa Perri： 我觉得在客户和市场研究这块，你要找的是有用户研究背景，但同时又具备流程导向的人。所以要找那些懂用户研究方法、掌握很好的实操技巧的人，因为他们可以帮忙创建工具包，引入合适类型的原型设计和可用性测试软件。他们知道什么是好的访谈，诸如此类，但他们内心也有一种把事情做得更好的驱动力。所以他们会说：“我需要建一个系统来做这件事。“他们擅长把事情体系化。我觉得这是所有人都需要的一种能力——“我可以建一个系统来解决这个问题。”

这其实是一个非常好的面试引导问题，我会拿它去问产品运营的人，虽然我之前从来没想过这个。就像问：“告诉我你在工作中不得不做的一个你特别讨厌的流程或事情，然后你最终想办法把它自动化了，或者在它周围建了一套系统让它变得更好。“我觉得这对任何做这类角色的人来说都是一道很好的面试题。

研究运营的实际案例

在用户和市场洞察这方面，目前做这件事的人不算多，但确实有一个小型的 research ops 运动正在兴起，我觉得在这里会非常有价值。Jen Cardello 是我们 Fidelity 案例研究的主角，她在那里负责用户洞察团队，她是用户洞察的副总裁——我想应该是这个头衔，她也分管所有的用户研究员，同时她还管理着一个研究运营团队。研究运营团队负责建立他们的参与者数据库，也帮忙为做用户研究的人构建工具包，管理所有的用户研究工具，还会走出去培训其他人做好用户研究。

在他们那里，并不是所有人都可以直接去跟客户交谈，像这种金融公司出于合规原因是有限制的。研究运营团队会确保对人员进行认证，让他们能够在一定范围内做合格的研究，而且他们还有分级制度，决定你能做到什么程度，这样就能实现研究的民主化，把研究能力交到更多人手上。如果某项研究涉及合规问题，就会回到 Jen 的团队，由用户研究员来协助完成。

这里面有很多法律上的问题——什么可以对客户说，什么不能说，能问客户什么，不能问什么——研究运营团队就是在处理这些复杂的合规要求。Jen 有研究运营的背景，她有完整的 UX 背景，但研究运营才是她的专长，她在这方面的体系建设非常出色。我和她曾在 Athenahealth 共事过，她在那里就做了这件事。我亲眼看着她把那套体系搭建起来，非常令人惊叹，现在她在 Fidelity 又做了一遍。

所以如果你能找到有这种背景的人，那就太好了。但如果找不到像 Jen 这样的人——毕竟 Jen 只有一个——那你至少应该找有用户研究背景的人，可能还需要一些 UX 背景。他们在这方面很擅长，而且有把它体系化的意愿。

Lenny： Jen 的 LinkedIn 即将收到一堆好友请求了。

Melissa Perri： Jen，对不起你的收件箱。

产品运营的汇报关系

Lenny： 我感觉研究团队现在要恨死把你们拉进产品运营的人了。一般来说，至少在初期，你认为产品运营应该向谁汇报？

Melissa Perri： 产品负责人。

Denise Tilles： 首席产品官。

Lenny： 回答得如此清晰干脆，我喜欢。他们怎么找到时间来培训和与这个人协作呢？这个人是他们的左右手，帮他们把一切都变得更高效吗？这是一种怎样的关系？

Melissa Perri： 我觉得肯定是他们的左右手。我们会对很多首席产品官说，尤其是高增长公司的——“你的第一个招聘就应该是产品运营的人，帮你把这些数据弄出来并开始分析”，因为这能帮他们做董事会汇报，帮他们制定战略。通常你走进一家成长阶段的公司，第一件事就是确保一切运转正常，你需要设定好战略。一般你被招进来的时候，往往存在战略层面的问题，而这个人就是你用来体系化战略的左右手。所以我确实认为首席产品官需要在方向上给予指导。

不过这也回到了我们之前的问题——你是雇一个有经验的人，还是雇一个新手？如果你作为首席产品官没有太多时间来培养一个产品运营的人，因为你有八千个火要救，那就雇一个有经验、知道怎么做的人来做体系化。如果你的问题是”我最大的困扰是商业数据与洞察”，比如说，“我只需要先把数据弄到手，这样我才能做战略层面的事，然后再来思考和规划我想要的产品运营是什么样的”，那也许你就先招一个数据分析师。如果他们在数据分析方面很有信心，这其实挺容易的——虽然我自己没做过——就是教他们作为产品人员需要看到哪些类型的信息。他们在开始阶段会需要更多的手把手指导，因为他们不会知道数据所有不同的切分维度，但并不需要投入过多的时间就能获得有价值的产出。

这不像每周培训 40 个小时然后等六个月才看到成果。更多的是：“我需要你去拉这些类型的数据切分，原因如下。让我给你解释一下，这样你就能学会，下次就能自己思考。“这也能帮到你。所以我觉得这真的取决于具体情况——你需要产品运营多快全面铺开，你有多少时间来培训人，你的起点在哪里，以及你从一开始就有多大的支持和资源来推动这件事。

案例研究：Athenahealth

Lenny： 太好了。也许作为最后一个问题，我想快速走一个你合作过的公司的案例研究，分享一下你是如何推行的、遇到了什么、需要克服哪些挑战，以及增加这个角色带来的好处和影响。

Melissa Perri： 我在 Athenahealth 的时候，我们当时在做……Athenahealth 一直是一家软件公司，我先说明这一点，但他们没有正式的产品管理角色，在我加入之前刚刚设立了这一岗位。首席产品官把我招了进去。他没有深厚的产品背景，所以他说：“我需要培训所有这些产品人员，搞清楚这个组织该怎么搭建。“于是我进去帮他做这件事。我们有超过 360 个产品经理，5000 个软件开发人员，平台规模庞大，市值约 80 亿美元，做的是电子健康档案系统。

这就是我开始意识到我们需要产品运营的地方。这是我自己的发现。我来告诉你我们是怎么推行的，以及下次我们会怎么做 differently，但首先我们把所有产品经理都培训了一遍，大家开始用我们教的很多东西，我们看到组织的成熟度有了很大提升，这非常好。但随后我们开始碰到一些问题，而这些光靠培训产品经理是解决不了的，产品运营的概念就是从这里诞生的。

Athenahealth 的产品运营实践

Melissa Perri： 我们还意识到产品经理实在太多了，真的太多了。一个人汇报给一个人，一层层往下叠，我们觉得”这没什么帮助”。所以我们最终对所有人进行了培训，让大家了解这个角色是什么，然后在遇到其他问题时思考：“除了产品经理，我们还需要什么？“产品运营就是其中之一。我们还让一些人从产品管理岗位转到了其他角色。有人成了数据分析师，有人成了用户研究人员，有人去了组织的其他部门。但在培训之后，很多人实际上自己选择了离开产品管理，有些人也来找我们问：“还有什么别的可以做？”

当我们审视产品运营这个角色时，我们问自己：“好，我们有哪些必须扑灭的大火，而且这些火不是技能缺失导致的？“这是产品运营很重要的一点——它不是用来替代产品经理或产品领导者缺乏产品管理技能的问题，而是帮助有技能的产品经理和产品领导者更好地完成工作。所以它永远不可能替代人们不具备完成工作所需技能这个事实。

高层透明度与信息鸿沟

我们遇到的问题之一，是把团队实际在做什么的洞察反馈给高管。CEO 和我一起制定战略，描绘公司愿景，我帮他把它落到书面，帮他部署，一起思考公司的发展方向。而他居然跑到 Jira 里去翻找大家在做什么的信息，我就跟他说：“你在 Jira 里找不到这些东西的，尤其是我们有成千上万的工单，5000 多人在用，你不可能在里面找到的。”

这让我意识到，“嘿，他在找这些东西。他到底想看到什么？“他想要的是一张组合路线图（portfolio roadmap），看到每个人在做什么，想看到我们在功能层面有哪些大的推进，以及这些如何与我们整体的战略和目标关联起来。什么能帮助我们提高留存率？什么能帮我们获取新客户？什么能帮我们打入企业市场——这是我们当时正在做的一件大事，向医院等高端市场迈进。我们在研发资源分配和路线图方面完全没有透明度。

所以在产品运营方面，我们要做的事情之一就是构建这个视图，想办法让大家在 Jira 中以正确的颗粒度填入正确的信息。我们实际上还得培训大家怎么写……当时我们只有 Jira，所以要教大家写 Jira 里的 epic（史诗），不能只是”做一个按钮”这种级别，而是要有实质内容，背后要有实际的支撑，这样我们才能进行审视。然后我们还得出去寻找合适的软件，把这些信息聚合到组合视图里，让高管们能获取他们需要的洞察。

OKR 看板与首位产品运营负责人

我们还需要建立一套追踪已部署 OKR 的机制，并实时了解其进展。所以我们为此搭建了仪表盘。我们从这里开始，这件事变得非常重要，因为高管可见性是一个大问题——如何让各团队之间的路线图保持一致，如何让大家看到正在发生的事情。随着我们识别出越来越多的需求，我们说：“我们是一个庞大的团队，确实需要有人来统筹这件事。”

数据与洞察在整个公司层面也是一个很大的问题，我们知道需要更好地做数据埋点。当时他们引入了 Amplitude，开始在整个组织中铺开，但还没有完全推广到位。所以我们有这些人四处奔走，帮助各个产品团队从 Amplitude 中获取信息，我们说：“这需要变成一个更一致的、体系化的东西。”

这就催生了对第一位产品运营负责人的需求。我们最终设立了一个产品运营副总裁（VP）的职位，有人从产品管理角色转了过来。她是一个更偏流程型的人，非常想帮助团队获得好的数据输出，同时她对产品管理理解得足够透彻，知道这些东西是怎么运作的，她想在公司内部建立这些系统。

产品运营团队的组织架构

向她汇报的有一个商业数据与洞察团队，负责 Amplitude 的推广。他们还在总监层级配置了人员，通常覆盖五到八个 Scrum 团队，有时更少，取决于具体产品。我们在那个层级嵌入了一名商业数据与洞察人员，帮助获取临时报告，因为我们的数据埋点还不够完善。我们说：“我们还在搭建顶层的体系和共享服务，但这些人今天就需要做决策，怎么让他们做到？“所以她负责管理这个团队，下面有人直接汇报。

然后我们还有负责组合视图、治理和推广的人员，把这些也纳入其中。这就帮我们启动了这方面的工作。另一边，这当时不归产品运营管辖，但正如我所说，Jen Cardello 在那里做研究运营，带领一个围绕用户洞察的团队。她搭建了参与者数据库，非常出色。她推出了一系列用户研究工具，他们还做了一个设计系统数据库，帮助我们更快地进行原型设计，并拥有一致的设计流程，非常了不起。

UX 负责人向首席产品官汇报，所以它仍然在 CPO 的管辖范围内，只是具体汇报给 UX 负责人。这完全没问题，因为我们几乎一直在和他们协作。这就是我们开始推行和运作的方式，这也是当时的需求所在，获取我们需要的洞察变得好多了。

产品运营角色的存续与验证

后来发生的事情是——当时 Athenahealth 经历了很大的动荡，公司私有化了。这是我离开的时候，很多领导者也同时离开了。但他们重组之后，实际上保留了产品运营团队。现在 Tim Davenport 负责产品运营团队，他当时是首席产品官的幕僚长（chief of staff），他一直在建设这个团队，保留那些有效的做法，然后在此基础上继续扩展。他们实际上也是我们书中的核心案例之一，讲述 Tim 现在在做什么，以及他如何协调解决运营支出（opex）和资本支出（capex）以及财务相关的问题。

Lenny： 太厉害了。这对产品运营价值是多么有力的证明——经历所有这些变动，这个角色百分之百地保留了下来。你提到一个很有意思的点，就是这位产品运营 VP 下面管理了好几个不同的人和团队，这非常有趣，因为我一直想象产品运营 VP 管理的是产品运营人员。他们带领比如数据团队和其他团队，这种情况常见吗？

Melissa Perri： 是的，在这个案例中，她确实管理着商业数据与洞察团队的人，他们都是数据分析师。我不会说他们是数据工程师之类的，但他们非常擅长写 SQL，能够从产品的角度分析数据。我还要说一点，我们把很多不想做产品经理但擅长这些工作的人从产品经理岗位上转到了这个角色。他们有一些产品背景，接受过产品方面的培训，在数据方面也很擅长，但他们更适合做数据工作而不是产品管理。就像我说的，很多人主动退出了，他们说”让我离开这个岗位，我不想做这个。“他们想要更多事务性的角色，或者深入数据的工作。我觉得很大程度上是因为人们低估了自己需要跟利益相关者打交道的程度，一旦真的要做这些，他们就会觉得”天哪，我不想做这个”，我在产品管理领域一遍又一遍地看到这种情况。

所以她管理这个团队，但他们确实跟 CTO 那边的数据团队密切合作。CTO 那边有一整个数据团队，负责更多的是数据库管理和数据埋点之类的工作。他们也在帮助部署 Amplitude，正确地做数据埋点，构建合适的视图，以及 Amplitude 或其他产品分析工具的相关工作。我们当时没有 Tableau，那是后来才加的，但他们负责利用数据，努力构建那些洞察。

闪电问答环节

Lenny： 太厉害了。接下来，我们进入了非常令人兴奋的闪电问答环节。我之前从来没有跟两个人一起做过这个环节，我们来看看效果如何。你们可以选择自己想回答的问题，也可以两个都回答。开始吧。

推荐书籍

Lenny： 你推荐最多的两三本书是什么？

Denise Tilles： 我来回答这个。当然，首先是《Escaping the Build Trap》，这是真心话。

Melissa Perri： 我就知道你会说这本。

Denise Tilles： 另一本我推荐的书叫《Traffic》，今年出版的，作者是 Ben Smith，讲的是 HuffPo 和 Gawker 等媒体的创立与发展。我那时在 Condé Nast 做媒体工作，所以也算是间接参与其中。这是一段令人兴奋的历程，虽然结局我们都知道，但故事很精彩。

Melissa Perri： 我认为《The Art of Action》是一本关于战略的出色著作，我一直向大家推荐。它超出了产品管理的范畴——市面上有很多优秀的产品管理书籍，但我喜欢这本，因为我认为它是产品管理社区里的一匹黑马。它精彩地描述了如何部署战略，以及如何判断组织中的战略是否得到了良好部署，或者是否存在需要填补的差距。所以当人们读完这本书后，他们会说”天哪，我们所有这些问题都有”，我就说”没错，这就是战略部署和战略制定的问题，非常明显。“这就是我最喜欢推荐给别人的书。我也很喜欢 Theresa Torres 的《Continuous Discovery Habits》，也是一本很棒的书，在产品领域里也顺便推荐一下。

最近喜欢的影视作品

Lenny： 下一个问题：最近最喜欢的电影或电视剧是什么？

Denise Tilles： 《Deutschland 82, 86, 89》，在 Hulu 上可以看到。强烈推荐，讲的是关于东德的故事。

Lenny： 像 Pedal 一样。

Denise Tilles： 对，非常好看。

Melissa Perri： 我想说……我刚看了 Netflix 上的《House of Usher》。我喜欢……现在正是万圣节。嗯，万圣节刚过。

Denise Tilles： 太应景了。

Melissa Perri： 所以我看了很多恐怖片，我特别喜欢 Netflix 上从《Haunting of Hill House》开始的那个系列，都非常棒。

Lenny： 太棒了。我开始看了但很快就放弃了，我应该再给它一次机会。我和我妻子最近一直在追《Love is Blind》，很经典的节目。

Denise Tilles： 我们也是。

Melissa Perri： 不错的选择。

Lenny： 真是一个糟糕又精彩的节目。

Denise Tilles： 确实。就是那种既上头又低俗的感觉。

最喜欢的面试问题

Lenny： 下一个问题：你招聘时最喜欢问的面试问题是什么？

Denise Tilles： 你最近一次在某个重要的事情上改变想法是什么时候，为什么？通过这个问题可以了解他们是否有学习心态，是否有自我认知，能否承认自己过去的状态以及如何演变的。这通常是一个很有洞察力的问题。

Melissa Perri： 我的大概是”跟我说说你失败的一次经历，发生了什么”。这个问题也很有意思，因为如果有人举不出失败的例子，这本身就是一个值得关注的信号。第二，我觉得每个人都会试图把它变成一个正面的故事。他们真的会试图美化它，我就说”我甚至不希望你美化它，我只是想让你告诉我你学到了什么。“最后说一下你学到了什么当然没问题，我觉得这是可以的。但他们会说”哦，但后来发生了这件事，所有这些事情后来都变得很好”，我就说”我不是在寻找一个完美的结局，我只是想知道你是否失败了，以及你是否从中学到了什么。“

最近发现的好产品

Lenny： 你最近有没有发现特别喜欢的产品？

Melissa Perri： 嗯，有一个我必须要提一下。不是说我最近才发现它，但我之前讲了我们在 Athenahealth 遇到的所有组合管理系统的问题，之后我发现了 Dragon Boat，我现在是他们的顾问委员会成员。它确实帮我解决了那个问题——能把 Jira 里的所有内容汇总起来，在上面以很好的视图展示出来。这真的太好了。

另一个我没有参与但我真的很喜欢的是 Dovetail，因为我觉得他们在产品运营领域做了很好的事情。他们是一个研究知识库，而且还在上面加了 AI 来帮助从所有已完成的研究中生成洞察。我跟 Dovetail 没有任何关联，但我真的很喜欢他们做的事情，因为我之前一直遇到反复自建研究知识库的问题，现在终于有一个专门的工具来做了。

Denise Tilles： 我想提的一个是 Vistali，我目前正在合作的一些产品负责人正在试用它。它是一个有趣的工具，提供了一个单一的工作空间，可以把你的战略、发现和交付可视化地连接起来，还能引导人们沿着这些路径前进。所以我想更多地试用一下，它确实引起了我的兴趣。

人生座右铭

Lenny： 你有没有最喜欢的人生座右铭，经常对自己重复、跟别人分享，或者在工作和生活中经常想起的？

Denise Tilles： 我的座右铭在两方面都适用，尤其是跟我合作的团队或跨职能利益相关者：如果你试图服务所有人，你就谁也服务不好。也就是说要聚焦于你到底在为谁构建产品，你的用户画像是谁。然后对我的孩子们来说，就是想要成为所有人的朋友，但这可能做不到。所以这句话两方面都适用。

Melissa Perri： 我做的大部分事情，最坏能怎样？每当我面对某件事感到害怕，或者需要去做什么，甚至是人际关系上的——比如”天哪，我得跟这个人进行一场艰难的对话”——我就会在脑海里告诉自己：“最坏能怎样？“通常当你坐下来认真想想，结果并没有你预想的那么糟。所以这句话一直帮助我管理面对困难处境或大胆尝试时的焦虑。我觉得年轻时，我多少被过度思虑和焦虑所困扰，没能迈出大的步伐。所以我一直坚持这个原则，不断问自己”最坏能怎样？“——答案通常没有你想的那么可怕。

Lenny： 我很喜欢这句。最后一个问题，既然你们两位都在，我们用一个很温馨的方式收尾。你们最欣赏对方的一点是什么？

Denise Tilles： Melissa 是一位传奇人物，但在传奇背后，她是一个非常乐于合作的人。我们当然是因为一起写这本书才真正深入了解彼此的。在那之前我们也共事过，但这真的是一种很好的方式，让你与曾经的同事、行业内的人保持联系。尤其是在新冠疫情期间，这让我们能共同朝着一件比我们两个人都更大的目标去努力。我最欣赏她的是，她被这么多人敬仰，却非常平易近人，真心实意地想要帮助别人。

Melissa Perri： 谢谢你，Denise。我最欣赏 Denise 的是，她总能带来一种让人安心的、耐心的气场。她处理任何事情都极具职业素养，同时又能直击问题的要害，帮助平息那些已经升级的紧张局面，扭转局势。她做每件事都带着这种耐心和沉稳，帮助你集中注意力、聚焦于关键问题，能真正把人引导到正确的方向上。所以对我来说，我一直很欣赏她辅导和带领团队的方式。她在 Produx Labs 也带领过她的分析师团队。当事情有点偏离轨道或局面失控时，Denise 总是说”没事，我们解决它”，然后直接介入把事情处理好。我一直非常感激这一点。

Denise Tilles： 哎呀，我们可能经历过不少”最坏能怎样”的时刻吧？

Melissa Perri： 一直都有。

去哪里找到这本书

Lenny： 太棒了。你们俩太棒了。听众朋友们，一定要去买她们的书《Product Operations》。应该在亚马逊上就能找到。请分享一下还有什么其他渠道可以买到，最后两个问题：想联系你们的人在网上哪里能找到你们？听众怎样能帮到你们？

Denise Tilles： Productoperations.com，我们上面有一些可供下载的资料，也有联系方式供大家提问。他们怎么能帮到我们？让我想想。

Melissa Perri： 告诉我们你们关于产品运营的故事。我们想听听大家是怎么落地的，哪些有效，哪些无效。我们也一直在学习这些。我觉得我们在这本书里也说了，产品运营正在兴起，但远远没有标准化。所以我们想了解大家的情况——你的公司在产品运营上成功了吗？你看到什么有效、什么无效？所以请务必联系我们，告诉我们你的经历。另外，如果你读了这本书，买书并在亚马逊上留一条评论也能帮到我们，因为这确实对作者有帮助，而且这次我们是自出版的，所以这个支持对我们尤其重要。

你们也可以在 LinkedIn 上找到我们俩。我在上面是 Melissa Jean Perri，不过如果你搜 Melissa Perri 通常就能找到我。Denise 是 Denise Tilles。如果你想联系我们，productoperations.com 上有表单可以留言。

Lenny： Productoperations.com。这是找到购书渠道最好的方式吗，还是有其他推荐的网站？

Melissa Perri： 我们也有其他渠道。我们刚搞定。自出版挺有意思的，但我们刚刚实现了向 Barnes & Noble 和其他书店的分销。所以基本上各大平台都能找到。不过如果你去网站，上面会有最新的购书信息。另外，如果你去实体书店——有些人不喜欢亚马逊——你去书店问一下，他们也能帮你订购。

Lenny： 太棒了。谢谢你们两位来做客。

Melissa Perri： 谢谢邀请我们。

Denise Tilles： 谢谢邀请我们。

Lenny： 我的荣幸。大家再见。

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

术语表

原文中文
agile coach敏捷教练
AmplitudeAmplitude
ARRARR（年度经常性收入）
AthenahealthAthenahealth（医疗科技公司）
Blake SamicBlake Samic
Brian BhutaBrian Bhuta
business data and insights商业数据与洞察
Candy LandCandy Land（棋盘游戏）
capex资本支出
Casey WintersCasey Winters
chief of staff幕僚长
chief product officer首席产品官
dashboard仪表盘
data instrumentation数据埋点
DealDeal（公司名）
Deloitte德勤
DoodleDoodle
DovetailDovetail（用户研究工具）
Dragon BoatDragon Boat（产品组合管理工具）
epicepic（Jira 中的史诗级需求）
FidelityFidelity（金融服务公司）
ForstaForsta
Jen CardelloJen Cardello
JiraJira
listening tour倾听之旅
LookerLooker（BI 工具）
McKinsey麦肯锡
MongoDBMongoDB
net retention净留存率
opex运营支出
persona用户画像
portfolio roadmap组合路线图
product operating model产品运营模型
Product Operations产品运营
Produx LabsProdux Labs
program management项目群管理
program manager项目群经理
quick wins快速胜利
RampRamp（公司名）
research ops研究运营
research repository研究知识库
SalesforceSalesforce
Sam’s ClubSam’s Club
ScrumScrum
Shintaro MatsuiShintaro Matsui
TableauTableau（数据可视化工具）
Tim DavenportTim Davenport
toolkit工具包
user research用户研究
VistaliVistali（产品管理工作空间）

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