来自 Atlassian 的经验教训 | Megan Cook（Jira 产品负责人）

Megan Cook 2024-02-04

来自 Atlassian 的经验教训 | Megan Cook（Jira 产品负责人）

我们推行了一个叫 Fight Club 的机制。我大概会因为谈论 Fight Club 而惹上麻烦——第一条规则就是不许谈论 Fight Club。但它是每周固定的 30 分钟，参与者只有我自己、工程负责人和设计负责人三个人。我们聚在一起，心里很清楚去那里就是为了产生冲突的。

我觉得很多时候，当面对困难的对话或者冲突时，人们会一直拖着，直到问题变得更大。或者如果一个人天生回避冲突，就可能完全逃避它。但如果你在一周中专门留出一段时间来做这件事，你就会处于那种心理准备状态。你知道自己是去解决难题的，你知道会有分歧，这会让事情好得多。我觉得我们三个人之间的关系因此好了很多，因为我们在问题还小的时候就去面对了。

Lenny： 今天的嘉宾是 Megan Cook。Megan 是 Jira 的产品负责人——Jira 被 75% 的《财富》500 强企业使用，全球拥有 12.5 万家客户，是迄今为止世界上最受欢迎的项目管理工具。

Megan 在 Atlassian 工作了将近 11 年。在加入 Atlassian 之前，Megan 曾担任分析师、开发者和敏捷教练。

在这次对话中，我们讨论了 Atlassian 在同时运营 15 条产品线方面做对了什么——这是许多公司梦寐以求的；在众多竞争对手中如何持续保持市场领先；为什么 Megan 认为游戏心态对打造优秀团队和优秀产品至关重要；获取对想法的支持的一系列实操建议；在远程环境中成为成功 PM 的技巧。此外还有一个很精彩的失败故事，以及更多内容，包括冲浪技巧。接下来，在短暂的赞助商广告之后，为您带来 Megan Cook。

Megan Cook： 非常感谢，Lenny。我是你播客的忠实听众，很高兴来到这里。

游戏与心理安全感

Lenny： 我有很多想聊的。我听说你作为领导者、作为产品领导者，在许多方面都极为出色，所以我想在不同领域都探一探。我想从一件我听说你非常倡导并且特别擅长的事情开始——那就是在团队中创造游戏的空间，同时营造充足的心理安全感。你觉得这些是帮助你的团队如此成功的关键因素。

你能谈谈为什么这对你如此重要吗？为什么创造游戏空间和心理安全感对你来说这么关键？然后你是怎么做的，也许可以举一两个你在团队中实际应用的例子？

Megan Cook： 好的，当然可以。我觉得尤其是在最近，科技行业几乎像是在经历一次集体警醒。我们之前处于一个丰裕时期，大家都在疯狂招人，然后 COVID 来袭，人们的行为不得不发生巨大改变——无法出行，必须在家办公。一大批行业受到严重影响，由此产生了一个高度不确定的时期。

在那之前，或者说在那个阶段初期，我注意到团队中一些细微的信号：当我们进行开放讨论时，并不是所有人都敢于发言——从最初级的人到最资深的人，本应可以无拘无束地讨论任何话题。反馈变得更加匿名化了。每次提交到领导层审阅的东西，都经过了一层又一层的精心打磨。我觉得一旦到了那个程度，就真的是最糟糕的反馈时机了，因为那很可能意味着已经投入了大量工作，而如果你需要纠正方向或做出重大变更，就可能浪费掉大量已经完成的工作。

所以我看着我的团队，心想：“嗯，感觉有些地方不太对劲。“后来我去参加了一个外部领导力活动，其中一位演讲者是 Ben Crowe。他是心态调整方面的专家，合作对象包括奥运金牌得主，还有 Ash Barty——一位网球选手，全世界排名第一时间。这些运动员必须在巨大压力下、在众多观众面前真正发挥出色。他谈到如何进入那种心流状态——一切都很顺利，新想法不断涌现，你在不断进步，势头非常好。他谈到，要进入这种心流状态，需要有一种游戏感，觉得事情是有趣的。你的头脑对新想法保持开放，你感到充分投入当下，而不是焦虑紧张、想着一堆其他事情。

有趣的是，当我思考”游戏”这个词的时候，我的直觉反应是游戏的对立面是工作。我们经常听到工作和游戏被并列作为对立面，但他的观点恰恰相反——游戏的对立面是恐惧。我意识到这正是我在团队中大量看到的东西，这也解释了为什么大家的想法变得越来越渐进、越来越保守。于是我做出了决定：好吧，我们需要关注那个团队的心理安全感，否则永远无法触及那些更大胆、更具突破性的想法。我把产品经理们召集到一起，大家坐下来讨论，共同想出了一些方案并付诸实施，效果非常好。我给你举几个例子。

Lenny： 好，请说。

Megan Cook： 第一个方案是这样的：我手下的产品经理团队现在已经大到不是每个人都能互相认识了。当彼此之间没有建立关系时，就会觉得有点害怕。你缺乏那种信任感，不确定别人会怎么回应你，也不太敢主动去找人。所以我们把团队分成了若干小组，组成同行反馈小组。大概每两周碰一次，有人带一份还很粗糙的初稿来，希望大家帮忙看看，然后每个人都要给出反馈。因为组里有不同层级的人，这是一个很好的机会，可以示范什么样的反馈是有帮助的。这里的文化氛围是大家一起帮那个人把工作做得更好。

所以大家可以在这种环境里展示自己非常早期的作品，并且感到自在。他们能看到，收到反馈其实可以是一件很积极的事情；他们也能看到，这些同事是可以信赖的，可以在彼此之间建立关系，从而有更多人可以求助。

Lenny： 这太有意思了，真是个好主意，而且如此简单。我很惊讶之前没听说过有人这样做。基本上就是让产品经理结对，独立贡献者级别的产品经理，可能也有管理者，互相给反馈。反馈的对象是一页纸提案、PRD、策略文档之类的吗？他们都在什么样的文档上给反馈？

Megan Cook： 其实什么都可以。可以是一个新体验，准备上线的新功能，也可以是一个新策略。我自己也把策略拿进去过，得到了非常好的反馈，有些甚至是出乎意料的好。还可以是一个大家想做的新实验，任何跟专业技艺相关的东西都可以。

Lenny： 而且我觉得就像你刚才暗示的那样，这种做法的一个优势在于它是小组形式，所以压力更小，而且没有……你自己通常也不在场。不过你刚才说有时也在，但一般情况下就是同级之间，他们可以更开放一些，不用那么担心留下什么不好的印象。

Megan Cook： 对，完全同意。我觉得很大程度上就是在锻炼那块肌肉。某种经历你可能一个季度才遇到一次，或者半年才一次，那就会觉得压力很大。但如果你反反复复地做，就习惯了。你习惯了可以期待什么，有了更多练习，就会舒服得多。

Lenny： 太棒了。简单却有力。大家总是在建议产品经理去找导师、找教练，但那些很难找。而这个就很随意，几乎就像是为你自己的工作成立了一个小型的同行董事会。我们在播客里有时候也会聊到这个。总之，真的很棒，非常好的主意，而且任何人都可以做。

Megan Cook： 谢谢。

Lenny： 好，你还有第二个方案？

团队线下聚会与失败分享

Megan Cook： 有的。我们做的另一件事是每半年把所有人聚到一起。所有产品经理到同一个地方，有点像一次线下团建。我们会先做一些有趣的活动，因为大家……你可能知道，Atlassian 是一个远程办公组织，所有人都是远程工作，可以在任何地方办公。所以大家平时不一定习惯所有人聚在同一个地方，需要一点时间来热身。之后我们会讨论策略，做一些关于专业技艺不同方面的工作坊，一起提升手艺。这也是类似的理念——大家建立关系，看到各种不同的想法碰撞，可以帮助提升自己的想法，也更有助于创新。

最近一次，我实际上邀请了一些来自组织各个部门的高级领导者来分享他们失败的故事。就是让大家习惯这个观念：失败是可以的。实际上，如果收获的教训非常好，甚至应该值得庆祝，它不是什么可怕的事情。大胆尝试不是坏事，它也可以是一种非常有力的学习方式。

