角色没有收敛，而是在扩张：Tamar Yehoshua 谈 AI 时代的大公司 PM 工作

一、嘉宾背景

这期节目来自 Lenny Rachitsky 主持的 Lenny's Podcast，标题直接给出讨论对象：Atlassian CPO Tamar Yehoshua 讨论“角色不是在收敛，而是在扩张”。从索引证据看，这不是一场关于个人履历的传记访谈，而是一场产品组织实践分析：Tamar 以 Atlassian 的产品和内部工作方式为主要材料，解释 AI 时代 PM 工作到底发生了什么变化。

Tamar 在节目中的可支持身份是 Atlassian 的 CPO。她谈到的经验范围包括 Atlassian 的 teamwork graph、Rovo、Confluence Remix with Rovo、Confluence Slides，以及 PM 参与代码、eval、原型和反馈处理的内部案例。证据还显示，Atlassian 被放在一个大公司语境中讨论：公司超过 10,000 人，并且内部使用 Rovo、Confluence、Jira 等产品。

因此，本文把 Tamar 的发言视为一位大规模软件公司产品负责人对组织实践的观察，而不是行业普遍定律。她的优势在于能把抽象问题落到具体团队：Confluence 新功能、零到一项目 rovoclaw，以及 Jira 这种历史很长、客户很多、合规要求很高的复杂产品。

二、本期主要内容

节目开场，Tamar 回到过去一两年的集体焦虑：PM、设计师、工程师都曾指着别人的 craft，说对方的工作会消失。她认为，现在更接近现实的变化不是岗位消失，而是岗位重叠，并且每个角色的能力半径都在扩大。她承认“AI builder”是真实角色，创业公司和大公司里都有；创始人原本也经常同时扮演多个角色。但她马上把问题拉回大公司：在超过 10,000 人、产品复杂、流程和安全要求都存在的 Atlassian，这种变化应该如何发生。

Tamar 的主轴很清楚：PM 的根本工作没有变。PM 仍然要定义 product-market fit，做用户喜爱的产品，并形成用户愿意付费的业务。变化发生在“如何完成这些工作”。AI 工具快速进步，组织上下文变得可以被系统读取和使用，PM 不必再把大量精力花在会议记录、行动项追踪、发布沟通和手工信息汇总上。她用 Atlassian 的 teamwork graph 和 Rovo 举例：CEO Mike 询问某个功能什么时候发布，几分钟后又发来 Rovo 的答案截图，团队确认答案正确。这个片段说明，组织知识正在从“问某个人”转向“问带上下文的系统”。

随后，Tamar 用“船”的比喻组织整期分析：PM 到底应该 rowing，还是 steering？她说 Atlassian 做过实验，也调整过团队组织方式，结论不是一刀切，而是取决于产品类型和产品阶段。节目主体由三个案例组成：Confluence 的 Remix with Rovo 和 Slides 展示 PM 亲自贡献代码、参与 eval；零到一项目 rovoclaw 展示 PM 从写代码转向掌舵；Jira 展示在大型、历史悠久、合规复杂的代码库中，PM 不该直接改生产代码，却可以通过原型流水线、反馈 triage 和客户洞察处理来加速工程。

三、核心观点：推理、例子与边界

Tamar 最重要的观点，是反对“AI 会把产品、设计、工程收敛成同一个岗位”的简单叙事。她看到的不是角色消失，而是边界重叠、能力扩张。这一判断有两个层次。第一，AI builder 确实存在，尤其在创业公司或早期产品里，一个人可能同时完成原型、产品判断、设计调整甚至代码实现。第二，大公司不能简单复制五人团队的工作方式。Atlassian 的语境里有超过 10,000 人，有复杂的既有产品，有安全、合规、客户规模和组织协作成本，所以“PM 要不要写代码”不是立场问题，而是杠杆问题。

她对 PM 本质工作的界定很稳定：定义 product-market fit，做用户喜爱的产品，建立用户愿意付费的业务。这些没有被 AI 替代。AI 改变的是 PM 达成目标的方式。以 Confluence 为例，Remix with Rovo 和 Confluence Slides 不是只要求 PM 写需求，而是要求团队重新设计工作流。PM Iya 原本没有写过代码，也没有用过终端，但工程伙伴搭建前端贡献 harness 后，她一个月提交了 26 个 PR，用来修复 UX 问题，让工程师聚焦更高层的工作。这个例子支撑了 Tamar 的“rowing”判断：在某些阶段，PM 亲自处理小而明确的前端修复，可能就是让船更快的方式。

但这套逻辑不能被机械推广。Confluence 案例里，工程经理提供了隔离路径，团队也预先定义了贡献模型，避免影响更大的代码库。这说明 PM 写代码的前提不是热情，而是边界、环境和协作模型。更重要的是，Tamar 没有把 PM 的新能力简化成“会写代码”。她强调 eval 已经成为 PM 工作的一部分：在 Confluence Slides 中，PM 与工程师协作定义 eval，带来 2x eval throughput；PM 还用 Arise 调试 prompt，把问题更快交给工程师。Figma MCP 到 coding agent 的设计 bug 修复、测试创建从半天降到 10 分钟，也说明 PM 的杠杆来自把质量标准、设计语义、提示调试和工程流程连接起来。

