哇，能和这么多出色的产品领袖在一个房间里交流真是太棒了。我想这是我第一次和如此多的产品经理聚在一起。我认识并了解在座的许多人，这真的令人惊叹。在过去的一两年里，我和很多人讨论过我们的工作内容以及产品经理的角色定位，这也是我今天要和大家探讨的话题。
实际上我们在基层看到了什么呢？如果大家的记忆力还够好，能回想起来一两年前的情景，那时大家都在互相指责对方的职业即将消失。产品经理告诉工程师他们的饭碗不保；设计师也警告产品经理同样的命运。每个人都在说别人的工作会消失，而实际上每个人都对自己工作的存续感到紧张不安。
值得庆幸的是，我们不再听到这种论调了。那么现在我们在听什么呢？每个岗位都在相互重叠。事实上，我们正进入一个“AI构建者”的新纪元。如果你收听Lenny播客、与初创公司的人交谈，或者阅读X平台上的推文，你会发现很多人在谈论AI构建者。
这个“AI构建者”的角色是真实存在的。有些初创公司不再招聘产品经理或设计师，而是雇佣“构建者”。无论是小公司还是大公司，都有这样的职位描述和岗位存在。如果你仔细想想，对于创始人来说这一直是常态。创始人在创立公司时本身就是构建者，身兼数职。
所以我坚信这确实正在发生，而且令人兴奋。但在一家拥有超过一万名员工的大型企业中情况如何呢？我相信在座的许多人都工作在非五人或十人初创团队的大公司。你们听到这些播客时会挠头想，那样工作真酷，但我没有那样的现实环境。
因此，我将谈谈Atlassian的情况。我不会深入探讨工程团队在做什么——当然他们做了很多工作，比如使用编码代理、重构代码库等。我将专注于产品经理及其发生的变化。正如我们所说，角色正在重叠，但也在扩展。
我们看到每个人都能比以前做更多的工作，这令人兴奋。产品经理的核心工作其实从未改变：寻找产品市场契合度；打造人们喜爱的产品；并确保构建一个客户愿意付费的商业体系。这些都没有变，改变的是我们做事的方式。
显然，AI工具变得更好了，并且以惊人的速度持续进步。我经常被问到如何跟上这一切的步伐？我的回答是你做不到，我认为没人能做到。建议是不要轻信你在X上看到的一切内容。
你必须弄清楚什么对你的客户真正有效。因此要专注于客户以及他们能从AI工具中获得的价值。另一项正在变化的因素是上下文（Context）。大家一直在听关于“上下文图谱”和需要拥有企业级大脑的说法，这非常真实。
现在你可以通过多种工具看到组织的上下文全景。在Atlassian，我们构建了所谓的“协作图谱”，让你能看到组织的全貌上下文。这对产品经理意味着什么？以前，经理是会议记录者、行动项跟进者和上市沟通者。
他们不再需要做这些了，因为有工具可以代劳。上周，我们的CEO Mike私信我和另一位产品负责人问某个功能何时上线。五分钟后他发了一张Rovo（Atlassian的AI产品）截图说：“这是Robo说的，对吗？”我们说是。他说抱歉浪费了你们时间。
我们看到人们能获取这些信息，但我们需要引导他们真正使用它，这涉及变革管理。而产品经理处于观察这一切变化的最佳位置。PM可以做的一件事是专注于加速。大家都在说事情变快了，但PM可以帮助团队真正提速。
在Atlassian我们将其比作一艘航行的船：如何更快到达目的地？关键在于智能加上下文，即模型智能加上组织上下文的结合。回到船的比喻：作为PM，你是划桨还是掌舵？哪种方式能让船更快前进？
我们做过很多实验，以不同方式组织团队并衡量产出。结论是：这取决于具体情况。它取决于产品类型以及产品所处的阶段。现在我想通过三个具体例子来谈谈PM在每个案例中的角色：
一是现有代码库中新功能的开发；二是从零到一的新产品开发；三是在大型现有代码库中的增强改进。所有例子显然都使用Atlassian产品，因为这是我们内部使用的工具。但你也可以将这些原则应用于贵公司所使用的任何产品中。
我们要从Confluence开始讨论。最近，Confluence推出了两个功能：“Remix with Rovo”和“Confluence Slides”。Remix允许你高亮一段文本，将其重新混合成多种不同格式；你可以选择想要的格式。
而Slides功能则是你选取一个页面，点击按钮即可将其转换为精美的幻灯片。显然这些都 heavily 基于AI技术。当团队启动时，他们并没有只说“我想构建什么”，而是提出了一个挑战：如何更快地构建它？以及如何显著改变我的工作方式？
在大型公司中，这与从零开始、拥有全新基础的情况不同。接下来我将介绍Confluence团队发生的一些变化。首先，产品经理开始提交代码（check in code）。我相信如果我让你们举手的话，很多人都在做这件事。
此外，这位产品经理从未写过代码，甚至以前都没用过终端。但她与工程合作伙伴坐下来协作，后者专门为她构建了一个工具包，使前端代码提交变得更容易。因此，有时你必须与他人合作，找出如何最好地利用现有工具的结果。她最终在一个月内提交了26个拉取请求（PR），这比团队中大多数工程师都要多。我问她为什么决定提交代码，她说：“我们需要修复UX中的许多问题，但没有足够的工程师来做这些工作。我希望工程师能专注于更高层面的活动，而这是我可以做的事情。”因此，她认为这将加速项目进展。
接下来是评估（Evals）。我假设我希望大多数人都明白，评估现在是你工作的重要组成部分，你们正在自我培训或上课学习如何进行评估。不同团队中，有时由产品经理进行评估，有时则由工程师进行。但在本例中，对于Confluence幻灯片之类的评估至关重要且必须准确无误。因此，传统上由产品经理完成这些工作，并与工程师合作，确保他们传达出希望团队如何评估该产品的意图。结果使得评估吞吐量提高了两倍（2x）。随后，产品经理开始使用LLM平台进行调试。我们在Atlassian使用Arize来查找提示词中的问题，然后更快地将其发送给工程师修复。
我认为这一条是我最喜欢的例子：他们自动化了设计缺陷的修复过程。你们见过多少次代码与设计不符的情况？为此，他们使用了Figma MCP（模型上下文协议），将Figma中的设计映射到实际代码中，然后利用编码代理自动化修复过程。因此，他们每小时可以修复约14个缺陷。这再次使产品变得更好。最后一个例子是测试创建。工程师从半天创建一个测试缩短到仅需10分钟，吞吐量提升巨大。
在这个例子中，Remix在6周内发布，Confluence在8周内发布。如果你是在初创公司，你可能会说：“天哪，那还是很长时间。”但请记住，这是企业级软件，必须符合合规性要求且必须安全。有时为了确保企业客户能够使用它，这些工作需要花费最长时间才能完成。因此，在AI之前可能需要6个月的事情，现在只需6周就能完成，且迭代循环更加紧密。这意味着与客户、测试客户以及内部团队的反馈循环更快，能更快地修复问题。
退一步看，产品经理的角色是什么？这位PM实际上是在“划船”（亲自执行任务）并提交代码。这是她决定让项目加速的最快方式。工程经理为她提供了一个干净且隔离的代码仓库，这一点非常重要，以免在更大的代码库中出错。团队前期制定了非常明确的贡献模型，规定谁负责做什么，并通过设计模糊了角色界限。他们说：“我们将质疑现有的流程。”这是其中一个例子。
下一个项目叫Roclaw（Robo Claw）。Robo是我们的产品，请勿混淆。这不是Robo上的一个功能特性，而是一个从零到一的全新项目，从头开始编写。起初由产品经理Josh和设计师Kevin负责。他们通过“氛围编码”（vibe coding）完成了整个项目，从始至终开发出了一个工作版的Alpha版本，并让客户在内部使用。一旦他们发现这很有前景，便向项目中加入了工程师。
此时，产品经理和设计师仍在提交代码，工程师也在工作。但Josh开始注意到，由于他忙于写代码，工程师们逐渐偏离了轨道。有一天他想：“等等，我应该花时间编码吗？这真的是我能做的杠杆率最高的活动吗？”于是，他决定从编码中抽身，专注于产品经理通常所做的工作：设定方向、确定优先级和消除障碍。随后事情开始迅速推进。
他最初通过编码起步，这对他有显著帮助，因为他能理解阻碍所在和挑战何在。这使得他引导团队的环境变得更好。另一方面，他也利用AI帮助他不做其他事情。我希望大多数人都不再手动编写每周报告了。如果你还在这样做，你可能不想承认这一点，但请去构建一个代理来完成它。Josh使用Roclaw在产品中开发了一个代理，用于自动生成每周更新报告（非常有趣），因此他不再手动编写周报。
在这种情况下，产品经理起初在“划船”，随后转变为“掌舵”。因为项目处于不同阶段，这是让项目加速所需的做法。他专注于消除团队障碍，无论当时需要什么行动，并且拥有贡献代码的能力，这对他很有帮助。因此他专注于最高杠杆率的活动。
最后一个例子是Jira。大多数人可能听说过Jira，许多人都使用过它。Jara已有20多年的历史，拥有庞大且复杂的代码库。它最初在数据中心运行，后来迁移到云端。支持隔离云环境、FedRAMP合规以及自定义功能。我们有数十万客户，不能出任何差错。因此，在这种场景下让产品经理提交代码可能会有点危险，所以我们不想这样做。但我们也必须将Jira带入AI时代，目标是使其成为“AI优先”。
因此，产品经理和工程师正在为Jira构建AI功能，以帮助客户使用AI进行软件开发，这非常有趣。例如：你如何利用所建工具重新发明开发生命周期？如何确保能将任务分配给代理（Agents）？如何确保在Jira中无缝使用代理处理一切事务？这是团队的一个大项目，从进行中到发布，其吞吐量约为平时的3倍。他们在约10周内发布了22个面向用户的功能特性。他们是如何做到的？做出了哪些改变？让我们从原型设计开始说起。
我相信在座的每个人都在进行原型设计，我百分之百确定。但他们做了什么使原型设计更有效？首先，他们从Loom开始使用。在Loom视频中，你可以录制想要更改的用户界面（UI），或者在这里录制带有讲解的Figma设计图，也可以仅仅将头脑风暴的内容录制成视频。
Loom具备从录制内容自动生成工作项的功能。随后，产品经理可以将这些工作项移至“进行中”状态，进而自动触发编码代理程序。整个流程非常精简高效：编码代理直接在前端代码仓库中编写代码，并利用云端的托管代理服务。因此，产品经理无需处理本地开发环境的问题。
这样生成的代码天然符合合规性、无障碍标准以及Atlassian的设计语言规范。当原型制作完成后，若需将其落地实施，流程会更加顺畅，向开发人员的交接速度也大幅加快。因此，为原型制作提供合适的环境是将成果快速交付给工程师的关键所在，这是一个重大的突破。
接下来是反馈的分类处理。可以想象，如果在Atlassian这样的大型公司里修改Jira中的内容，全员都在使用该系统，因此会收到海量反馈。我们采取了什么措施呢？我们将通过Slack收到的反馈和Bug，利用Jira在Slack中的代理程序进行分类整理，然后自动发送给编码代理进行修复。这为工程团队节省了巨大的时间成本。
此外，我们还进行了大量的用户研究以获取客户洞察。在此过程中，我们利用Jira Service Management来审查来自客户洞察的所有视频资料。我们收集了超过900条反馈信息，并使用机器人代理对这些信息进行分类和归类。我们对最终获得的分类质量感到非常惊喜，从而明确了哪些内容需要发送给工程团队进行修复。
所有这些环节结合在一起时，产品经理显然处于主导和引导地位。他们的核心任务是消除工程师的障碍以加速项目进展，包括更有效地处理内外部反馈，以及构建可复用的原型。正如开头所述，产品经理并不将代码签入生产环境。
那么，综合来看，现在的产品经理在做哪些以前未曾做过的事情呢？他们显然在进行原型制作和测试；编写评估用例（Evals）；更深入地挖掘客户反馈信息；并以更高的速率处理各种数据。所有这些工作的前提是，所有的AI工具都能理解你所在组织的上下文语境。
在Atlassian，这种能力构建于“团队协作图谱”（Teamwork Graph）之上。那么他们不再做哪些事情呢？他们不再进行手动更新，不再手工汇编研究资料，也不再从零开始制作SLI幻灯片。虽然我说没有同步会议会夸张一些，但我相信现在的同步会议确实减少了。
我们是如何做到这一点的？我们在Atlassian的行动计划是什么？当我与初创公司的人交谈时，他们告诉我应该招聘“AI原生”的人才。然而，我们在Atlassian已经拥有许多优秀的产品经理了。因此，我们的目标是让他们转变为AI原生型人才，帮助他们掌握构建产品所需的技能。
为此，我们引入了一项名为“AI流利度指数”（AI Fluency Index）的工具，旨在帮助人们理解他们需要提升的方向。该指数包含六项能力指标：例如，你是否懂得如何使用工具？是否知道如何撰写邮件？是否能自动化数据洞察？能否进行原型制作？以及你是否具备所需的技术素养水平。
该指数分为一到五个等级：一级代表好奇，三级代表胜任，五级则是先锋引领。我们并不期望每位产品经理在所有方面都达到最高等级（5级）。这并非晋升阶梯，而是用于个人发展。它为技能培养提供了北极星指引，因为所需技能始终在不断变化。
真正的阶梯关乎成果以及你为客户创造的价值。这一指数旨在帮助产品经理理解他们应当掌握的技能。我们期望随着时间的推移，每个人都能在这些方面达到3级水平。同时，你需要了解团队的需求，明确对团队最重要的技能点，并专注于将其提升至5级水平。
我们如何培训产品经理？我们希望他们成为AI流利型人才。我们尝试过多种方法，其中最成功的是我们的“AI构建者周”（AI Builder Weeks）。这是每季度举行的一次活动，我们会专门抽出一周时间，让大家暂停常规工作。在此期间，我们培训产品经理和设计师。
活动首先邀请外部演讲嘉宾分享经验（感谢Claire参加我们要最近的构建者周）。随后，由组织内部在特定技能方面更为先进的产品经理来培训其他同事。最后，参与者需要完成一个项目：根据具体情况，他们可以与团队或其他人员合作，运用所学技能进行实践。这一举措取得了巨大成功。
已有超过一千人参与了我们的构建者周，并在活动后建立了120多个新工作流供人们使用。每次我们只聚焦于一个主题：第一次是原型制作，第二次是评估用例（Eval），第三次是如何构建代理程序，而最近一次则是代码签入。
我们与客户深入探讨了这一话题，并实际构建了一套“AI构建者周工具箱”。你可以在我们的网站上找到它，里面展示了我们过往的议程安排及实施方法。好了，现在我们已经告诉产品经理他们要达成的目标，并进行了培训。
此时，客户经常会问一个问题：你们如何衡量成果？坦白说，我们尚未完全解决这一问题。我认为目前还没有人真正找到了完美的答案。我与许多人探讨过此事，这就像老生常谈的“如何衡量开发者生产力”一样棘手。
目前，我们衡量的是部署到生产环境的PR数量（而非撰写的PR总数）。我们也衡量交付的功能特性。虽然确定功能从构思到进入客户手中并开始使用的确切时间点有些棘手，但总体目标是明确的。当然，你需要设定正确的OKR（目标与关键结果），确保达成这些指标以及整体的吞吐量。
有时，衡量单个团队的吞吐量比衡量整个组织的吞吐量更容易。因此，建议两者兼顾：既要确保团队工作速度加快，也要推动组织整体效率提升。如果你有关于如何衡量成果的想法，欢迎交流。我们每季度都在积极工作，团队会尝试不同的实验方法，并观察可以衡量的成果指标。
综上所述，正如我之前所说，角色正在扩展，每个角色的职责都在增加。我认为产品经理可以做更多事情来优化他们的工作……
以更高效、更好的方式工作，从而为客户交付更多价值。我认为这是作为产品经理最好的时代，非常令人兴奋。我是一个乐观主义者，相信十年后我们依然会在这里。但我真心觉得在座的各位非常幸运能身处当下。好了，就这些，谢谢大家。