Lenny： 我很喜欢这个。我们在播客里经常聊失败的话题，所以在这方面我们非常一致。另外确认一下，这个活动是 Atlassian 整个产品团队参加，还是只是你自己的团队每半年聚一次？

Megan Cook： 只是我的团队，然后我们也会邀请一些与我们密切合作的其他产品经理。

Lenny： 然后把他们都飞到澳大利亚去？

Megan Cook： 对，都去悉尼。

Lenny： 悉尼，太棒了。我觉得那里的关键不只是让大家互相见个面，差不多像是培训，针对不同的技能，帮助大家在专业技艺上，或者沟通、写作等方面提升。那谁来教这些内容呢？是团队内部成员，还是请外面的人？

Megan Cook： 实际上我们两种都有。我们会请外部专家，也会……团队内部本身就有很多知识和技能。不同的产品经理有不同的长处。我们的团队类型也完全不同。比如增长团队的人可能想教大家怎么提出好的假设，或者我们会请团队之外、但 Atlassian 内部具备相关技能的人来讲。

Lenny： 我很喜欢这个，这也给了那些产品经理一个机会——一来他们自己能通过教学把这项技能掌握得更好，二来也能锻炼教学和公开演讲的能力。做这种事情有各种各样的额外好处。

Megan Cook： 对，完全同意。而且我觉得作为产品领导者，以身作则非常重要，无论是对外教学、做演讲、讲解不同概念、讲解业务，还是坦诚地谈论哪些事情没有成功。

组织规模与分享意愿的变化

Lenny： 回到你最开始回答这个问题的时候，你谈到 Atlassian 出现了一个转变，事情开始变得更正式，大家在会议上变得更不愿意分享、更害怕被批评。万一有人觉得自己的公司可能也在发生类似的情况，你还记得大概在什么规模的时候开始出现的吗？或者说有没有一些信号，比如”我注意到大家分享得越来越少，或者在大会发言时越来越顾虑”？

Megan Cook： 大概是在工作分成了真正不同的业务线、彼此之间没有那么多理由需要互动的时候。我觉得大概是……差不多在 15 个人的时候，我们就开始看到一些这样的迹象了。

Lenny： 15 个产品经理？

Megan Cook： 对。

Lenny： 明白了。好的，这是个很有参考价值的数字。

10美元优先级游戏

Megan Cook： 对，你知道吗，我再分享一个我们最近在尝试的新做法。我们开始尝试一种叫”10美元游戏”的方式来管理优先级。我觉得大家可能在制定策略之类的时候玩过这个10美元优先级游戏。我们开始把它用在个人优先级上。你和你的经理可以坐下来，列出你所有的优先事项，然后通过分配10美元来展示你把时间都花在了哪里。我和一些人做过这个，有时候会出现这样的情况——“我这周在这个上面只放了10美分。“我就会说，“哦，这是什么意思？20分钟、30分钟的投入？我觉得这实际上并没有推动什么事情向前发展。“所以这个方法很好地帮助人们发现自己是否过载，也能对齐”我的优先级是否合理”，以及”我是否把时间花在了最能推动业务前进的重要事情上”。

Lenny： 太棒了。好的。你刚才提到你们是远程办公，是一开始就远程的吗？

Megan Cook： 不是，不是一开始就这样。实际上是新冠疫情爆发的时候才开始大规模转型的。

Lenny： 明白了，说得通。

远程办公的经验与建议

Lenny： 现在很多公司都在转向远程办公，也在摸索如何高效地远程协作。从我能看到的情况来说，远程办公在 Atlassian 似乎运作得非常好。你有没有什么建议、重要的经验教训或技巧可以分享，关于如何高效地远程办公，尤其是作为产品经理？感觉作为 PM，远程之后工作难度提高了不少，所以我很好奇你有没有什么建议可以分享给那些正在公司或个人层面尝试远程办公的人？

Megan Cook： 当然有。这是个很好的问题，因为远程办公确实不容易，我们一开始也踩了不少坑。但我们坚信，你不需要在办公室里才能打造世界级的产品。我们把这个叫做”Team Anywhere”，意思是 Atlassian 的任何人每天都可以选择自己想在哪里工作。我们认为这更人性化——灵活性不应该是一种福利，它可以从根本上改变人们的生活，尤其考虑到每个人工作之外还有不同的安排。所以我们不太关注你在哪里工作，而更关注如何让你的工作更高效、更有成效。

大概新冠疫情刚爆发的时候我们开始这么做，到现在已经大约三年了。实际上我们刚刚发布了一份指南，总结了这段时间的核心经验。内容是关于一千天的远程办公实践，大家可以在我们的 Work Life 博客上找到，地址是 research@atlassian.com，想深入了解的话可以去看看。不过我可以从中分享几个技巧，以及我们从研究中发现的一些东西。

Lenny： 好的，我们也会在节目备注里放上那个文档的链接。

专门留出连接的时间

Megan Cook： 好的，太好了。第一点是专门留出连接的时间。人与人之间的连接确实是在面对面时建立起来的，但我们发现这不一定需要每天都发生。我们发现，当你有意识地把人们聚在一起时，连接感和生产力都会提升约30%，而且这种效果可以持续好几个月。所以我们发现平均每年聚三次左右就足够了。这也是为什么我的 PM 团队每六个月聚一次。但除此之外，整个团队每隔六个月也会再聚一次。所以我们全年总共会聚四次。

每隔六个月那次，我们会把所有工程师、设计师、所有一起工作的人都召集起来。我们会包下办公室的整层楼，然后整个一周我们都待在一起。其中一部分时间我们就像平时一样一起工作，坐在工位上，进行那种茶水间式的随意闲聊。这能重新建立彼此的关系。其他时间我们会做工作坊，处理一些当面做起来更方便的重要工作，有时候我们就是纯粹一起玩乐。我们把这种活动叫做”节日”。

Lenny： 你刚才提到你们测量了某种生产力的提升。你碰巧知道他们是怎么测量的吗？这个真的很有意思。

Megan Cook： 好问题。我不清楚具体细节，但我可以去帮你了解。

Lenny： 那太好了。我想我们可以先把这段留在播客里，然后如果节目备注里能链接到相关的测量方法的文档，那就太有意思了，因为不管用在什么场景，这都是一个很酷的数据。我很好奇他们是怎么测量的。

Megan Cook： 没问题。

Lenny： 好的，还有什么其他建议吗？

有意识地安排深度工作时间

Megan Cook： 第二点就是要非常有意识地去安排。我前面提到我们一开始也踩过一些坑。其中一个就是，大家立刻把彼此的日历塞满了各种会议。就好像——Lenny，如果我和你一起工作，以前我只需要从显示器后面探个头就能问你个问题。人们担心现在做不到这一点了，那怎么获得这些答案呢？所以觉得需要更多时间跟每个人开会，而这绝对无助于提高生产力。

作为 PM，我们需要时间做创造性工作。我们需要那种深度工作的时间，而当你开完一个会又隔30分钟再开下一个会的时候，这种时间是不存在的。你需要三到四个小时才能启动，进入那种心流状态。所以我和我的领导团队会同步日历，每周我们会有两次大段的连续时间，所有人都空出来。这样我们所有人都有机会做深度工作。这意味着我们开会的时间变少了，但也意味着如果出现什么意外情况需要大家一起处理，我们已经有了那段预留的时间，所以心态上可以更从容一些，知道一定能处理得了。

Lenny： 那段预留时间是在一天中的什么时段？

Megan Cook： 两次分别在一天中的不同时段。一次占一个下午，另一次占整个上午。取决于你是哪种类型的人，其中一个会比另一个更适合你。所以我们索性两种各安排一次。

Lenny： 我个人其实也做了类似的事情。我在周一、周三和周五都预留了深度工作时间块。那个日历邀请的标题是”如果你在这段时间里预约会议，我就扇你。“这个方法真的很有效。不过我觉得你提到的其实是远程办公中 PM 面临的另一个缺失的部分——你没法走过一位工程师身边随口问一句”进展怎么样？“，也没法对设计师说”你现在做到哪了？让我看一眼你在做什么。“这些互动我觉得真的很难复制。你的建议是给领导团队预留出这段时间来互相沟通，那这个理念到底是”这是深度工作时间，不要打扰团队里的任何人”，还是说”你也可以随时 ping 你的直属经理，问’进展怎么样’”？

