角色不是在收敛,而是在扩张——Tamar Yehoshua(Atlassian)

• 一两年前人人指着别人的手艺说「你的工作要没了」——PM（产品经理）对工程师说，设计师对 PM 说，而且大家是真紧张；Tamar 说现在已经听不到这种话，换成了「各个岗位在相互重叠」。→ 详细
• 新的说法是 AI builder（builder，亲手把东西做出来的人）：听 Lenny's Podcast、跟创业公司的人聊、刷 X 都在谈，她的判断是这个岗位真实存在。→ 详细
• 证据是有些创业公司已经不招 PM、不招设计师，只招 builder，职位描述都有了，小公司大公司里都有；但她提醒这对创始人从来如此——创办公司的人一直就是那个身兼数职的 builder。→ 详细

• 这场演讲是讲给大公司的人听的：听播客里五人、十人团队那样干活「一定很酷，可我面对的现实不是那样」，所以她只讲 Atlassian（一万多人）里 PM 这边实际发生了什么；工程侧在用 coding agent（会写代码的 AI 代理）、在重构代码库，她不展开。→ 详细
• 核心立场也就是演讲标题：角色在重叠，但同时也在扩张——每个人能做的事都比以前多得多。→ 详细
• PM 的工作和过去一样：找到 PMF（产品市场契合，做出来的东西正好是市场要的）、做出人们喜爱的产品、确保这是一门有人肯付钱的生意——「这些都没变，变的是我们做这些事的方式」。→ 详细

• 在座的产品负责人最常问她的一个问题是「你是怎么跟上这一切的」。她的回答只有一句：「跟不上」，并且补了一句「我觉得没有谁能跟得上」。说这话的人管着一家一万多人公司的产品，AI 工具还在「飞快地继续变好」，她没有假装自己有一套追新的办法。→ 详细
• 她给的替代做法很具体：「你在 X 上读到的东西，都别信」，你得自己弄清楚什么对你的客户真正管用——把注意力放在客户身上，放在客户能从 AI 工具里得到什么上。换句话说，筛子从「这个工具新不新」换成了「它对我的客户管不管用」，前者永远追不完，后者是你本来就该回答的问题。→ 详细

• 大家一直在听 context graph（上下文图谱，把组织里的人、项目、文档、决定连成一张可查询的网）和「企业大脑」，她说这是千真万确的；Atlassian 做了 Teamwork Graph，能看到组织的完整上下文。→ 详细
• 对 PM 的直接后果：过去 PM 是在会上做记录、跟进待办、跟 go-to-market 团队（负责把产品卖出去的销售与市场）对上线时间的人，现在不用再做这些了，有工具能做。→ 详细
• 例子：上周 CEO Mike 私信她和一位产品负责人，问某个功能什么时候上线；五分钟后他自己发来一张 Rovo（Atlassian 的 AI 产品）的截图问「Rovo 是这么说的，对吗」，得到肯定答复后回了句「抱歉，浪费你们时间了」。→ 详细
• 她的补充：信息已经拿得到，但还得推大家一把让他们真去用，这里有变革管理（让一群人改掉旧习惯）的成分；而 PM 正坐在第一排看着这一切怎么变。→ 详细

• PM 能做的一件事是专注于加速。Atlassian 把团队想成一艘驶向目的地的船，更快到达靠的是「智能 + 上下文」——模型的智能，加上你所在组织的上下文。→ 详细
• 问题于是变成：作为 PM，你是在划桨（rowing，亲自下场干活）还是在掌舵（steering，定方向）？他们做了一堆实验，用不同方式组织团队、衡量产出，得出的答案是「看情况」——看产品是什么类型，看产品处在哪个阶段。→ 详细
• 所以她接下来用三个具体例子讲 PM 各扮演什么角色：在已有代码库里做新功能、从 0 到 1 的产品、在非常庞大的已有代码库里做增强。例子都是 Atlassian 自家产品，她说换成你们公司用的任何产品道理一样。→ 详细

