Roles aren't converging—they're expanding | Tamar Yehoshua (Atlassian CPO)
频道: Lenny's Podcast
视频: https://www.youtube.com/watch?v=BtK4kFI1LNo
原文语言: en
统计: 共 14 轮 · Tamar 14
[0:06] Tamar
Wow. It's so amazing to be in a room with so many awesome product leaders. I think this is the first time I've been together with so many product people in one room. Uh and so many of you I recognize and know it's it's really amazing. And with many of you, I've had conversations over the last year or two about what is our job and what is the role of a PM. So that's what I'm here to talk to you about. What are we actually seeing practically on the ground? If you remember back a year or two ago, if we can all remember that far back, everyone was pointing at everyone else's craft and saying, "Your job is going to go away." PMS were telling engineers their job was going to go away. PMs, designers were telling PMs, everyone was saying that everyone's job is going away. And everyone was actually really nervous that their job was going away. Thankfully, we are not hearing that anymore. What are we hearing today? Well, each job is overlapping. In fact, and there's a new era of the AI builder. If you listen to Lenny Lenny's podcast, if you talk to people at startups, if you read tweets on X, you will see that a lot of people are talking about the AI builder. And the AI builder job is real.
哇。能和这么多出色的产品负责人待在同一个房间里，太棒了。我想这是我头一回和这么多做产品的人聚在一间屋子里。呃，在座很多人我都认得、都熟，真的很棒。过去一两年里，我和你们当中不少人都聊过：我们的工作到底是什么，PM（产品经理）这个角色到底是什么。所以我今天就是来跟大家聊这个的：在一线，我们实际看到的到底是什么情况？回想一两年前——如果大家还记得那么久以前的事——每个人都指着别人的那门手艺说：“你的工作要没了。”PM 跟工程师说他们的工作要没了，设计师又跟 PM 这么说，人人都在说别人的工作要没了。而且大家是真的很紧张，怕自己的工作没了。谢天谢地，现在已经听不到这种话了。那今天听到的是什么呢？是各个岗位在相互重叠。事实上，还出现了一个 AI builder 的新时代（builder，就是亲手把东西做出来的人）。如果你听 Lenny's Podcast，如果你跟创业公司的人聊，如果你在 X 上看推文，就会发现很多人都在谈 AI builder。而 AI builder 这个岗位是真实存在的。
[1:21] Tamar
There are startups that are not hiring PMs or not hiring designers. They are hiring builders. There's job descriptions. There's builders in small companies. There's builders in large companies. And if you think about it, this has always been the case for founders. Founders have always when they started a company been the builder and really worn lots of hats. So I do believe that this is something that is very real that's happening and also very exciting. But what does this look like in a company with over 10,000 people? I'm sure many of you work in large companies that are not five person startups or 10 person startups and you listen to these podcasts and you kind of scratch your head and you say that would be really cool to work like that. I don't have that reality. So what I'm going to do is I'm going to talk to you about what it looks like at Atlassian. I'm not going to go into what the engineering teams are doing. Of course they're doing a lot. They're using coding agents. They're refactoring their code bases. There's a lot of work going on the on the engineering side. I'm going to focus on the PM and what's happening there. As we said, the roles are overlapping, but they are also expanding. So that's what we're seeing is the people everyone can do so much more than they that they could do before and it's exciting. So the job of a PM is really the same as it always was. What is your job? It's to find product market fit. It's to build products that people love. It's also to make sure you're building a business that people will actually pay for your products. None of that has really changed. It's how we do it that's changed. And what has changed?
有些创业公司已经不招 PM、不招设计师了，他们招的是 builder。有这样的职位描述，小公司里有 builder，大公司里也有 builder。仔细想想，创始人向来如此：创始人创办公司的时候一直就是那个 builder，真的是身兼数职。所以我确实相信，这是一件正在真实发生的事，也非常令人兴奋。但在一家一万多人的公司里，这会是什么样子？我相信在座很多人都在大公司工作，不是五个人、十个人的创业公司。你们听着这些播客，会有点挠头，心想：能那样工作一定很酷，可我面对的现实不是那样。所以我接下来要讲的，就是这件事在 Atlassian 是什么样子。我不打算展开讲工程团队在做什么——他们当然做了很多：在用 coding agent，在重构代码库，工程那边有大量工作在进行。我要聚焦的是 PM，以及 PM 这边在发生什么。就像前面说的，各个角色在重叠，但它们同时也在扩展。这就是我们看到的：每个人能做的事都比以前多得多，这很让人兴奋。所以 PM 的工作其实和过去一直以来的一样。你的工作是什么？是找到产品市场契合（PMF），是做出人们喜爱的产品，同时还要确保你在做的是一门生意——人们真的愿意为你的产品付钱。这些其实都没变。变的是我们做这些事的方式。那到底变了什么呢？
[2:59] Tamar
Obviously, AI tools have gotten much better and continue to get better at a rapid rate. And one of the questions that I get a lot from some of the people in this room is like, how do you stay on top of it all? And the answer is you don't. So, I don't think anybody could. But the tip is that everything that you read on X, don't believe. You have to figure out what's actually working for your customers. So focus on the customer and what they can get out of the AI tools. The other thing that is changing is context. You've been hearing all about context graphs. You've been hearing about how you need to have an enterprise brain. Well, this is very real. You now can see through lots of different tools the context of your organization. And at lastian we built what we call the teamwork graph that you can see the con full context of your organization. So what does this mean for the PM? Well the PM used to be the person taking notes in meetings, following up on action items, communicating with go to market when things are going to launch. They don't have to do that anymore. We have tools that can do that. The other day, last week, Mike, our CEO, DM'd me and one of the product leads and says, "When when is some feature launching?" Five minutes later, he sent a screenshot of Rovo, which is Atlassian's AI product, and said, "This is what Robo said. Is it right?" We're like, "Yeah." And he said, "Sorry, I wasted your time." And so, what we are seeing is people have access to this information, but we also have to help them along so that they actually use it. There's change management involved, but PMS have a front row seat into how all of this is changing. And one of the things that PMs can do is focus on acceleration. We've all been hearing how things are moving so much faster, but the PM can really help accelerate what's happening in their team. At Alaskan, we think about it as a ship that is going. So you have a ship
显然，AI 工具已经好了很多，而且还在飞快地继续变好。在座有些人经常问我一个问题：你是怎么跟上这一切的？答案是：跟不上。我觉得没有谁能跟得上。不过有个小建议：你在 X 上读到的东西，都别信。你得自己弄清楚什么对你的客户真正管用。所以，把注意力放在客户身上，放在他们能从 AI 工具里得到什么上。另一个在变的东西是上下文。你们一直在听人讲 context graph（上下文图谱），一直在听人说你得有一个“企业大脑”。嗯，这是千真万确的。现在你可以通过各种各样的工具看到自己组织的上下文。在 Atlassian，我们做了一个叫 Teamwork Graph 的东西，让你能看到组织的完整上下文。那这对 PM 意味着什么？过去，PM 是那个在会上做记录、跟进待办事项、跟 go-to-market 团队沟通什么时候上线的人。现在他们不用再做这些了，我们有工具能做。前几天，就上周，我们的 CEO Mike 给我和一位产品负责人发私信，问：“某某功能什么时候上线？”五分钟后，他发来一张 Rovo 的截图——Rovo 是 Atlassian 的 AI 产品——说：“Rovo 是这么说的，对吗？”我们说：“对。”他说：“抱歉，浪费你们时间了。”所以我们看到的是，大家已经能拿到这些信息了，但我们还得推他们一把，让他们真的去用。这里面有变革管理的成分，不过 PM 正坐在第一排，看着这一切是怎么变的。而 PM 能做的一件事，就是专注于加速。我们都一直在听说事情推进得快了很多，而 PM 真的可以帮自己团队里正在发生的事再提速。在 Atlassian，我们把它想成一艘正在行驶的船。也就是说，你有一艘船
[4:56] Tamar
that is going through to get to your destination. How are you going to get to your destination faster? One of the things is intelligence plus context. So the intelligence of the models plus the context of your organization, how can you put that together to move faster? Now going back to the ship metaphor, are you as a PM, are you rowing or are you steering? What is the best way for you to make the ship go faster? So we've done a bunch of experiments. We've organized teams in different ways, measured outputs, and the answer that we have come to is it depends. It depends what type of product it is. It depends on what phase in the product it is. So what I want to do now is actually talk through three concrete examples and what the role of the PM was in each one. Now one is a new feature in an existing codebase. Another is a 0ero to1 product and another is enhancements in a very large existing codebase. All the examples are obviously using Atlassian products because that's what we use internally. But of course you can use all of this is true with whatever products your company uses. So we're going to start with Confluence. So Confluence recently launched two features called remix with robo and confluence slides. So remix is you highlight a piece of text, you remix it into multiple different formats. You choose the format and slides is you take a page and you click a button and it converts it into beautiful slides.
正在驶向你的目的地。你要怎样才能更快到达目的地？其中一点是智能加上下文。也就是模型的智能，加上你所在组织的上下文——怎么把这两样合在一起，走得更快？回到船的比喻：作为 PM，你是在划桨，还是在掌舵？你用哪种方式最能让这艘船跑得更快？我们做了一堆实验，用不同的方式组织团队、衡量产出，最后得出的答案是：看情况。要看是什么类型的产品，要看产品处在哪个阶段。所以我现在想做的，是具体讲三个例子，以及 PM 在每个例子里扮演的角色。第一个是在已有代码库里做一个新功能，第二个是一个从 0 到 1 的产品，第三个是在一个非常庞大的已有代码库里做增强。这些例子用的显然都是 Atlassian 的产品，因为我们内部用的就是这些。但当然，不管你们公司用什么产品，这些道理都同样成立。我们先从 Confluence 说起。Confluence 最近上线了两个功能，叫 Remix with Rovo 和 Confluence Slides。Remix 就是你选中一段文字，把它 remix 成多种不同的格式，格式由你来选。Slides 则是你拿一个页面，点一下按钮，它就把页面转成漂亮的幻灯片。
[6:23] Tamar
Obviously these are you heavily based on AI. When the team started, they didn't just say, "Here's what I want to build." They took a challenge of how do I build it much faster and how do I significantly change how I work? And again, in a big company, this is different than you have a clean slate and you're just starting. So, I'm going to go through what are some things that changed for the confluence team. So, first PM started checking in code. I'm sure if I asked you to raise your hand, many of you are checking in code as well. This PM Ya had never written any code, had never even used a terminal before, but she sat down with the engineering partner who actually built a harness for her to use that made it easier for her to check in code in the front end. And so sometimes you have to partner with somebody else to figure out how you can leverage the tools the best. She ended up checking in 26 PRs in a month, which was more than most of the engineers on the team. I asked her why. Why did she decide she was going to check in code? and she said there were so many things we needed to fix in the UX and we didn't have enough engineers to do it and I wanted the engineers to focus on higher level activities and this is something I could do. So she felt that this would accelerate the project. Next is EVELS.
显然，这些功能都高度依赖 AI。团队起步的时候，并不只是说“这就是我想做的东西”。他们给自己立了一个挑战：我怎么才能做得快得多，怎么才能大幅改变自己的工作方式？再说一遍，在大公司里，这和你有一张白纸、刚刚起步的情况不一样。所以我来讲讲 Confluence 团队有哪些东西变了。第一，PM 开始提交代码了。我相信如果我请大家举手，你们很多人也在提交代码。这位 PM 以前从没写过任何代码，连终端都没用过，但她和搭档的工程师坐到了一起，对方专门给她搭了一个 harness，让她往前端提交代码变得容易了。所以有时候你得找别人搭档，才能摸清怎么把工具用到最好。结果她一个月提交了 26 个 PR，比团队里大多数工程师都多。我问她为什么，为什么决定自己去提交代码？她说：UX 上有太多东西需要修，我们又没有足够的工程师来做；我希望工程师专注在更高层次的事情上，而这件事是我能做的。所以她觉得这样能给项目提速。接下来是 evals（评测）。
[7:40] Tamar
So I assume I hope most of you understand that EVELS is a significant part of your job now and that you're training yourselves or taking classes on how to do EVELs. different teams. Sometimes the PMs do eval, sometimes the engineers do evals. Well, in this instance, the evals for something like confluence slides was so important to get right. That the PMs had done them traditionally and they worked with the engineers to make sure that they relayed how they wanted the team to eval this product and then they got a 2x throughput in eval. The PMS in turn started using the LLM platform. We use arise at Atlassian for debugging. So they were using the platform to find issues with the prompts and then send it to the engineers again faster. I think this one is my favorite. They automated the fixing of design bugs. How many times have you seen the code and it didn't match the design? So they used Figma MCP and mapped the designs from Figma to the actual code and then automated the fixing with a coding agent. And so they could fix something like 14 bugs in an hour. So this again made the product much better. The last one was test creation. This the engineers went from creating a test in a half day to 10 minutes. Just huge throughput improvements. So in this example, the remix launched in 6 weeks, Confluence launched in 8 weeks. Now if you're at a startup, you might be like, "Oh my god, that's still a long time."
我想——我希望——你们大多数人都明白，evals 现在是你工作里很重要的一部分，而且你们正在自学或者上课学怎么做 evals。不同团队做法不一样，有时候是 PM 做 eval，有时候是工程师做 evals。而在这个例子里，像 Confluence Slides 这样的东西，evals 做对实在太重要了。以往一直是 PM 在做，这次他们和工程师配合，确保把自己希望团队怎么评测这个产品传达清楚，结果 eval 的产出量（throughput）提高到了 2 倍。反过来，PM 也开始用起了 LLM 平台——我们 Atlassian 用 Arize 做调试。他们用这个平台找出 prompt 的问题，再发给工程师，同样是更快了。下面这个我觉得是我最喜欢的：他们把修设计 bug 这件事自动化了。你们有多少次看到代码和设计稿对不上？他们用 Figma MCP，把 Figma 里的设计映射到实际的代码上，再用 coding agent 自动修复。这样他们一个小时能修掉大概 14 个 bug。这同样让产品好了很多。最后一项是写测试。工程师写一个测试，从原来的半天缩短到了 10 分钟。产出量的提升非常大。所以在这个例子里，Remix 用 6 周上线，Confluence Slides 用了 8 周。如果你在创业公司，你可能会想：“天哪，这还是很久啊。”
[9:04] Tamar
But remember, this is enterprise software that has to be compliant, has to be secure, and sometimes doing this stuff takes the longest to get done to make sure your enterprise customers can use it. So what would have taken before AI about 6 months now took 6 weeks with much tighter iteration loops. So the iteration loops with the customers, with the the beta customers, and internally just fix things much faster. So taking a step back here, what was the role of the PM? The PM was actually rowing and checking in code. And this is what she decided was the fastest thing to make the ship go faster. The engineering manager gave her a clean isolated repository, which is very important. So nothing got messed up in the larger repository. And the team up front had a very intentional contribution uh model of who was going to do what and they blurred the roles by design and they said we're going to question existing processes. So this is one example. Next is a project called Roclaw. Now Robo is our product. Not to be confused. This was not a feature on Robo. This was a zero to one pro project from the ground up written. Now it started with a PM Josh and a designer Kevin. They vibe coded the whole thing. They from soup to nuts got to a working alpha that they got customers using internally. And once they saw they were onto something, then they added engineers to the project. So then we got the PMs and the designers were still checking in code and the engineers were working as well. But Josh started to see that the engineers started veering off track because he was busy writing code and he one day is like wait a minute should I be spending my time coding? Is this actually the highest leverage activity that I could be doing? So he decided to step back from the coding and to focus on what a PM usually does setting direction prioritizing and unlocking. And then things started moving much faster. The fact that he had started out by coding
但别忘了，这是企业级软件，必须合规，必须安全，而有时候恰恰是这些事花的时间最长——要确保你的企业客户能用。所以，在有 AI 之前大约要花 6 个月的事，现在只用了 6 周，而且迭代循环紧凑得多。也就是说，和客户、和 beta 客户、以及内部的迭代循环，修起问题来都快得多。那么退一步看，PM 在这里的角色是什么？这位 PM 其实是在划桨，在提交代码。这是她判断下来最能让这艘船跑得更快的办法。工程经理给了她一个干净、隔离的代码仓库，这一点非常重要，这样大仓库里就不会有东西被搞乱。而且团队一开始就非常有意识地定了一个贡献模式——谁来做什么；他们是有意把角色边界模糊掉的，并且说：我们要质疑现有的流程。这是第一个例子。下一个是一个叫 RovoClaw 的项目。Rovo 是我们的产品，别搞混了——这不是 Rovo 上的一个功能，而是一个从 0 到 1、从零写起的项目。它一开始只有一位 PM Josh 和一位设计师 Kevin，整个东西都是他们 vibe coding 出来的。他们从头到尾一手做出了一个能跑的 alpha 版，并且让内部的用户用了起来。等他们看出这事有戏，才给项目加了工程师。于是就变成了 PM 和设计师还在提交代码，工程师也在干活。但 Josh 开始发现工程师渐渐跑偏了，因为他自己正忙着写代码。有一天他突然想：等一下，我的时间该花在写代码上吗？这真的是我能做的杠杆最高的事吗？于是他决定从写代码里抽身出来，专注于 PM 通常做的事：定方向、排优先级、清障。然后事情就推进得快多了。他一开始是从写代码起步的，这一点
[11:16] Tamar
significantly helped him because he could understand what the blockers were. He could understand what the challenges were and it made for a much better environment of how he could steer the team. And then on the flip side, he also used AI to help him not do other things. I hope most of you are not writing weekly reports by hand anymore. And if you are, you probably don't want to admit it, but please go and write build an agent to do it. So Josh used uh Rovoclaw and built an agent in the product he was developing to give the weekly updates on itself which were super amusing and so he no longer writes weekly updates. So in this instance the PM started out rowing and then shifted to steering because it was a different phase of the project and that's what he needed to do to make the project go faster. So he was unfocused on unblocking the team whatever he needed to do at that point in time and he had the ability to contribute code which really helped him. So he focused on his highest leverage activities. Okay, last example, Jira. Most of you have probably heard of Jira. Many of you have used it. Jira has been around for over 20 years. It's a huge complicated codebase. We have things like it started on data center and then moved to the cloud. It it supports isolated cloud. It supports Fed ramp. It supports the customizations. and you have we have hundreds of thousands of customers that you can't mess up. So this instance of PM checking in code can be kind of dangerous. So we didn't want to do that.
对他帮助非常大，因为他看得懂卡点在哪儿、难点在哪儿，这让他给团队掌舵的条件好了很多。反过来，他也用 AI 帮自己把另一些事省掉了。我希望在座大多数人都已经不再手写周报了。如果你还在手写，大概也不太想承认，但拜托，去做一个 agent 来干这件事。Josh 就用上了 RovoClaw，在他自己正在开发的这个产品里做了一个 agent，让它来汇报它自己的每周进展，那些周报读起来特别逗，所以他现在不用再写周报了。所以在这个例子里，PM 一开始是在划桨，后来转去掌舵，因为项目进入了另一个阶段，要让项目跑得更快，他就得这么做。他专注于给团队清障，那个时间点上需要他做什么他就做什么，而他有能力贡献代码，这一点确实帮了他大忙。所以他把精力放在了自己杠杆最高的事情上。好，最后一个例子，Jira。在座大多数人应该都听说过 Jira，很多人也用过。Jira 已经存在二十多年了，代码库庞大又复杂。比如说，它最早是在 Data Center 上起步的，后来才迁到云上；它要支持 Isolated Cloud，要支持 FedRAMP，要支持各种定制；而且我们有几十万客户，是绝对不能搞砸的。所以在这种情况下，让 PM 提交代码可能有点危险。所以我们没打算这么干。
[12:56] Tamar
But we also had to bring Jira into the AI age. And our goal was to make it AI first. And so the PMs and the engineers were building AI features in Jira to help the customers use AI to do their software development, which was really fun. like how are you reinventing the software development life cycle with the tools that you're building and how do you make sure you can assign to agents how do you make sure you can seam seamlessly use agents for everything in Jira so this was a big project for the team and from in progress to shipped their throughput was about 3x what it normally was and they shipped in about 10 weeks 22 userfacing features how did they do it what were the changes they made so let's start with prototyping. Again, everybody here is prototyping that. I'm 100% sure. But what did they do to make the prototyping more effective? So, first they started with Loom. And in a Loom video, you could record the UI that you wanted to change or you could record here the Figma designs with a talk track or you could just brainstorm that goes into a recording and then Loom has the ability from the recording to automatically create work items. And then from the work item the PM can move it to in progress and then that automatically kicks off a coding agent. So this whole thing was very streamlined and the coding agent wrote code in the actual front-end repository and used a managed agent in the cloud.
但我们也得把 Jira 带进 AI 时代。我们的目标是让它变成 AI 优先。所以 PM 和工程师们就在 Jira 里做 AI 功能，帮客户用 AI 来做他们自己的软件开发，这件事特别有意思。比如，你怎么用自己正在做的这些工具去重新发明软件开发生命周期？怎么确保能把任务指派给 agent？怎么确保在 Jira 里做任何事都能无缝用上 agent？所以这对团队来说是个大项目。从「进行中」到「已发布」，他们的产出量（throughput）大约是平时的 3 倍，大概 10 周时间上线了 22 个面向用户的功能。他们是怎么做到的？做了哪些改变？我们先从做原型说起。还是那句话，在座每个人都在做原型，这一点我百分之百确定。但他们做了什么，让做原型这件事更有成效？首先，他们从 Loom 入手。在一段 Loom 视频里，你可以把想改的 UI 录下来，也可以把 Figma 设计稿配上讲解录下来，或者干脆就是头脑风暴，这些都进到录像里；而 Loom 能从录像里自动创建工作项。接着 PM 把工作项挪到「进行中」，这一步就会自动启动一个 coding agent。所以整个流程非常顺畅，而且 coding agent 是在真正的前端代码仓库里写代码，用的是云端托管 agent。
[14:29] Tamar
So PMS didn't have to deal with their local environment. So then you got code that was already compliant, accessible and in the Atlassian design language. So when they were done, if they wanted to implement the prototype, it was much more seamless and the handoff to developers was much faster. So having the right environment for prototyping is key of getting it faster into the engineers hands. So this was a big unlock. Next was triaging feedback. As you can imagine, if you're use if you're making changes in Jira at a company like Atlassian, everybody in the company is using it and you get tons of feedback. So, what did we do? We took the feedback and the bugs that came in through Slack and we used the Jira agent in Slack to triage them and then automatically send them to the coding agent for fixes. Again, saving a huge amount of time for engineering. And then we also did a lot of user studies for customer insights. So here we used Jira service management to take and review all of the videos from the customer insights. We got over 900 pieces of feedback. We use used a robo agent to then triage and categorize them. And we were very happily surprised with the quality that we got of the triage. So then we knew what to send to engineering to fix. All of these things together in this instance the PM was clearly steering. The PM had to focus on unblocking the engineers in order to make the project go faster. That included processing feedback internally, externally more effectively, and building prototypes that were set for reuse. And as I said in the beginning, PMS did not check in code to the production environment. So, if you put all this together, what are things that PMs are doing now that they weren't doing before? They're obviously prototyping and testing. They're writing evals. They're going deeper on customer feedback. They're consuming information at a much higher rate rate. And all of
所以 PM 不用去折腾自己的本地环境。这样拿到的代码本身就已经合规、满足无障碍要求，而且符合 Atlassian 的设计语言。所以做完之后，如果他们想把这个原型真正实现出来，过程就顺畅得多，交接给开发也快得多。所以，有一个合适的原型环境，是让东西更快到工程师手里的关键。这是一个很大的突破点。接下来是反馈分拣。你可以想象，在 Atlassian 这样的公司里改 Jira，全公司每个人都在用它，你会收到海量的反馈。那我们怎么做的？我们把从 Slack 进来的反馈和 bug，用 Slack 里的 Jira agent 做分拣，然后自动发给 coding agent 去修。同样，这给工程团队省下了大量时间。另外我们还做了很多用户研究来获取客户洞察。这里我们用 Jira Service Management 来接收并过一遍客户洞察里的所有视频。我们拿到了 900 多条反馈，然后用一个 Rovo agent 来分拣和归类。分拣出来的质量让我们又惊又喜。这样我们就知道该把哪些发给工程去修。把这些合在一起看，在这个例子里，PM 显然是在掌舵。PM 得专注于给工程师清障，才能让项目跑得更快。这包括更高效地处理内部和外部的反馈，也包括做出为复用而准备的原型。而且就像我一开始说的，PM 没有往生产环境提交代码。所以，把这些全放在一起看，PM 现在在做哪些以前不做的事？他们显然在做原型、做测试。他们在写 evals。他们在客户反馈上挖得更深。他们消化信息的速度比以前高得多。而这一切
[16:32] Tamar
this works if all the AI tools understand the context of your organization. And that is built on top of at Atlassian the teamwork graph. And then what are they not doing? They are not doing manual updates. They're not compiling research by hand. They're not creating SLI uh slides from scratch. I would love to say that there are no synchronous meetings, but that would be an exaggeration. uh but there are I believe fewer synchronous meetings. Well, how did we do this? What was our playbook at Atlassian? When I talk to people at startups, they tell me hire people that are AI native. Well, we have a lot of PMs already who are amazing PMs at Atlassian. So, we want them to become AI native. We want to help them be able to learn the skills that they need to learn uh in order to build products for our customers. So we introduced something that we call the AI fluency index and this is to help people understand where they need to go and we have six capabilities in the fluency index. Things like do you understand how to use the tools? Do you understand how to write emails? Do you understand how to automate data insights? Can you prototype? And do you have the level of technical literacy that you need? And then we have an index from one to five.
要行得通，前提是所有 AI 工具都理解你所在组织的上下文。在 Atlassian，这是建立在 Teamwork Graph 之上的。那他们不再做什么了？他们不再手动更新进展，不再手工汇总调研，不再从零开始做幻灯片。我很想说现在已经没有同步会议了，但那就夸张了。不过我相信同步会议是变少了。那我们是怎么做到的？Atlassian 的打法是什么？我跟创业公司的人聊，他们跟我说：去招 AI 原生的人。可是我们在 Atlassian 已经有很多 PM 了，都是非常出色的 PM。所以我们希望他们变成 AI 原生的。我们想帮他们学会需要掌握的技能，好为我们的客户做产品。所以我们推出了一个东西，叫 AI 熟练度指数（AI Fluency Index），用来帮大家搞清楚自己该往哪儿走。这个指数里有六项能力，比如：你会不会用这些工具？你会不会写 evals？你会不会把数据洞察自动化？你能不能做原型？你有没有达到所需的技术素养水平？然后我们有一个从 1 到 5 的分级。
[17:49] Tamar
One is curious, five is pioneering, three is capable, and we do not expect every PM to be a five at everything. And this is not a ladder. This is for development. So that you have a northstar on the skills that you need to be developing because of course this changes all the time. The ladder is about outcomes and what you produce for your customer. This is helping PMS understand the skills that they should be attaining. We do expect people to get to an L3 in all of these over time and you should understand what your team needs. You should understand what is the most important point for your team and that you focus on getting to an L5. How do we train PM? So we want them to become AI fluent. Uh we've tried a bunch of different things and the thing that stuck the most was our AI builder weeks. So, our AI builder week is once a quarter. We take a week where you're not doing your regular work and we train PMs and designers. It starts with bringing in external speakers. Shout out to Claire who came to our last builder week. And then we have PMs internally in the organization who are more advanced in certain skills training other PMs. And then we have people do a project. So it depending on what it is, they can work with their teams, they can work with other people that but they do a project to use the skills they're learning. This has been incredibly successful. We've had over a thousand people go through our builder weeks.
1 级是 curious（好奇），5 级是 pioneering（开拓），3 级是 capable（胜任）。我们并不指望每个 PM 在每一项上都到 5 级。而且这不是职级阶梯，这是用来做能力发展的。这样你对自己该发展哪些技能就有了一个北极星，因为这些东西当然一直在变。职级阶梯看的是成果，是你为客户交付了什么。而这个是帮 PM 弄清楚自己应该去掌握哪些技能。我们确实期望大家假以时日在所有这些项上都达到 L3，同时你应该清楚你的团队需要什么，清楚对你的团队来说哪一项最重要，然后在那一项上专注做到 L5。那我们怎么培训 PM 呢？我们希望他们把 AI 用得很熟练。我们试过一堆不同的办法，最后真正留下来的是我们的 AI Builder Weeks。AI Builder Week 每个季度一次。我们拿出一周时间，这一周你不做日常工作，由我们来培训 PM 和设计师。先是请外部讲者来分享。在这儿要特别感谢 Claire，她来了我们上一次的 Builder Week。然后是组织内部在某些技能上更领先的 PM，来培训其他 PM。再然后我们让大家做一个项目。具体看是什么项目，可以和自己的团队一起做，也可以和别的人一起做，但总之要做一个项目，把正在学的技能用起来。这件事非常成功。已经有一千多人参加过我们的 Builder Weeks。
[19:20] Tamar
We've built over 120 new workflows that people are using after the builder weeks. So what are the focus and we focus on one thing each time. So the first one was prototyping. The second one was uh eval. Third one was how do you build agents? And then the the most recent one was checking in code. We have talked to customers a lot about this and we've actually built an AI builder week in a box. You can find it in our website where it shows you kind of the agendas that we've had and how we've utilized them. Okay. So now we've told the PMS where what they're going to achieve. We've trained them. And what is a question I get from customers all the time is how are you measuring outcomes? I'll be honest, we haven't figured it out. I don't think anyone has figured it out. I talked to a lot of people about this and everyone is I mean it's the age-old how do you measure developer velocity. Um we are measuring PRs deployed not PRs written but PR is deployed to production. We're measuring features delivered. It's a little tricky to figure out when the feature started but from idea to delivery in the customer's hands and usage. Obviously you want to have the right OKRs. You want to make sure that your OKRs being met and like overall throughput.
Builder Weeks 之后，我们已经做出了 120 多个大家正在用的新工作流。那每次的重点是什么？我们每次只聚焦一件事。第一次是做原型。第二次是 eval。第三次是怎么搭建 agent。最近的一次是提交代码。这件事我们跟客户聊过很多，而且我们还真做了一个「AI Builder Week in a box」，在我们的网站上就能找到，里面大致展示了我们用过的议程，以及我们是怎么用的。好。那现在我们已经告诉了 PM 他们要达到什么目标，也培训了他们。而我一天到晚被客户问到的一个问题是：你们怎么衡量成果？说实话，我们还没搞明白。我觉得没有任何人搞明白了。我跟很多人聊过这件事，大家都……我是说，这就是那个老问题：怎么衡量开发者速度。我们在衡量部署了多少 PR——不是写了多少 PR，而是部署到生产环境的 PR。我们在衡量交付了多少功能。一个功能到底从什么时候算起，这有点难界定，但大致就是从想法，到交付到客户手里，再到使用情况。当然，你得有对的 OKR，得确保你的 OKR 达成了，另外还有整体的产出量。
[20:30] Tamar
Sometimes it's easier to measure the throughput of an individual team versus an organization. So you want to do both. You want to do make sure teams are working faster and organizations are working faster. So if you have ideas of how you're measuring, let me know. But we are working actively each quarter. We have experiments that teams are running in different ways and we look at what we can measure on the outcome. So bringing this all together as I said the roles are expanding each role is expanding and I think the way I look at it PMS can do more to get their jobs done more effectively and better and they can do more to deliver more to their customers. I think this is the best time in the world to be a PM. I think it's super exciting. I am an optimist and I think we'll all be here 10 years from now. But I really think that this you guys are all so lucky to be here today. So that's it. Thank you.
有时候衡量单个团队的产出量，比衡量整个组织的要容易。所以两个你都要做，既要确保团队跑得更快，也要确保组织跑得更快。所以如果你们在怎么衡量这件事上有想法，告诉我。但我们每个季度都在积极推进：各个团队用不同的方式在跑实验，然后我们看在成果上能衡量出什么。所以把这些归拢起来，就像我说的，角色在扩展，每个角色都在扩展。而我的看法是，PM 可以做更多的事，把自己的工作做得更高效、更好，也可以做更多的事，给客户交付更多东西。我认为现在是当 PM 最好的时代。我觉得这太让人兴奋了。我是个乐观主义者，我相信十年后我们都还会在这儿。不过我是真心觉得，你们今天能在这儿，真的都非常幸运。就这些。谢谢大家。