Megan Cook： 理念就是这是深度工作时间，是你受保护用来做深度工作的时间。不过我发现有一个做法效果很好——在经理和下属的关系中，我每周会和我的下属进行非常简短有力的一对一。然后我确保日历里有弹性空间，因为总会有些事情冒出来，即使我们做了更长的一对一也可能覆盖不到。他们可能就是需要一个小时来过一遍某个东西，可能遇到了一个特别棘手的策略问题。所以他们知道可以 ping 我要更多时间，而我的日历里会为这些情况留有弹性空间。

Lenny： 太好了。在这方面还有其他建议吗？

Megan Cook： 嗯，你可能也注意到了，预留大量深度工作时间的一个后果就是——你用来开会的时间变少了。所以会议时间变得非常宝贵。我们在这方面的做法是……我个人非常反感把状态同步当作会议来开。所以我会很明确地说，如果我们开会，那是为了解决问题。如果只是状态同步，没问题，那我可以在适合我的时间异步阅读，团队里的其他人也一样。实际上我们用的是自己的工具来做这件事，非常方便。这个工具叫 Atlas，它可以让你或团队定期为某个目标或项目提交状态更新，然后把所有更新汇总成一封邮件，你就能快速了解你关心的所有进展，这对我们帮助很大。

同时这也让文档变得更加严谨。你会把事情记录下来，我们用 Confluence，所有的决策、策略、项目启动，都有非常完善的文档记录。哪怕过了一年，你回头想”当时为什么做了那个决定？我们的假设是什么？我们的假说是什么？“，也可以轻松回去查看并反思。

最后一点是，我的同事分布在美国、欧洲，世界各地。要找到一个同时适合澳大利亚人、美国人和欧洲人的时间真的很难。总得有人在凌晨三点爬起来。所以我们工作方式中一个很重要的部分就是录音和录像。我之前有一位在法国的下属，我们会来回录制视频，速度很快。你可以用很口语化的表达，非常随意，不用担心文字传达时语气被误解。这几乎已经变成一种全新的文档类型，在远程工作中非常重要。你可以把一段视频放在文档顶部来解释文档内容，非常棒。这也是我们收购 Loom 的一个重要原因。

Lenny： 我正想说这个。全都讲得通。

Megan Cook： 是的，因为它已经变成我们生活中如此重要的一部分，确实帮助极大。

远程办公中的 buy-in 技巧

Lenny： 顺着这个话题往下说，全面远程办公的话，我猜要让你正在做的事情获得他人的 buy-in 会更难。而我听说你非常擅长争取 buy-in，尤其是从高管那里为想法和项目争取 buy-in。我觉得在 Atlassian 这件事额外有挑战性——你们有两位 CEO，这是我最近才知道的。而且你们全是远程办公，这两个因素可能让事情变得更难。再加上，争取项目的 buy-in 本来就是一件普遍困难的事。对于那些来找你请教的 product leader 和 PM，你会给他们什么建议，帮助他们提升争取 buy-in 的能力？

Megan Cook： 是的，这件事确实很难做好。我见过很多人在这方面挣扎，你说得对，全面远程确实会更有挑战性。然后你还要和跨职能合作伙伴组成一个紧密的团队，你们之间的关系怎么建立？不过我先从一般的 buy-in 说起。

大多数人来找我问如何争取 buy-in 的时候，他们心里已经有一个日期、一个特定的会议，他们脑海中的图景是——自己会拿出一个完美的提案，展示出来，所有人竖起大拇指，然后他们就赢了。我认为这种心态从一开始就是不对的。争取 buy-in 更像是一段旅程。

我举个例子。我之前在研究人们每天在 Jira 中如何开始一天的工作，人们是怎么上手 Jira 的。我们有一个想法——可以打造更多模板，让用户带着各种不同的使用场景进入产品时，有一个更好的起点。这可以改变从首页一直到产品内部的所有体验，形成一个非常好的流程。

Jira 既是一个平台，也不仅仅是一个 Jira Software 产品。它上面实际上构建了四个不同的产品。所以当你想去改变类似这样的东西时，你实际上是在为所有这些不同的产品做改动，不只是一个。因此非常重要的一点是，与大量不同的利益相关者建立合作关系。每一个可能受到这个变更影响——无论正面还是负面——的产品，我们都很早就带着想法和提案去找他们，收集反馈，然后在进一步开发的过程中一次又一次地回到他们那里。当我们有了设计、有了更多数据、和用户测试了各种方案后，我们不断回去，认真吸纳他们的反馈。

所以我认为建立这些合作关系非常重要。在高管层面也是同样的道理。你走进那些会议，提交提案，争取最终的同意，在座有很多人，他们各自有非常不同的视角来看待问题，有丰富的经验可以借鉴。你的 CTO 看待某件事的方式和关注的重点，会跟首席营销官、设计负责人完全不同。他们都会用不同的方式看待和思考问题。所以如果你知道自己的工作会对某个人负责的领域产生重大影响，而你又想听到他的意见，最好在项目有了一定清晰度但还没完全成型的时候就提前安排那次会面，这样你就能把他们的关切纳入考量，因为他们会拥有更宏观的视野。而且这也意味着，当你最终走进那场决议会议时，这些人会成为你的支持者。

所以我认为在正式会议之前，有大量的前期工作要做，这些工作才能确保你在那场会议中有好的结果。

Lenny： 也许我来总结一下你刚才分享的——第一点就是……基本上就是尽早把人拉进来，尤其是受影响最大的那个人。

Megan Cook： 在此之外，我觉得还要有一种心态——保持开放，不一定要自己想出”正确”的方案，更重要的是解决问题或抓住机会。你要清楚自己的假说是什么，事实是什么，做决策所依据的原则是什么，同时保持开放，最终拿出的方案不一定是你最初认为最好的那个。

Lenny： 我猜大多数人都会觉得自己一直处于那种状态——“我非常乐于接受反馈，我完全思想开明”——但其实并不是。你觉得有没有什么方法可以让人意识到”你其实没有自己看起来那么开明”，或者有什么建议让人表现出更强的开放性？还是说你有没有观察到什么……这种事我见得太多了。人们以为自己是在倾听，但其实并没有。你应该改变这一点。

区分假说与事实

Megan Cook： 我觉得有一种方法可以逼自己进入那种状态，就是把你拥有的假说和事实区分清楚。很多人展示的方式往往是”情况就是这样，这就是我所知道的，这显然是应对这个局面的正确做法”。但大多数时候，你手上有不错的数据，对这个领域也有很好的理解，但接下来真正会发生什么，其实是一个假说。总会有你不知道的东西，而且往往你直到发布之后才会知道。发布绝对是最好的检验方式——检验你以为会发生的事情是否真的会发生。

所以我认为，当你带着这样的状态走进会议室——“好，这些是我们实际掌握的事实，这些是假说，这是我验证或推翻假说的计划”——那么你其实是在把自己的想法暴露出来，让大家可以说”哦，关于这个假说我了解更多”，或者”这里有一些你没有的数据”，又或者”还有另一种思考方式”。我觉得人们可能会觉得这样做会显得自己不够可信，觉得你必须充满自信地走进去，必须清楚知道解决方案是什么。但我通常发现，如果你坦率地走进去，暴露自己的思考过程，说明你在哪些方面需要别人的视角和帮助，这反而更能建立可信度。因为每个人都知道你不可能拥有所有答案，你也不可能预见未来。这样做反而能真正帮助建立大家对你的信任，让人觉得你知道自己在做什么。

Lenny： 你有没有什么具体的例子，能让这件事更真实一些？比如你团队里有人这么做了，或者你自己这么做了？因为我觉得对很多人来说，意识到”我其实根本没有在听别人说话，我只是想说服他们我的想法是对的，这就是我们要做的，别挡我的路，给我开绿灯就好”这件事还是挺难的。

收购案例：放下执念