• 背景：Confluence（Atlassian 的文档协作产品）最近上线了两个高度依赖 AI 的功能——Remix with Rovo（选中一段文字，把它转成多种格式，格式自选）和 Confluence Slides（拿一个页面点一下按钮，转成幻灯片）。这属于「在已有代码库里做新功能」那一类。→ 详细
• 团队起步时不只是说「这就是我想做的东西」，而是先给自己立了一个挑战：「怎么才能做得快得多，怎么才能大幅改变自己的工作方式」。Tamar 强调这和有一张白纸、刚起步的创业公司不一样，大公司是带着存量在改。→ 详细
• 第一个变化是 PM 开始提交代码。这位 PM 以前从没写过任何代码，连终端（敲命令的那个黑窗口）都没用过；她和搭档的工程师坐到一起，对方专门给她搭了一个 harness（把环境和流程包好的一套脚手架），让她往前端提交代码变得容易。结果她一个月提交了 26 个 PR（pull request，一次代码改动的合并申请），比团队里大多数工程师都多。Tamar 的旁注是：有时候你得找别人搭档，才能摸清怎么把工具用到最好。→ 详细
• Tamar 问她为什么决定自己提交代码。她给了三层理由：UX（用户体验）上有太多东西需要修；没有足够的工程师来做；「我希望工程师专注在更高层次的事情上，而这件事是我能做的」。她下场划桨不是想改行当工程师，而是判断这样最能给项目提速。→ 详细
• 配套的两条护栏：工程经理给了她一个干净、隔离的代码仓库，Tamar 说这一点「非常重要」，这样大仓库里不会有东西被搞乱；团队一开始就有意识地定了贡献模式（谁来做什么），角色边界是有意模糊掉的，并且明说「我们要质疑现有的流程」。→ 详细

▲ 图注：案例一的小结页。左边是 Remix with Rovo and Confluence slides，下面挂着 ROW 和 PM 两个标签；右边四格写着干净隔离的仓库、有意设计的贡献模式、质疑现有流程、有意模糊角色；底部波浪线上有一艘小船，对应她的划桨比喻。

• evals 谁来写：她先对全场说了一句期望——evals（评测，给 AI 输出好坏打分的一套测试题）现在是 PM 工作里很重要的一部分，希望大家都在自学或上课。各团队做法不同，有时 PM 做、有时工程师做；Confluence Slides 的 evals 做对太重要，以往一直是 PM 在做，这次 PM 和工程师配合，把「希望团队怎么评测这个产品」传达清楚，eval 的产出量（throughput）提高到 2 倍。→ 详细
• PM 自己查 prompt 的毛病：PM 开始用 LLM 平台做调试——Atlassian 用的是 Arize（字幕写作 arise，按上下文判断是这家 LLM 可观测性平台，能看到模型每次调用进去什么、出来什么）——自己找出 prompt 的问题再发给工程师，同样更快了。→ 详细
• 自动修设计 bug（她说这是她最喜欢的一项）：针对「代码和设计稿对不上」这个老问题，团队用 Figma MCP（让 AI 能直接读取 Figma 设计稿的接口）把设计映射到实际代码上，再让 coding agent 自动修，一个小时能修掉大约 14 个 bug。→ 详细
• 写测试：工程师写一个测试，从原来的半天缩短到 10 分钟。→ 详细
• 结果：Remix 用 6 周上线，Confluence Slides 用了 8 周。她预判了创业公司听众的反应——「天哪，这还是很久啊」——然后解释：这是企业级软件，必须合规、必须安全，而恰恰是这些事花的时间最长；有 AI 之前这大约要 6 个月，现在 6 周，并且和客户、beta 客户以及内部的迭代循环都紧凑得多。→ 详细

• 第二个例子是从 0 到 1 的项目，叫 RovoClaw。Tamar 特意说别和产品 Rovo 搞混——它不是 Rovo 上的一个功能，是从零写起的。起步只有 PM Josh 和设计师 Kevin 两个人，整个东西是他们 vibe coding（靠和 AI 对话把代码做出来）出来的，从头到尾一手做到能跑的 alpha 版，并让内部用户用了起来；看出这事有戏之后，才给项目加工程师。→ 详细
• 转折点：加了工程师之后，PM 和设计师还在提交代码。Josh 发现工程师渐渐跑偏了——因为他自己正忙着写代码，没人掌舵。有一天他问自己：「等一下，我的时间该花在写代码上吗？这真的是我能做的杠杆最高的事吗？」于是他从写代码里抽身，回到 PM 通常做的三件事：定方向、排优先级、清障，然后事情推进得快多了。→ 详细
• 关键一句：他一开始是从写代码起步的，这一点「对他帮助非常大」——他看得懂卡点在哪儿、难点在哪儿，给团队掌舵的条件好了很多。划桨那一段不是弯路，是后来掌舵掌得准的本钱。→ 详细
• 顺手省掉的事：Tamar 说希望大家都已经不再手写周报，「如果你还在手写，大概也不太想承认，但拜托，去做一个 agent 来干这件事」。Josh 就在自己正在开发的 RovoClaw 里做了一个 agent，让它汇报它自己的每周进展——她说那些周报读起来特别逗——他从此不再写周报。→ 详细
• 她对这个例子的总结：PM 一开始划桨，后来转去掌舵，因为项目进入了另一个阶段；那个时间点上需要他做什么他就做什么，把精力放在自己杠杆最高的事上，而会写代码这件事确实帮了他大忙。→ 详细