rovoclaw 案例给出了相反但同样关键的证据。PM Josh 和设计师 Kevin 一开始 vibe coded 出可用 alpha，并让内部客户使用，这很符合 AI builder 叙事。但当工程师加入、项目继续推进后，Josh 发现自己继续写代码反而让项目偏离方向，于是回到设定方向、排列优先级、unblock 团队。Tamar 的解释不是“PM 不该写代码”，而是“早期写代码让他更理解阻塞点，之后更会掌舵”。这让她的观点更有约束力：角色扩张不等于永远跨界；跨界的价值可能是在某个阶段建立理解，再在另一个阶段做更高杠杆的判断。

Jira 案例是全篇最重要的限制条件。Tamar 描述 Jira 是一个有超过 20 年历史的巨大复杂代码库，经历了 Data Center 到 Cloud 的演进，涉及 isolated cloud、FedRAMP、大量定制和数十万客户。在这种环境下，让 PM 直接改生产代码可能很危险，因此团队没有这么做。但 PM 仍然能通过掌舵来加速：Loom 录制 UI、Figma 或 brainstorm 后自动生成 work item，PM 把 work item 移到 in progress 后触发云端 managed coding agent，在真实前端仓库中产出符合合规、可访问性和 Atlassian design language 的代码；Slack 中的 Jira agent triage 内部反馈；Jira Service Management 和 Rovo agent 处理 900 多条客户洞察反馈。这里的核心不是 PM 变得更像工程师，而是 PM 把上下文、反馈和原型转化为工程可消费的输入。

因此，Tamar 的核心观点可以概括为：AI 让 PM 的工作面更宽，但没有取消 PM 对方向、优先级和判断力的责任。组织上下文是关键变量；模型智能只有接上公司知识、流程、设计语言、客户反馈和代码环境，才可能带来吞吐提升。她也保留了不确定性：不要相信 X 上的所有说法；不同产品、不同阶段会有不同答案；Atlassian 还没有完全解决 AI 生产力的衡量问题。她列出的 deployed PRs、features delivered、idea-to-customer usage、OKR 和 throughput 都是探索中的指标，不应被读成行业已经验证的统一公式。

四、学习与应用

把这期节目用于实际产品组织，第一步是区分“职责本质”和“完成方式”。如果团队只讨论 PM 是否要写代码，很容易把问题变成身份争论。更有效的问题是：在当前产品阶段，什么动作最能提高客户价值交付速度？在新功能、前端 UX 问题清晰、工程资源紧张且能提供隔离贡献环境时，让 PM 做小范围实现可能合理；在方向不清、依赖复杂、需要协调多方时，PM 继续写代码可能反而拖慢项目。

第二个应用是为 PM 的 AI 工作建立贡献模型，而不是只发工具账号。Confluence 案例说明，PM 能提交 PR 的条件包括工程伙伴支持、前端 harness、隔离路径、明确的贡献边界和团队预先约定。Jira 案例说明，在复杂产品里，PM 可以不碰生产代码，却仍然通过 Loom 到 work item 再到 coding agent 的链路，把原型变成更接近实现的资产。团队采用 coding agent 时，应明确哪些仓库、哪些改动类型、哪些质量门槛、哪些审批流程适合 PM 参与。

第三个应用是把 eval 和反馈处理纳入 PM 能力模型。AI 产品不是 demo 能跑就够；PM 需要能描述质量标准、识别 prompt 问题、推动 eval throughput，并把客户研究、内部 Slack 反馈和服务管理工单转为可 triage、可实现、可复用的工程输入。Tamar 的案例显示，PM 的新杠杆往往不在“替工程师写更多代码”，而在让团队更快知道什么值得修、如何判断好坏、哪些反馈代表真实客户需求。

第四个应用是组织训练。Atlassian 没有把答案简化成“招聘 AI native”。它已有许多优秀 PM，所以建立 AI fluency index，把工具使用、eval、数据洞察自动化、原型、技术素养等能力分层，并用季度 AI Builders Week 让 PM 和设计师在项目中练习。其他组织可以借鉴这种结构，但要保留 Tamar 的边界：指数不是晋升 ladder，晋升仍应看 outcome 和客户产出；训练主题也应围绕团队当前瓶颈，而不是追逐最新工具。

最后，衡量要谨慎。Atlassian 跟踪 deployed PRs、features delivered、idea 到客户使用、OKR、团队和组织 throughput，但 Tamar 明确说他们还没有完全 figured out。对其他团队来说，这意味着不要把“PR 数”“agent 使用次数”或“生成代码量”当成最终价值。更稳妥的做法是同时看交付速度、客户是否使用、缺陷和返工、合规与可访问性，以及团队是否减少了低杠杆的手工劳动。AI 可以减少手写周报、手工汇总研究、从零制作 slides 和部分同步会议，但它不能替 PM 判断方向是否正确，也不能替团队承担复杂产品的风险。

来源

• 原始节目：Roles aren't converging—they're expanding | Tamar Yehoshua (Atlassian CPO)