Megan Cook： 我过去有一个例子。当时有一个潜在的收购机会，我非常、非常想做这件事，因为那意味着能以很快的速度给产品增加一大批急需的能力。我就是喜欢那种势头，而且我看不到其他任何方式能做到这一点。我考察了好几个自建的方案，看起来都不太可行。我需要说服几个人——我的老板，还有那个领域的工程负责人。当我把这个方案拿给他们的时候，我了解到的是，那位工程负责人其实可以从公司其他部门调来一批人来支援这个项目，而且这些人掌握了我们需要的所有知识。所以那个看似不可能的任务，他实际上拥有额外的资源让它变得可能。

最终，收不收购其实没那么重要，更重要的是能不能把那个价值交付给客户，这才是我们要解决的问题。所以关键在于回过头来，不要爱上那个方案、爱上那家公司，而是退一步想——“好，我们到底在这里做什么？归根结底真正的目标是什么？”

Lenny： 太好了。在我转到下一个话题之前，关于这方面你还有什么想补充的吗？

如何开好提案会议

Megan Cook： 另外一点我想说的是，真正到了开会的时候，会议的设置也很重要。我经常看到人们走进去，带着一份厚厚的文档或一个演示文稿什么的，然后就直接开始讲。他们很兴奋。但实际上你应该先退一步，非常清楚地告诉这个群体你希望从他们那里得到什么。你可以请求一个决定，可以请求反馈，你也可以指出你在哪里还不太确定，希望他们特别从那个角度来思考，用他们的知识来帮你检验假说。在一开始就把这些说清楚，这样他们读你的文档或听你后续提案的时候，脑子里就已经有了这个框架。

然后我觉得非常有效的是，用一个简短的叙述把你要讲的所有内容串起来。就是很简要地说明——当前的情况是什么，发生了什么变化，以及由此带来的影响是什么……也就是说我们现在有一个问题要解决，或者一个机会可以把握。

最后一点就是确保你准备好了数据。会议室里有高管、有各方的人，他们通常同时在处理一大堆事情，可能每天要听十个提案，涉及公司各个不同领域，所以他们不可能有你那么了解细节。所以你要很用心地选择你带什么数据去，哪些关键要点能帮助他们尽可能清晰地理解当前的局面。但同时你又要对自己的数据足够熟悉，这样当他们需要深入了解细节时你能随时展开。这同样能帮助你建立可信度，让大家对推进这个方案更有信心。

Lenny： 你介意快速总结一下这几条建议吗？然后我想转到你另一个我很欣赏的强项话题。

Megan Cook： 好的，没问题。第一条是，找到那些会受到正面或负面影响的人，或者可能有很好观点的人，在你在制定解决方案或应对当前局面的过程中就和他们合作。第二条是，带着开放的心态来面对——抓住核心问题或你想交付的价值是什么，对如何达成目标保持开放，也对你可能不知道的、需要沿途调整的事情保持开放。最后一条就是会议的设置要到位。走进去的时候，确保你非常清楚你需要什么——是需要一个决定还是别的什么——同时确保你有非常好的支撑数据，来在你听众面前建立可信度。

Lenny： 说得太好了。这就是产品经理总爱问”我们到底要解决什么问题”这个说法或口头禅的来源。但它确实源于一个非常重要的出发点——始终聚焦于让所有人就”我们要解决的问题”达成一致。因为正如你刚才说的，最大的分歧往往来自于人们以为自己在解决不同的问题。说到这里，我现在有一个周边商店了，lennyswag.com，上面有贴纸，还有一堆经典的 PM 术语，包括”但我们到底要解决什么问题？“所以我觉得……但这确实植根于一个真正重要的问题。虽然有时候问多了确实有点烦人。

Megan Cook： 对，这个贴纸放在最显眼的地方真的太好了。

Lenny： 就需要一个大大的标语牌。也许贴纸需要做得更大一点。

Megan Cook： 没错。

坚持做正确的事

Lenny： 还有一件事，我听说你特别擅长——而且其实和我们刚才聊的这些话题都相关——有人这样形容你：你非常善于”打该打的仗”，意思就是去做那些需要做、但不一定受欢迎、或者大家当下没有优先考虑的事情。我听说你在 Atlassian 推动了对 CSAT 的大力投入，就是因为你觉得这才是正确的方向。还有一些项目也是类似的情况——“我就去做该做的事”。你能谈谈为什么这对你来说很重要，产生了什么样的影响，以及你实际上是怎么成功做到的吗？显然这和赢得他人认同的能力是紧密相关的。

Megan Cook： CSAT 这个例子其实非常好，因为有时候你会陷入一种思维惯性——不断给产品加价值、加价值、加价值，但如果客户对你做出来的东西不满意，或者在我们这个案例中发现，一个核心原因是易用性没有达到应有的水平，那这些价值根本就无从释放。怎么加都没用。而且这类事情往往很难获得投入，因为它不是那种闪亮的、令人兴奋的新东西。它是要回头去打磨已有的功能、改进已有的体验。大约两年前，我们的首席体验官非常关注提升 CSAT 得分，让我去研究一下。然后——

Lenny： 简单解释一下 CSAT 吧，有些人可能不太熟悉这个词。

Megan Cook： 当然，当然。CSAT 就是客户满意度（Customer Satisfaction）。我们实际上有一个调查问卷来衡量 CSAT，让客户对产品的满意度进行评分，也会对不同的方面分别评分，这样我们就能了解对于不同的任务或者产品的不同维度——比如可靠性、速度、易用性——客户的感受如何。

Lenny： 我们最近有一期播客正好请了 Judd，聊了 NPS 的话题，有数据显示它其实并不是一个好的预测指标，他更推荐 CSAT。所以你可以把 CSAT 看作在很多场景下对 NPS 的一种替代。不好意思，打断你了，继续说。

Megan Cook： 没关系。所以首席体验官非常重视这件事，让我去研究。但即便这个需求是从最高层提出来的，也不意味着它就能自动获得资源投入。我们经历了几轮不同的步骤来判断这里到底有什么值得投入的。首先，我前面提到我们有那个调查问卷，所以我们有非常丰富的反馈。它不只是一个评分，我们会看到人们解释为什么给了那个分数，这能帮我们精确定位是哪些关键因素拉低了分数。我们和客户也进行了很多深入对话——那种非常丰富、非常有价值的对话，但听的时候又非常痛苦，因为你会亲眼看到一个人在你本以为会给他们带来巨大价值的东西上苦苦挣扎。

然后我们分析了这件事到底会产生什么影响。我们发现的逻辑是这样的：易用性确实是关键原因之一。从逻辑上讲，如果你的产品在某些地方很难用，一些核心操作对用户来说不好完成，那么新用户或新客户的上手时间就会更长，你很难向他们展示产品价值。即便是一个已经用得很好的老客户，当他引入新用户时，那个新用户也可能很难跟上节奏，整体效率就被拖慢了。所以从商业角度看，它会影响新客户获取，也会影响业务扩展的能力。这里面有很清晰的收入关联。

我还发现我们有很多依赖关系。我们有大量的平台团队，而解决这个问题的很多改进都依赖于 Atlassian 内部许许多多的团队。他们各有各的目标，还要服务于其他产品。我不知道你有没有试过对齐三四个不同的路线图，让时间点恰好配合好来推进某项改进——那基本上是不可能的。我们根本做不到。但我们确实发现这些团队对这个领域很有热情，也很想改善易用性。所以我们合作找到了一种低成本的方式，让那些团队帮助我们做出需要的变更，而不需要他们承担主要的开发成本。

每个团队都派出了一位对接人，我们称之为”牧羊人”（shepherd）。当我们的开发者进入代码库做修改时，这位牧羊人会确保不会引发问题，并负责代码审查和设计评审之类的事情。通过获得认同、找到数据支撑为什么这件事很重要，然后我们构建路线图，找到了这种低成本、非常经济的方式在早期就产生有影响力的改变。我觉得这一点非常非常重要。我们还整理了一些设计稿，展示新体验会是什么样子。