▲ 图注：案例二的小结页。左边是 RovoClaw 的图标与名称，下面挂着 STEER 和 PM 两个标签；右边四格写着杠杆最高的事、给团队清障、有能力贡献代码、用 agent 写进展更新；底部同样有一艘小船。

• 为什么这里不能照搬前两个例子：Jira 已经存在二十多年，代码库庞大又复杂——最早在 Data Center（客户自己部署的版本）上起步、后来才迁到云上，要支持 Isolated Cloud（隔离云）、FedRAMP（美国政府对云服务的安全合规认证）和各种定制，还有几十万客户「是绝对不能搞砸的」。所以让 PM 提交代码「可能有点危险，所以我们没打算这么干」。→ 详细
• 但 Jira 也得进 AI 时代，目标是 AI 优先：PM 和工程师在 Jira 里做 AI 功能，帮客户用 AI 做他们自己的软件开发——怎么重新发明软件开发生命周期（从需求到上线的整条流程）、怎么把任务指派给 agent、怎么在 Jira 里做任何事都能无缝用上 agent。结果是从「进行中」到「已发布」的产出量大约是平时的 3 倍，大概 10 周上线了 22 个面向用户的功能。→ 详细
• 做原型的链路是这个案例的核心，分三步。第一步用 Loom（录屏工具）：把想改的 UI 录下来，或把 Figma 设计稿配上讲解录下来，或干脆录一段头脑风暴；Loom 能从录像里自动创建工作项。第二步，PM 把工作项挪到「进行中」，这个动作会自动启动一个 coding agent。第三步，coding agent 是在真正的前端代码仓库里写代码，用的是云端托管 agent，PM 不用折腾自己的本地环境。→ 详细
• 这样做的好处她讲得很直白：拿到的代码本身就已经合规、满足无障碍要求，而且符合 Atlassian 的设计语言，所以想把原型真正实现出来时过程顺畅得多，交接给开发也快得多。她的结论是「有一个合适的原型环境，是让东西更快到工程师手里的关键」，并称之为一个很大的突破点。→ 详细

• 内部反馈分拣：在 Atlassian 改 Jira，全公司每个人都在用，反馈是海量的。做法是把从 Slack 进来的反馈和 bug 交给 Slack 里的 Jira agent 分拣，再自动发给 coding agent 去修，给工程团队省下大量时间。→ 详细
• 外部客户洞察：团队做了很多用户研究，用 Jira Service Management（Atlassian 的服务台产品）接收并过一遍客户洞察里的所有视频，拿到 900 多条反馈，再用一个 Rovo agent 分拣归类；分拣出来的质量让他们「又惊又喜」（幻灯片上标的准确率是 90%，她口头没念这个数），于是知道该把哪些发给工程去修。→ 详细
• PM 的角色：这个例子里「显然是在掌舵」——专注给工程师清障，包括更高效地处理内外部反馈、做出为复用而准备的原型，并且没有往生产环境提交代码。三个例子合起来就是「看情况」的具体含义：已有代码库的新功能里 PM 划桨，从 0 到 1 的项目里先划桨后掌舵，二十多年的老代码库里只掌舵。→ 详细

▲ 图注：Jira 案例里处理客户洞察的流程图：Slack 里的 JSM Assist 收进 900 条反馈，交给 Rovo Agent 做 route、prioritize、label 三个动作，末端标着 90% accuracy。

• 把三个例子合起来，PM 现在在做、以前不做的事，她口头念了四件：做原型和测试；写 evals；在客户反馈上挖得更深；消化信息的速度比以前高得多。幻灯片上列的是六行，多出来的两行是「审阅并修改 agent 的产出」和「把最佳实践固化下来」，写 evals 那一行的完整写法是「写 evals 并迭代 prompt」。→ 详细
• 这一切行得通有个前提：所有 AI 工具都得理解你所在组织的上下文。在 Atlassian，这建立在 Teamwork Graph 之上。→ 详细
• 不再做的三件事：不再手动更新进展，不再手工汇总调研，不再从零开始做幻灯片。第四件她没敢写进清单——「我很想说现在已经没有同步会议了，但那就夸张了」，她相信的只是同步会议变少了。幻灯片上也是这么排的：前三行被划掉，「更少的同步会议」那一行没划。→ 详细

▲ 图注：她讲 PM 现在在做什么时的幻灯片，共六行：PROTOTYPE AND TEST、WRITE EVALS AND PROMPT ITERATION、GO DEEPER ON CUSTOMER FEEDBACK、REVIEW & EDIT AGENT OUTPUT、CODIFY BEST PRACTICES、CONSUME INFORMATION AT VELOCITY，底部黑色横条写着 TEAMWORK GRAPH。

