划桨还是掌舵：Atlassian 产品经理怎样变成 AI 构建者

Tamar Yehoshua 是 Atlassian 的首席产品官。她在 Lenny and Friends Summit 上对一屋子产品负责人说，一两年前人人都在指着别人的工种预言它会消失：产品经理说工程师没了，设计师说产品经理没了，大家都紧张。那种说法现在听得少了。她听到的是：岗位在重叠，而且出现了真正的“AI 构建者”。创业公司在招构建者，不一定再分开招产品经理和设计师。创始人从一开始就身兼数职，所以这种角色并不新鲜。

更难的问题是：超过一万人的公司里，这套东西长什么样。她刻意不谈工程侧已经在用的编码智能体和重构，只谈产品经理。她看到角色在重叠，也在变宽，每个人能做的事比以前多得多。产品经理的工作仍是找到产品市场契合、做出人们喜欢的产品，并做成别人愿意付钱的生意。这些目标没变，变的是怎么做。

有人问她怎么跟上所有 AI 动态。她的答案是跟不上，也劝人别把 X 上读到的都当真，要看对自己客户真正有用的东西。另一件在变的是上下文。Atlassian 做了他们称为 teamwork graph 的东西，能看到组织里的完整上下文。以前产品经理要在会里做笔记、追待办、通知上市团队何时上线，现在这些可以由工具来做。

她讲了上周的一件事。CEO Mike 私信她和一位产品负责人，问某个功能何时上线。五分钟后他发来 Rovo（Atlassian 的 AI 产品）的截图，问说得对不对。对了。他说抱歉浪费了你们的时间。信息大家已经拿得到，但还要帮人真正用起来，这里有变革管理。产品经理坐在第一排，看着这一切怎么变。

Atlassian 把加速想成一艘驶向目的地的船：模型的智能，加上组织的上下文。每位产品经理要决定自己是在划桨还是在掌舵。公司试过不同的团队结构并测量产出，结论是看情况：取决于什么产品、处在什么阶段。她接下来用三个例子说明：现有代码库上的新功能、从零开始的产品，以及超大代码库上的增强。

第一个例子是 Confluence 新上的 Remix with Rovo 和 Confluence Slides：圈一段文字改成多种格式，或把一页一键变成幻灯片。这是现有代码库上的新功能，而且必须合规、安全。团队一开始就给自己出题：怎么建得更快，怎么显著改工作方式。产品经理 Ya 从没写过代码，也没用过终端。她和工程搭档一起，对方给她做了一套前端合入的辅助装置。她一个月合入 26 个 PR，比组里多数工程师还多。

Lenny 听众可能会问她为什么要写代码。Ya 的理由是：UX 上要修的东西太多，工程师不够，她希望工程师去做更高层的事。评估方面，Slides 这类功能对评估要求很高，产品经理传统上就在做，他们把期望评估方式传给工程，评估吞吐变成两倍。他们还用 Arize 查提示词问题，再更快交给工程师。

她最喜欢的一项是自动修设计偏差。团队用 Figma MCP 把设计对到代码上，再让编码智能体去修，大约一小时能修 14 个设计缺陷。测试创建从半天变成 10 分钟。Remix 六周上线，Slides 八周上线。Yehoshua 说，AI 之前这类事大约要六个月。产品经理在这里是划桨；工程经理给了干净、隔离的仓库，团队事先约定贡献方式，有意模糊角色，并质疑现有流程。

第二个例子叫 Rovoclaw，是从零做起的项目，不要和 Rovo 产品本身混在一起。产品经理 Josh 和设计师 Kevin 把整件东西 vibe code 到可内部使用的 alpha，确认方向对了，才把工程师加进来。之后产品和设计仍在合入代码，工程师也在干活。Josh 很快发现，自己忙着写代码时，工程师开始跑偏。他问自己：写代码还是最高杠杆的事吗？

他退回来做产品经理常做的事：定方向、排优先级、清障。之后事情快了起来。正因为开头自己写过代码，他懂卡点和难点，掌舵也掌得更好。另一边，他在正在做的产品里做了一个智能体，让 Rovoclaw 自己写每周进展，写得还挺好笑，从此他不再手写周报。这个项目里，产品经理先划桨，阶段变了再改成掌舵，把时间放在当时杠杆最高的事上。

Jira 做过 20 多年，从数据中心走到云，还要支持隔离云和 FedRAMP，服务几十万客户，搞砸不起。Yehoshua 说这里让产品经理往生产代码里合入会危险，所以他们没这么做。目标是把 Jira 做成 AI 优先，让客户能把工作派给智能体、在软件开发生命周期里无缝用智能体。从“进行中”到上线，吞吐大约是平时的三倍，大约 10 周交出 22 个面向用户的功能。

原型从 Loom 开始：录下要改的界面或带解说的 Figma，自动生成工作项；产品经理把一项标成进行中，就会在云里拉起托管的编码智能体，代码直接写进前端仓库。产品经理不用管本地环境，产出已经合规、可访问，并符合 Atlassian 设计语言，交给开发更快。Slack 里的反馈和缺陷由 Jira 智能体分拣，再送给编码智能体去修。用户研究里超过 900 条反馈，用 Rovo 智能体分类，质量让他们惊喜。

这里产品经理明显在掌舵：给工程师清障、更有效地处理内外部反馈、做出可复用的原型，不往生产环境合代码。汇总来看，产品经理现在做原型、测试、写评估、更深地挖客户反馈、消化远更多信息；不再手写更新、手编调研、从零做幻灯片。同步会议她不敢说没了，但她认为变少了。这一切成立的前提，是 AI 工具通过 teamwork graph 理解组织上下文。

创业公司常说去招 AI 原住民。Atlassian 已经有很多出色的产品经理，他们想让这些人变成会用 AI 的人。公司做了 AI 流畅度指数，覆盖六项能力，例如会不会用工具、会不会自动做数据洞察、会不会做原型、技术素养够不够。分数从 1（好奇）到 3（能用）再到 5（开拓）。这是发展指南，不是晋升阶梯；阶梯看的是给客户的结果。公司预期大家迟早在各项上到 L3，并在团队最需要的那项冲到 L5。

试过多种培训后，真正留下来的是每季度一次的 AI 构建周：那一周不做日常工作，请外部讲师，由内部更熟某一技能的产品经理教同事，再做一个动手项目。超过一千人参加过，产出 120 多个事后仍在用的新工作流。每一周只盯一件事：先是原型，然后是评估，再是做智能体，最近一次是合入代码。他们还做成“盒装 AI 构建周”放在网站上，把日程和用法公开给客户。

被问到怎么衡量结果，Yehoshua 说他们还没想清楚，她觉得也没人想清楚，这和测开发者速度是一类老问题。他们看的是部署到生产的 PR，而不是写了多少 PR；看功能从想法到交到客户手里并被使用；看 OKR 和整体吞吐。团队吞吐和组织吞吐都要看。她以乐观收尾：角色都在变宽，产品经理能把活干得更有效，也能给客户交更多东西。她认为现在是做产品经理最好的时候。