我们的设计负责人 Charlie Sutton 有一句很好的口号：展示，不要讲述（show don’t tell）。在这次工作中，这恰恰是激发大家热情的核心方法。你可以展示当前的体验、展示用户的痛点，你可以播放一段客户尝试使用产品时录制的视频以及他们的真实感受。这就带来了情感层面的冲击，帮助大家真正理解问题所在。而新的体验则是质的飞跃——可能直接砍掉二十次点击操作之类的。所有这些因素共同作用，让我们获得了所需的投入。

还有一点也很有帮助，就是我们一开始规模控制得很小。我觉得如果你有一个假设，能够从小处开始，就更容易获得投入，更容易展示成功，之后可以在此基础上不断扩大。在这次项目中，我们最初召集了大约四十人加入。随着产品发布，我们保持了相对小的规模，所以非常快地建立起了势头。我们定期发布进展更新，持续营造团队工作的兴奋感。

在某个阶段，团队还推动了一件在整个过程中影响相当大的事情——深色模式（dark mode）。这需要协调全公司才能实现，但它早就该做了，我们自己也非常喜欢。而用户反馈也进一步推动了势头。实际上就在昨天，我看到了一条关于我们最近某项改动的反馈，那位客户说这是他们很长时间以来见过的最好的”生活质量提升”（quality of life improvement）。就这个措辞本身，就会让你对自己正在产生的impact感到兴奋。

Lenny： 这是 CSAT 相关的工作，还是深色模式？

Megan Cook： 是 CSAT 的工作，是改进其中一个流程。

Lenny： 太棒了，这个故事里有很多让我特别喜欢的地方。第一点就是自己赋予自己力量去做那些你认为需要做的事情，这种力量真的很强大。很多 PM，其实很多人都是这样，总是假设自己没有任何权力，觉得自己被塞进了方形的洞里，那就只能待在那里了，没人会允许他们去做那些自己认为重要但别人不认可的事情。所以我觉得，认识到你拥有的权力、杠杆和能动性比你以为的要多得多，这本身就有巨大的力量——但你同时也得把事情做好。你刚才在讲的时候我记了很多笔记，都是我觉得要做成这类事情的核心要素——就是一个你靠自己推动的、一开始没有太多自上而下支持的草根项目。

我觉得关键就是保持小规模。第二是让它直观可感，让人觉得”哇，这真的会很棒”，一路走来不断激发人们的兴奋。让事情变得非常简单，我觉得这是一个很有启发性的经验——比如”我们已经替其他团队把所有活都干完了，对你们来说会非常简单，不会有很多额外工作”。然后展示数据——“这是我们从 CSAT 目前获得的结果，这是你们可能获得的 impact，这是需要投入多少工作量”，用真实数据说话。还有就是保持草根精神。感觉这整个方法论的核心就是保持小规模、保持草根、一开始不要申请大量资源，用势头来说话。

Megan Cook： 我觉得这一点非常重要。一开始保持草根和小规模，就不会让人觉得这是一个很大的赌注，但这恰恰给了你机会去真正证明你所走的方向是有回报的。这就像是获得更多投入的一个小小的切入点。

Lenny： 太好了。我想换个话题，聊聊 Atlassian 作为一家公司，不过在那之前，关于刚才这些你还有什么想补充的吗？

Megan Cook： 没有了，我们继续吧。

从单一产品到十五个产品线

Lenny： Atlassian 让我觉得最有趣的一点是，它是一家成功推出多产品线的公司典范。这是每一家软件公司、每一家企业的梦想——你从一个产品起步，发展到某个阶段遇到瓶颈，然后增加一条新的业务产品线，然后再继续加。Atlassian 大概有 15 个产品了，这个数字准确吗？

Megan Cook： 对，没错，我们现在确实有 15 个产品。

Lenny： 天哪，太厉害了。这非常罕见，也是很多公司的梦想。所以我很好奇，你觉得 Atlassian 到底做对了什么，才能拥有这么多各自成功的产品？

Megan Cook： 你知道吗，并不是说我们一上来就第一个产品就做对了。15 个产品，我们在这件事上尝试了很多次，所以我可能会讲两个例子。第一个，如果回顾 Jira Software，它最初不过是一个很 humble 的 bug 追踪器。就这么简单，没什么复杂的。然后它经历了一个又一个软件开发方式的巨大变革。它是 2003 年上线的。我还记得，为了帮你们定位一下那个年代，当时最流行的手机是诺基亚 6100。不知道你有没有用过那款。

Lenny： 我不记得那个具体型号了，但我脑海里浮现的就是一台诺基亚手机，那种小小的砖头。

Megan Cook： 对，那是我岳母最喜欢的一款手机，我们花了好久才让她换成更好的。但从那以后发生了很多变化。有了敏捷，有了云。最近我们看到的是软件团队的大规模扩张。以前的软件团队是极其以开发者为中心的。我觉得大多数人在想到 Jira Software 的时候，会以为使用者里面 80% 都是开发者。但实际上开发者大概只占 50%，甚至不到 50%。剩下的是一个巨大的混合群体——技术支持、运营、销售、市场、财务、设计、HR、法务，基本上你能想到的公司里所有角色都会进来推动工作。

所以我们在很多年前就看到了一个趋势——软件团队不再只是开发者了。我们自己的团队内部也是这样。而且我们发现其他团队——财务、市场团队，甚至设计团队——都在自己拼凑解决方案。Jira Software 非常灵活，这是它巨大的优势。这些团队看到软件团队在工作协作方面变得越来越高效，他们也想要同样的好处，于是开始使用 Jira，但我们当时完全没有为他们做好适配，所以用起来相当困难。但积极的一面是，我们从用户那里收到了非常明确的信号——他们希望我们提供更多。而且我们知道，市场团队的工作方式和开发团队是不一样的，本来也应该不一样。所以我们推出了 Jira Work Management，更专注于软件团队之外的这些用例——正是用户在要求我们去解决的问题。

这是一个非常好的发现新产品需求的方式。这些来自客户内部同一业务领域的强烈信号，说明我们完全有能力帮助他们。

Lenny： 从注意到”设计师在用 Jira 但体验不好，PM、研究员也在用，而且遇到了这些问题”，到意识到”嗯，这里可能有一个机会”，再到最终推出产品——这个过程的细节是怎样的？我不知道第一个版本的情况，也不确定你是不是亲身参与了，但你能分享多少就分享多少。你们有没有选择设计合作伙伴，比如跟 Salesforce、Microsoft 合作确保他们喜欢这个产品？这个过程持续了多久？因为我觉得这才是大家最好奇的问题——如何验证、发现，然后真正推出一个能成功的产品。

Megan Cook： 那个产品我没有那么深入参与，但我可以给你讲第二个例子。

Lenny： 太好了。

内部创新机制与 Jira Product Discovery 的诞生

Megan Cook： 第二个例子其实来源于我们的产品内部创新项目。我们允许公司里的任何一个人，只要愿意，都可以来 pitch 一个新产品创意。我们有一位非常出色的产品经理 Tammy Carson，她发现了产品经理们的一个需求——他们需要一个更好的工具来构建产品路线图，在想法被正式确认之前这个阶段。如你所知，作为产品经理，在真正开始构建产品之前有一个模糊的阶段，你在看大量的机会和想法，在做优先级排序，但这些还不是真正确认的工作。没有人愿意把这些放进 Jira，因为一旦进了 Jira，所有人就会默认它一定会发生。这就是 Jira Product Discovery 的由来。

Megan Cook： 过去我们在 Atlassian 的新产品中也尝试过类似的做法，虽然有一些成功了，但过程非常艰难，因为公司大部分的流程和审核机制都是为 Jira Software 这样的大型产品优化服务的。所以我们对此做了调整，创建了非常小的团队，并设置了我们称之为 wonder、explore、make、impact，以及最终 scale 的阶段关卡。这意味着要在每个阶段对这些创新项目进行评估。核心思路是快速迭代——要么证明它行不通、无法成为一门生意，要么快速验证它确实可行，值得追加投入。每个阶段都会相应增加一点投入。