▲ 图注：紧接着的下一页：MANUAL STATUS AGGREGATION、COMPILING RESEARCH BY HAND、CREATING SLIDES AND DOCS 三行被划掉，FEWER SYNCHRONOUS MEETINGS 一行没划，底部同样是 TEAMWORK GRAPH。

• 出发点：创业公司的人给她的建议是「去招 AI 原生的人」，但 Atlassian 已经有很多非常出色的 PM，所以选的是另一条路——帮他们学会需要掌握的技能，让他们变成 AI 原生的。→ 详细
• 工具叫 AI 熟练度指数（AI Fluency Index），作用是「帮大家搞清楚自己该往哪儿走」。它是一张「六项能力 × 五个等级」的表。六项能力她现场举了五项：会不会用这些工具、会不会写 evals、会不会把数据洞察自动化、能不能做原型、技术素养够不够。等级从 1 到 5：1 级是 curious（好奇），3 级是 capable（胜任），5 级是 pioneering（开拓）。→ 详细
• 两句关键的定性。其一，「我们并不指望每个 PM 在每一项上都到 5 级」。其二，「这不是职级阶梯，这是用来做能力发展的」——职级阶梯看的是成果、是你为客户交付了什么；指数只是给你一个「该发展哪些技能」的北极星，因为这些东西一直在变。也就是说，会用工具本身不算绩效，交付到客户手里的成果才算。→ 详细
• 期望值是两段式的：假以时日，所有项都到 L3；同时每个人要清楚自己的团队需要什么、哪一项对团队最重要，在那一项上专注做到 L5。别家怎么给 AI 熟练度定级，见 ep239（Wade Foster）与 ep90（Elizabeth Stone）；同批 259 从首席 AI 官的角度谈了公司层面的 AI 能力建设。→ 详细

• 怎么培训：试过一堆不同的办法，「最后真正留下来的」是 AI Builder Weeks——每个季度一次，拿出整整一周，这一周不做日常工作，专门培训 PM 和设计师。→ 详细
• 一周分三段：先请外部讲者分享（她现场感谢了 Claire，说她来了上一次 Builder Week）；再由组织内部在某些技能上更领先的 PM 培训其他 PM；最后每个人都要做一个项目——可以和自己团队做，也可以和别人做，总之要把正在学的技能用起来。→ 详细
• 每次只聚焦一件事，顺序是：第一次做原型，第二次 eval，第三次怎么搭建 agent，最近一次是提交代码。→ 详细
• 成果：已经有一千多人参加过；Builder Weeks 之后做出了 120 多个大家正在用的新工作流。→ 详细
• 这套做法她跟客户聊过很多，Atlassian 还把它做成了「AI Builder Week in a box」放在自家网站上，里面是他们用过的议程和用法。→ 详细

▲ 图注：AI Builders Week 的 RESULTS 页：训练重点四项 PROTOTYPING、EVALS、AGENTS、CODING，下方两个数字卡是 1K+ participants 与 120 new workflows built。

• 目标定了、人也训了，客户一天到晚问她的问题是「你们怎么衡量成果」。她的回答是「说实话，我们还没搞明白。我觉得没有任何人搞明白了」——这就是「怎么衡量开发者速度」那个老问题。→ 详细
• 目前在量的四样：部署到生产环境的 PR 数（她特意强调不是写了多少，而是部署了多少）；交付的功能数（一个功能从哪天算起不好界定，大致是从想法、到交付到客户手里、再到使用情况）；OKR（目标与关键结果）定得对不对、达没达成；整体产出量。→ 详细
• 团队和组织两级都要量：单个团队的产出量比整个组织的好量，但既要确保团队跑得更快，也要确保组织跑得更快。她直接向全场求助——「如果你们在怎么衡量这件事上有想法，告诉我」——并说每个季度各团队都在用不同的方式跑实验，再看成果上能量出什么。→ 详细

• 归拢成一句：角色在扩张，每个角色都在扩张；PM 可以做更多的事，把自己的工作做得更高效、更好，也可以给客户交付更多东西。→ 详细
• 她的态度：「我认为现在是当 PM 最好的时代」「我是个乐观主义者，我相信十年后我们都还会在这儿」，并说今天在场的人都非常幸运。同一场峰会的另外几段从别的角度答了同一个问题，见同批 254、255、257 与 ep238。→ 详细

▲ 图注：收尾页：标着 PM、Designers、Engineers 的三个圆互相交叠，中央一行字 They're expanding。