所以 wonder 阶段可能只有提出想法的那个人。到了 explore 阶段，可能会增加几个人，大概三人左右，去真正深入调研——做一个原型，找一些感兴趣的客户来帮助我们进一步思考，并制定初步的产品路线图。然后到了 make 阶段，你会拥有一个完整团队，但所谓完整团队大概也就 12 个人左右，规模并不大。我认为这一点非常重要，因为在每个阶段你都在获取验证，获得越来越多的客户关注和参与，他们帮助你一起打磨解决方案。

你之前问过我们是否会跟 Salesforce 这样的合作伙伴公司联手做新产品。在这个案例中，我们主要是与客户深度合作——我们从 Jira Software 等其他产品中看到了这种需求信号，于是为客户构建真正满足他们需求的工具，然后逐步扩展到更多客户，找到产品市场匹配，再加大投入。我们最近有几个新产品都经历了这样的分阶段推进。Jira Product Discovery 是一个，前面提到的 Atlas 是一个，最新的应该是 Compass。

Lenny： 所以我听到的是，本质上有一套循序渐进的关卡式流程，新产品想法必须逐步通过。我想应该有一个负责人可以决定，“这个不行了，就在 explore 阶段终止吧，把资源投到其他想法上”。我猜是这样？

Megan Cook： 对，没错。可能是负责该市场方向的人。在每一个阶段关卡，都会做一次是否继续推进的评审。

Lenny： 阶段分别是 wonder。我很喜欢这个名字，起得真好。Explore、make，然后还有哪几个来着？

Megan Cook： Impact 和 scale。

Lenny： 明白了。Impact 大概就是看有没有产生效果——我们做出来了，它起作用了吗？然后就是 scale。懂了，说得通，就是全面铺开的意思。

Megan Cook： 对。Impact 阶段可以说我已经能够靠自身产生的收入实现自给自足，而 scale 就是真正推向市场，让它起飞。

Lenny： 正式上线。嗯，放到官网上那种。好的，那 wonder 就好比一个产品经理加一个工程师在黑客松上冒出了个想法。Explore 就是他们获得一些资源，开始探索这个想法，搭建原型，也许还找一个设计合作伙伴来一起构思。大致是这样？

Megan Cook： 对。确保有一个清晰的路线图。对。

Lenny： 好的，明白了。那 make 阶段，是不是就是扩展到更多客户，把产品做得更完善？

Megan Cook： 对，make 阶段才是真正构建产品。原型嘛——

Lenny： 好的，明白了。

Megan Cook： 原型可能很简单，可能东拼西凑的。Make 阶段是真正地构建产品，看能不能吸引越来越多的客户。

Lenny： 明白了。

Megan Cook： 那个阶段你会开始跟客户一起构建。

Lenny： 这真的很有意思，因为我再次觉得 Atlassian 是极少数把这件事做得这么好的公司之一。而且，我不知道这个数字是不是有点夸张——我从未听说过有其他公司做出了 15 个成功的产品。我不确定它们各自有多成功，但它们都活着，而且人们似乎……它们都在被推广。话说回来，对于正在考虑推出第二款产品的人，你有没有什么建议？有什么你建议他们去做的或去想的，可能是他们还没考虑到的？

大公司内部孵化的关键原则

Megan Cook： 我的建议更多是从 Atlassian 的情况出发的——一家 12,000 人的大公司，如何以一种更接近创业公司的心态来孵化新项目。当你做到这个规模时，有季度规划、业务评审，以及各种各样的流程，但你未必想把一个种子项目直接扔进这些流程里，它还没准备好承受这些。所以我觉得这里有几个关键点让创新项目真正成功：

首先，从非常小的规模开始，验证想法和解决方案，不要加太多人，不要迫于压力加太多人。我觉得大家很容易对某个想法的潜力感到兴奋，然后想一口气扔四五个团队上去，但那样……我们之前聊到过这个现象，人多了反而会让事情变慢，所以你要保护这个小团队。

第二点就是给他们快速行动的自由，用不同的方式解决问题。这里的期望值是不同的。他们不一定要参与我前面说的那些流程。这个团队就应该全力冲刺，去证明想法到底行不行，能不能找到产品市场匹配。

而且要采用不同的标准。如果我想给 Jira Software 加一个功能，面对的是数以百万计的用户，那这个东西必须足够健壮，必须能扩展，用户天然会对它有这些期望。但对于这种小型创新项目，我们是在验证产品市场匹配，你最初不需要考虑这些。你必须用不同的标准来衡量，否则只会把他们拖慢得厉害。

实际上我们发现，让这些小团队用稍微不同的方式解决问题，反而催生了一些创新视角，我们可以把这些创新回移植到其他产品中。比如你看看 Jira Product Discovery，它那种类似电子表格的想法列表视图，里面的一些体验设计，我们确实会引入到 Jira Software 中。

Jira 如何持续保持领先

Lenny： 你提到多年来 Jira 经历了许多风雨。从我的角度看，它似乎还在不断经历风雨，而且应对得异常出色。一方面，总有源源不断的创业公司向 Jira 发起挑战，试图成为大家都在用的那个项目管理工具。另一方面，感觉总有人在吐槽 Jira，说”Jira 太难用了，我想换个别的”。但与此同时，它依然占据主导地位，也有很多人真心喜欢它。我很好奇，你认为 Atlassian 整体和你的团队到底做了什么，让 Jira 始终领先于所有人？我知道你可能会说”我们比任何人都更善于倾听客户的声音”。如果这确实是答案的重要组成部分，请一定要分享。但我更好奇的是，有没有什么别人可能没注意到的原因，解释了为什么 Jira 能成功这么久？

Megan Cook： 是的。我觉得涌入这个领域的创业公司数量之多，恰恰说明我们所解决的问题——团队协作这个问题——有多么重要。我们在全球有超过 125,000 家客户，他们每天从 Jira 开始一天的工作，数百万用户和各种类型的公司在使用它。我特别喜欢听他们用它做了什么。他们真的让我惊叹。比如 NASA 用它来着陆火星探测器，或者 Canva 用它为 4000 万人构建设计平台，规模惊人。

Lenny： 我觉得火星探测器这个故事 unbeatable，这个太棒了。后面再接 Canva 的故事就显得没那么精彩了，不过当然也很了不起。好吧，抱歉，请继续。

Megan Cook： 就像你说的那样，客户是我们成功的基石。我们确实对客户极度关注。我们相信只要对他们负责，方向就不会错。我从没觉得我们有过那种自满的心态——不管我们规模多大，我们始终怀着一种健康的危机感，觉得必须持续改进、做得更好。所以正如你提到的客户反馈，这确实是其中很大的一部分。我们把这些做法制度化，让每个人都能轻松参与。比如全公司每周都会收到一封邮件，里面随机选取了一些客户的反馈，包括他们的评分和原话。这样一来，每个人都在持续接收这种反馈。

我们还会定期共享所有人的研究成果。我们也收集产品内的反馈。通过社交媒体、LinkedIn，或者现在的 X，我们让客户非常容易地联系我们。另外我们还有一个完整的社区空间，客户可以在那里就我们提出的新想法或他们的意见展开更深入的讨论。我认为这一切对于让 Jira 保持领先都至关重要。

创新文化与黑客松

我们在其他方面保持领先的另一个原因是，我们的文化非常非常开放地拥抱创新，几乎是在主动邀请创新。比如我们有这些黑客松，内部称之为 shepherd。全公司停下手头的工作，每个人都可以尝试新的想法或技术。这是一个竞赛，最好的创意会获得曝光。它还能让人们和平时不合作的人一起工作。而这些创意的曝光也会在各个地方激发出更多创意。

就像我之前说的，创新可以来自任何地方。所以任何人都可以提出新想法或新产品。当我们看到某些新兴技术我们认为会非常基础且有趣时，就会专门分出一支小团队去研究。比如 Atlassian 内部有一个核心 AI 团队，已经存在很长时间了，但随着 ChatGPT 的出现，整个领域有了一个巨大的飞跃。出现了某种突破。所以在我的团队里，我也专门分出一支小团队去探索，看看我们能做些什么有趣的事情。

我觉得我们也不会回避那些需要更多关注的市场细分，比如刚才提到的 Jira Product Discovery 的故事。而且我们自己也在大量使用自己的产品，这帮助我们发现了各种小问题，让一切变得非常真实。整个团队在做的事情会让我们非常兴奋，我们彼此之间会发送大量的反馈。我觉得这也是非常重要的一部分。

投资未来业务

另一个方面是，当我们审视投资方向时，当然总是有投资核心业务的压力，但我们也会确保投资于孵化未来业务。就像我们刚才谈到的，这些投资不一定总能成功。我们有过 Compass 和 Atlas 那样成功的例子，但我们也通过 Atlassian 的各种创新项目来探索。如果有一些有趣的想法或技术，未来可能会支撑我们的产品，我们就会先在市场上播种。这也促成了几次收购，非常有价值。

最后一点，我认为我们保持敏捷、迅速应对各种变化的能力也让我印象深刻。每次我们能做到什么程度都让我惊讶。比如 2020 年我们决定全力投入打造世界一流的云体验，Atlassian 内部几百人在极短的时间内进行了调动，这令人印象深刻。而且我们在砍掉项目的时候也毫不手软。我再给你举个例子——我们曾经有一个白板产品，本来打算像 Jira Product Discovery 那样做成独立产品。但当团队推进到某个阶段关卡时，我们意识到它其实更像是一种非常实用的文档类型。所以现在你会看到它作为 Confluence 的一个功能存在。做这个决定非常快。

失败角落

Lenny： 我有一个环节，不算新了，叫”失败角落”。我很好奇你在职业生涯中有没有什么重大失败的有趣故事？如果有的话，你从那次经历中学到了什么？

Megan Cook： 我想给你讲一个不太一样的例子，因为我觉得这种失败更难被察觉，而这一点本身就很有意思。这件事我一直在想。当年我错过了一个非常大的机会来推动 Atlassian 向前发展。正如我所说，现在每次我评审一个新想法或审视一个我们在考虑的机会时，都会想起这件事。

当时我在一个团队里，负责改进我们的产品帮助开发者完成工作的方式。通常情况下，他们会从 Jira Software 开始，领取一项任务，然后切换工具——创建分支，开始写代码。我们发现他们会忘记回来更新工作状态，这会在团队中造成很多混乱。另一个开发者可能会以为那项工作还没开始就接手了，导致大量时间浪费。或者如果你想追踪指标，比如一项工作从启动到完成需要多长时间，数据就会完全失真。所以这造成了很大的问题。

但我们不想让开发者再回到工具里去更新，因为那显然会打断他们的工作。所以我们决定构建自动化功能，这样他们就不需要离开 IDE 或命令行了。他们可以继续工作。举个例子，Jira 可以检测到一个新分支被创建，然后自动把你的任务移到”进行中”状态，因为已经有代码在针对它编写了。还有一大堆类似的例子，已经集成在里面了。我决定把它放在用户编辑工作流的地方，我们发布了，表现还不错。人们发现了它，使用了它，看起来确实提供了不少价值。人们喜欢它，这听起来不太像一个失败。我觉得这不是……

Megan Cook： 我失误的地方在于，我本应该从这个功能中意识到更多的东西。自动化，它超级有用。它不仅仅适用于开发者，一大群各种各样的人都可以使用它。它可以应用在每一款产品中。它的能力远不止于把东西移到一个新状态。所以我本应该意识到，我们可以构建一个让每款产品都能借以向前推进的出色服务。几年后，Atlassian 确实收购了一家正好做这件事的公司，做这种高级自动化。它现在已经集成到每一款产品中了。你可以想象收购一家公司要花多少钱。这真的是我犯下的一个代价极大的错误。所以现在每当我看到一个新想法，我总会问自己：“我们怎么把这个推得更远？这里面有没有什么东西可以放大十倍？能不能更广泛地应用到更多类型的用户、更多的产品上？有没有某个更大的机会我们可以真正抓住？”

Lenny： 这个故事太棒了。所以教训就是——在产品上要往大了想。你几乎需要先等它成功，然后才会想到：“哦，我们能不能拿这个东西做更多的事情？“你觉得你当时在构建它的过程中就应该想到这些，还是那时候想这些会太早了？

Megan Cook： 不，我觉得我在构建的过程中就应该捕捉到这一点，因为即便回想那个体验——它确实是一个很好的试验场，这一点不可否认。但即便回想那个体验，仅仅是那个体验被设计安放的位置和产品本身，就限制了它的功能，这真的很可惜。

Lenny： 我想这个教训就是，如果你投入了某个想法，问问自己：如果这个东西大十倍会是什么样子？如果这是一件更大的事，它能不能应用到我们正在做的其他事情上？这样理解对吗？

Megan Cook： 对。这个东西三年后、五年后能走到哪里？这应不应该改变你现在对它的思考方式？

闪电问答环节

Lenny： 很好的建议。Megan，在我们进入非常精彩的闪电问答之前，你还有什么想分享的，或者有什么想留给听众的吗？

Megan Cook： 我想留给你一个东西。这是我最近为我的团队找到的一个非常有用的实践，我们实施它没多久，尤其是在远程工作之类的背景下。就像我说的，我们在一起的时间有限，但我们建立了一个叫做”搏击俱乐部”机制的东西。我说出来可能会惹上麻烦。第一条规则就是不准谈论搏击俱乐部。

Lenny： 大家都知道这个梗。

Megan Cook： 每周三十分钟。只有我自己、我的工程负责人和设计负责人参加。我们聚在一起，都知道进去就是要产生冲突的。我觉得往往当出现困难对话或冲突的时候，你会一拖再拖，直到它们变成更大的问题。或者如果有人回避冲突，他们可能会干脆完全避开。但是当你在每周安排一段特定的时间来做这件事，你就会进入那种心态。你知道进去是要解决一个难题的。你知道会有分歧，而这就让一切好很多。我觉得我们之间的关系因此好了很多，因为我们很早就把这些问题处理掉了。

Lenny： 这太酷了。就像夫妻咨询之类的，就是”我们有什么问题？现在就来解决。“我喜欢这个。而且这让提出困扰你的事情、提出你觉得需要改变的事情变得理所当然。那么，我们接下来就进入非常精彩的闪电问答环节。准备好了吗？

Megan Cook： 准备好了，等不及了。开始吧。

Lenny： 第一个问题，你最常推荐给别人的是哪两三本书？

Megan Cook： 是这样的，我有个习惯，每年都会给我所有的直接下属寄书，针对他们正在提升的某项技能。所以我有一份很长的书单，我确实会发出去。但我发得最多的，尤其是给新 PM 的，是 Marty Cagan 的 Inspired。这本书经得起时间考验。是我的第一任老板推荐给我的，里面有很多很棒的技巧，是非常好的基础知识。

更近一些的，我给管理者们寄的是 Claire Hughes Johnson 的 Scaling People。我想那本书应该是去年才出的，但里面有大量非常实用的战术性内容、模板、各种你可以直接拿来用的东西。

Lenny： 选得真好。这两本我书架上都有，都在我书架后面。两位作者都上过我的播客。我真想看看你给大家推荐的那份完整书单。如果你还没有把它整理出来，你应该发一篇博客或 newsletter，列出每项技能和对应推荐的书。

Megan Cook： 哦，好主意。对，我要做这件事。谢谢。

Lenny： 好，你有作业了。下一个问题。你最近最喜欢的电影或电视剧是什么？

Megan Cook： 我看剧总是很滞后，但我最近在刷的是《基地》。我觉得它构建了一个庞大的世界。我通常不是那种特别迷科幻的人，但它把一些关于新技术可能意味着什么的想法呈现出来的方式……如果你没看过的话——这真的是剧透了——其中一个主要角色，或者说三个主要角色，其实是统治宇宙的皇帝的克隆体。这个皇帝决定在自己生命的三个不同阶段克隆自己，让那些人继续统治下去。我觉得光是这个设定就引出了一个思考：如果我们延长人类寿命会怎样？影响是什么？当同样的思维方式、同样的人一直延续下去，事物会怎样发展？非常引人入胜。

Lenny： 《基地》这部剧对我来被毁了，因为我很多很多年前就读过原著，那是我最喜欢的科幻三部曲之一。然后我对这部剧超级期待，结果它跟原著基本上毫无关系。故事线完全不同，核心理念是唯一真正保留的东西。所以我后来就厌倦了，弃剧了。但如果你没读过原著的话，我觉得你会喜欢的。它制作得很精美。

Megan Cook： 书更好吗？

Lenny： 对，书更好。“书总是更好的”，我觉得这是一条不错的经验法则。

Megan Cook： 确实是个好法则。我大概会去读一下。

Lenny： 对。我读的时候还是个青少年，所以也不知道。也许它们没那么好，但我觉得大家都很喜欢。如果你喜欢这部剧的话，尤其推荐读原著。下一个问题，你有没有一个最喜欢的面试问题喜欢问候选人？

Megan Cook： 我觉得这是一个老问题，但在关于失败这个话题上是一个好问题。我喜欢问人们最大的失败是什么。我觉得这是了解一个人的好方式，因为你可以看出他们有多善于自省，他们有多深入地思考过发生的事情以及从中学到了什么。它展示了他们能不能在你面前展现脆弱。你可以看到他们认为什么是”大的失败”——有些人会列出一个其实算不上失败的事情。同时你也可以看出他们有没有那种成长型思维——他们有没有从中学到什么？有没有在之后的应用中体现出来？

Megan Cook： 我发现一个有趣的规律：我招到的最优秀的员工，往往都有经历过重大失败并从中学习的经历。所以我觉得这个问题很好——你能看到他们心目中”失败”的尺度是什么，学到了什么；同时，从他们解决问题的方式中，你也能看到他们是怎样应对这类情况的。他们是那种想独自一个人闯出一条路的人？还是会召集一群人一起来解决问题的人？从这一个问题中，你就能洞察他们的价值观和做事方式，这非常有价值。

最喜欢的产品

Lenny： 最近有没有发现一个你特别喜欢的、让你眼前一亮的产品？

Megan Cook： 有的。你可能得拦着我不让我说个没完。我最近买了一个烟熏炉，一个 Traeger 烟熏炉，用来熏肉。光是开箱体验就已经不可思议了。你会收到一个巨大的纸箱，打开之后，把纸箱翻过来，它就变成了一个可以让小孩钻进去玩的小酒馆（saloon）场景——

Lenny： 哇，好酷。

Megan Cook： ……而不是直接扔掉，纸箱变成了一件很好玩又实用的东西。说明书的开头画着一箱六瓶啤酒，帮你判断组装到哪一步时应该喝到第几瓶。里面还附赠了一些工具，而且质量真的不错，不是那种拼装产品里常见的凑合用的工具。除了这些充满趣味的小心思之外，组装过程中你还会不断发现惊喜。比如我打开放木屑颗粒的料斗，里面居然放着一顶棒球帽，完全出乎意料，特别酷。组装好之后实际使用的体验也非常棒。它可以连接手机，我可以去海滩玩，同时让牛胸肉在炉子上慢慢熏着，回到家就做得恰到好处。一切都顺畅运行，功能整合得很好，还内置了食谱。是的，我非常喜欢这款产品。

Lenny： 还有盐。听起来太令人愉悦了，真是一个很棒的产品体验。我觉得我得买一个了。我看我们要帮 Traeger 卖出不少烟熏炉了。

Megan Cook： 那是肯定的。

人生格言

Lenny： 下一个问题。你有没有一个经常回想起来的、会分享给朋友的人生格言，无论是在工作中还是生活中？

Megan Cook： 我的格言是关于最大化快乐。具体来说，就是找到重要的事情并全力以赴，或者找到烦人的事情，把它变成让我享受的事情。举一个非常小的例子——我特别不善于保管钥匙，到处乱放，你可能会在我的餐具抽屉里找到它，然后就再也找不到了。一个显而易见的解决方案是在墙上钉个挂钩，每次把钥匙挂上去，这样就容易找到了。但真正让我快乐的是根本不需要钥匙。所以我现在前门装了指纹锁，每次进门都有点像 James Bond 的感觉。如果有人需要放包裹之类的，也很方便让他们进来。这就是把一件烦人的事变成了更有趣的事。

另外一点是，我非常重视维护好那些珍贵的关系，并不断拓展这些关系。所以我总是会为那些住在伦敦的好朋友们留出时间。我们之间有个约定：每次谁到了对方所在的大洲，就会见面。所以每次我去欧洲——去年我去了柏林，还去了一趟阿姆斯特丹，他们也飞过来找我，我们就一起玩了，度过了很棒的时光。关键就是要确保你为那些重要的事情留出时间。

冲浪建议

Lenny： 顺着这个话题，最后一个和创造更多快乐有关的问题。我注意到你身后有一块很漂亮的冲浪板。对于那些正在学冲浪但可能还不太成功的人，你有什么建议可以分享给听众，帮助他们提高冲浪的成功率？

Megan Cook： 冲浪难道不是你尝试过的最让人感到渺小的运动吗？

Lenny： 对，我试过几次，确实是这样的。

Megan Cook： 我觉得冲浪非常有趣。我从未做过类似的运动——它是一种你必须去”感受”的东西。每次你学习的时候，你在脑子里想着冲浪，你会在真正掌握之前就感受到它。就拿抓浪来说，一道绿波涌过来，你划水、划水，你不确定该在哪个位置，不确定要划多少下才能赶上那道浪，你就是得先成功几次，然后才能找到那种感觉。选浪也是一样的。我第一次面对大海试图挑选一道浪、找到正确的位置时，我甚至看不出海浪的形状，根本找不到那个点。我就是看了一百道浪之后，才能做到。

所以我对冲浪最好的建议就是：走出去，坚持练习，一遍又一遍地做。你会越来越好的，你会开始注意到以前从未注意到的那些细节。还有就是找一些朋友一起，找一个冲浪伙伴，互相监督，确保你们经常下水。

Lenny： 伙伴是最好的。太棒了。Megan，我们聊了游戏、心理安全感、争取认同、坚持正确的战斗、拓展新产品线，还有冲浪。最后两个问题：大家如果想联系你、或者跟进一些话题，在网上哪里可以找到你？听众怎样能帮到你？

Megan Cook： 找我最好的地方是 LinkedIn，我就是 Megan Cook。如果你是 Atlassian 的客户，也可以在 Atlassian 社区找到我，我们可以聊聊。我也有社交媒体账号，比如在 X 上也能找到我。至于怎么帮到我——任何关于 Jira Software 的反馈，我都非常渴望听到。另外，如果你对人们工作方式的演变和转变感兴趣——你认为未来会怎样发展，你看到团队的目标在如何变化——我很乐意聊这些。请随时联系我。

Lenny： 太好了。Megan，非常感谢你来参加节目。

Megan Cook： 谢谢你，Lenny。很开心。

Lenny： 我也是。大家再见。

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

术语表

原文中文
bug trackerbug 追踪器
CSATCSAT（客户满意度）
dark mode深色模式
Failure Corner失败角落（Lenny 播客的固定环节）
Fight Club”搏击俱乐部”机制（团队内部定期冲突讨论会议）
flow state心流状态
Foundation《基地》（科幻作品，改编自 Isaac Asimov 同名小说）
growth mindset成长型思维
Hackathon黑客松
IC PMIC PM（独立贡献者级别产品经理）
incremental渐进式
Inspired《Inspired》（Marty Cagan 著产品管理经典）
James BondJames Bond（007 系列电影主角）
Jira Product DiscoveryJira Product Discovery
Jira SoftwareJira Software
Jira Work ManagementJira Work Management
NPSNPS（净推荐值）
onsite线下团建/线下聚会
PRDPRD（产品需求文档）
product market fit产品市场匹配
psychological safety心理安全感
quality of life improvement生活质量提升
Scaling People《Scaling People》（Claire Hughes Johnson 著管理书籍）
shepherd”牧羊人”（shepherd，平台团队派出的代码审查对接人）
ShipIt（注：原文 shepherd 疑为 ShipIt Day 的转录错误，即 Atlassian 的 24 小时黑客松活动）
show don’t tell展示，不要讲述
stage gates阶段关卡
Tammy CarsonTammy Carson（Atlassian 产品经理）
TraegerTraeger（美国知名烟熏炉/烤炉品牌）

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