Roles Aren't Converging, They're Expanding: How Atlassian's PMs Work in the AI Builder Era
Lenny's Podcast
At the Lenny and Friends Summit, Atlassian CPO Tamar Yehoshua addressed a question they said had come up in many conversations over the past year or two: what is the job of a product manager now? Their answer, drawn from practice inside a company of more than 10,000 people, is that roles are not only overlapping but expanding. Whether a PM should write code or step back and steer the team depends on the kind of product and the phase it is in. They illustrated this with three concrete Atlassian projects.
From "your job is going away" to the AI builder
Yehoshua recalled that a year or two earlier, "everyone was pointing at everyone else's craft" and predicting that it would disappear. PMs told engineers their jobs were going away, designers said the same to PMs, and people were genuinely nervous. They said that conversation has largely stopped. Now the discussion is about jobs overlapping, and about a new role: the AI builder.
Yehoshua described that role as real. Some startups are not hiring PMs or designers but "builders," with job descriptions to match, and builders exist in both small and large companies. They noted that founders have always worked this way, wearing many hats when starting a company. The question for this talk was what that looks like in a large organization. They pointed out that many people listen to podcasts about five-person startups and cannot see how that applies to their own reality. They chose to set aside the engineering side, where teams are using coding agents and refactoring codebases, and focus only on PMs.
The job is the same; how it gets done has changed
In Yehoshua's view, the PM's core job has not changed. It is still to find product-market fit, build products people love, and make sure the business is one customers will pay for. What has changed is the method.
The first change is the tools, which keep improving quickly. People often ask them how to keep up. Their answer is that you don't, and they doubt anyone can. Their advice is not to believe everything on X, and to focus on what actually works for your customers.
The second change is context. Yehoshua referenced the current talk about context graphs and an "enterprise brain" and said it is very real. At Atlassian, the company built what it calls the teamwork graph to expose the full context of the organization. As a result, the PM no longer has to be the person taking meeting notes, chasing action items, or telling go-to-market teams when things will launch. They gave an example from the previous week. CEO Mike messaged them and a product lead asking when a feature was launching. Five minutes later he sent a screenshot of an answer from Rovo, Atlassian's AI product, and asked whether it was right. It was, and he apologized for wasting their time. Yehoshua's point was that people have access to this information but still need help to actually use it. That is a change-management problem, and PMs have a front-row seat to it.
Rowing or steering?
Yehoshua framed the PM's opportunity as acceleration. Atlassian thinks of a team as a ship heading to a destination, and one way to get there faster is intelligence plus context: the models' intelligence combined with the organization's context.
Within that metaphor, the question for a PM is whether they are rowing or steering. Atlassian ran experiments, organized teams in different ways, and measured output. Yehoshua said the conclusion was "it depends," on the type of product and its phase. They then walked through three examples:
- a new feature in an existing codebase
- a zero-to-one product
- enhancements to a very large existing codebase
Example 1: Confluence — the PM rows and checks in code
Confluence recently launched two AI-based features. Remix with Rovo lets a user highlight text and convert it into a format they choose. Confluence Slides turns a page into slides with a click. Yehoshua stressed that the team did not just decide what to build. They also set themselves the challenge of building much faster and significantly changing how they worked, which they said is different inside a big company than starting from a clean slate.
The PM checked in code. The PM, Ya, had never written code or used a terminal. Her engineering partner built a harness that made it easier for her to check in front-end code. Yehoshua used this to make a broader point: sometimes you need to partner with someone to use the tools well. Ya checked in 26 PRs in a month, which Yehoshua said was more than most engineers on the team. When asked why, she said there were many UX fixes needed, the team lacked engineers to do them, and she wanted engineers focused on higher-level work. She saw this as something she could do to accelerate the project.
Evals. Yehoshua said they hope most PMs understand that evals are now a significant part of the job. On some teams PMs own evals, on others engineers do. For Confluence Slides, getting evals right mattered so much that the PMs, who had traditionally done them, worked with engineers to convey how they wanted the product evaluated. This produced a 2x throughput in evals. The PMs also used Arize, the LLM platform Atlassian uses for debugging, to find problems in prompts and send them to engineers faster.
Automated design-bug fixes. Yehoshua called this their favorite. Code often doesn't match the design, so the team used the Figma MCP to map Figma designs to the actual code, then had a coding agent fix the mismatches. They could fix around 14 bugs in an hour.
Test creation. Engineers went from spending half a day creating a test to about 10 minutes.
Results. Remix launched in six weeks and slides in eight. Yehoshua acknowledged this might sound long to startups, but said enterprise software has to be compliant and secure, and that work often takes longest. They estimated the work would have taken about six months before AI. Iteration loops with beta customers and internal users were also much tighter.
What made it work. In this case the PM was rowing, because she judged that checking in code was the fastest way to move the ship. The engineering manager gave her a clean, isolated repository so nothing in the larger repo got broken, which Yehoshua called very important. The team also agreed up front on an intentional contribution model. They blurred roles by design and committed to questioning existing processes.
Example 2: RovoClaw — from rowing to steering
RovoClaw was not a feature of Rovo but a zero-to-one project built from scratch. It began with a PM, Josh, and a designer, Kevin, who vibe coded the whole thing to a working alpha that internal customers used. Once they saw they were onto something, they added engineers. The PM and designer kept checking in code alongside them.
Josh then noticed the engineers starting to drift off track because he was busy coding. He asked whether coding was really his highest-leverage activity. He decided to step back and do what PMs usually do: set direction, prioritize, and unblock. According to Yehoshua, things then moved much faster. They added that his early coding helped a great deal, because he understood the blockers and challenges, which made him better at steering.
Josh also used AI to stop doing other work. Yehoshua urged anyone still writing weekly reports by hand to build an agent for it. Josh built an agent inside RovoClaw that wrote the weekly updates on the project itself, which Yehoshua called "super amusing," and he no longer writes them.
Their takeaway: the PM started out rowing and shifted to steering because the project had entered a different phase. He focused on whatever unblocked the team at that moment, and his ability to contribute code helped him do that.
Example 3: Jira — steering in a huge, sensitive codebase
Jira has existed for more than 20 years and has a large, complicated codebase. It began on data center and moved to cloud. It supports isolated cloud, FedRAMP, and customizations, and it serves hundreds of thousands of customers that "you can't mess up." In this setting, Yehoshua said, PMs checking in code could be dangerous, so Atlassian chose not to have them do it.
The goal was still to make Jira AI-first. PMs and engineers built AI features to help customers use AI in software development, including rethinking the software development life cycle, assigning work to agents, and using agents seamlessly throughout Jira. From in-progress to shipped, throughput was about 3x the norm, and the team shipped 22 user-facing features in about 10 weeks. Yehoshua described several changes behind that.
Prototyping in the real environment. Prototypes started in Loom. A PM could record the UI they wanted to change, walk through Figma designs with a talk track, or simply brainstorm. Loom could then automatically create work items from the recording. When the PM moved a work item to in progress, a coding agent started automatically. That agent wrote code in the actual front-end repository using a managed agent in the cloud, so PMs did not have to deal with local environments. The resulting code was already compliant, accessible, and in the Atlassian design language. If the team wanted to implement a prototype, handoff to developers was much faster. Yehoshua called having the right prototyping environment key, and "a big unlock."
Triaging internal feedback. Because everyone at Atlassian uses Jira, changes generate a lot of feedback. Feedback and bugs arriving in Slack were triaged by the Jira agent in Slack and automatically sent to the coding agent for fixes, which Yehoshua said saved engineering a lot of time.
Customer insights. The team ran many user studies and used Jira Service Management to review all the videos, gathering more than 900 pieces of feedback. A Rovo agent then triaged and categorized them. Yehoshua said the team was "very happily surprised" by the triage quality, and it told them what to send to engineering.
Here the PM was clearly steering: unblocking engineers, processing internal and external feedback more effectively, and building prototypes set up for reuse. PMs did not check in code to production.
What PMs do now, and what they've stopped doing
Across the examples, Yehoshua listed new PM activities: prototyping and testing, writing evals, going deeper on customer feedback, and consuming information at a much higher rate. All of this, they said, depends on AI tools understanding the organization's context, which at Atlassian is built on the teamwork graph.
What PMs have stopped doing includes manual updates, compiling research by hand, and creating slides from scratch. Yehoshua said they would love to claim there are no synchronous meetings, but that would be an exaggeration. They believe there are fewer.
The AI Fluency Index
Startup leaders often tell Yehoshua to hire AI-native people. Atlassian already has many excellent PMs, so the goal is to help them become AI-native.
To do that, the company introduced an AI Fluency Index covering six capabilities. Examples Yehoshua gave were:
- understanding how to use the tools
- writing evals
- automating data insights
- prototyping
- having the necessary technical literacy
Each capability is rated from 1 to 5: 1 is "curious," 3 is "capable," and 5 is "pioneering." Yehoshua emphasized that this is not a career ladder but a development tool, a north star for skills that keep changing. The ladder is about outcomes for customers. Atlassian does not expect every PM to reach 5 on everything. It does expect everyone to reach level 3 on all capabilities over time, and to reach 5 in whatever matters most for their team.
AI Builder Weeks
Of the training approaches Atlassian tried, Yehoshua said the one that stuck most was AI Builder Week. Once a quarter, PMs and designers set aside regular work for a week. It opens with external speakers (they thanked Claire, who spoke at the latest one). More advanced internal PMs then teach specific skills to others. Finally, participants do a project applying what they learned, either with their own teams or with others.
Yehoshua called it very successful: more than a thousand people have participated, and more than 120 new workflows built during the weeks are still in use. Each week focuses on one topic. So far these have been prototyping, evals, building agents, and most recently checking in code. After discussing it with customers, Atlassian published an "AI Builder Week in a box" on its website, with the agendas it has used.
Measuring outcomes: still unsolved
Customers often ask how Atlassian measures outcomes. Yehoshua said plainly that the company hasn't figured it out, and that they doubt anyone has. They compared it to the old problem of measuring developer velocity.
Atlassian currently measures PRs deployed to production rather than PRs written. It also measures features delivered, from idea to customers' hands and usage, though they said pinning down when a feature started is tricky. It tracks whether OKRs are met and overall throughput. Yehoshua noted that throughput is often easier to measure for one team than for an organization, so both need attention. Teams run experiments each quarter and the company looks at what outcomes it can measure. They asked the audience to share ideas.
Closing
Yehoshua returned to their main point: each role is expanding. PMs can do more to get their jobs done effectively and deliver more to customers. They called this the best time to be a PM, described themself as an optimist, and said they expect everyone in the room will still be doing this work ten years from now.
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. And so many of you I recognize and know, 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. 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, there's a new era of the AI builder. If you listen to 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. 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 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: everyone can do so much more than 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? 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, how do you stay on top of it all? And the answer is you don't. 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 Atlassian we built what we call the Teamwork Graph, so that you can see the 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 said, "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 Rovo 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 Atlassian, we think about it as a ship that is going. So you have a ship 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 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. One is a new feature in an existing codebase. Another is a zero-to-one 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 all of this is true with whatever products your company uses.
So we're going to start with Confluence. Confluence recently launched two features called Remix with Rovo 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. Obviously these are 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 when 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, the 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 evals. I assume, I hope, most of you understand that evals is a significant part of your job now, and that you're training yourselves or taking classes on how to do evals. Different teams, sometimes the PMs do evals, sometimes the engineers do evals. Well, in this instance, the evals for something like Confluence Slides were 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 evals. The PMs in turn started using the LLM platform, we use Arize 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. The engineers went from creating a test in a half day to 10 minutes. Just huge throughput improvements.
So in this example, 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." 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 beta customers, and internally, just fixed 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 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 RovoClaw. Now Rovo is our product. Not to be confused, this was not a feature on Rovo. This was a zero-to-one project written from the ground up. Now it started with a PM, Josh, and a designer, Kevin. They vibe coded the whole thing. From soup to nuts, they 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 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 one day he's 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 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 build an agent to do it. So Josh used 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 focused 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. It started on Data Center and then moved to the cloud. It supports isolated cloud. It supports FedRAMP. It supports customizations. And we have hundreds of thousands of customers that you can't mess up. So in this instance, a PM checking in code can be kind of dangerous. So we didn't want to do that.
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 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 22 user-facing features in about 10 weeks.
How did they do it? What were the changes they made? So let's start with prototyping. Again, everybody here is prototyping, I'm 100% sure. But what did they do to make the prototyping more effective? So first, they started with Loom. In a Loom video, you could record the UI that you wanted to change, or you could record the Figma designs with a talk track, or you could just brainstorm, and 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 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. 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 to getting it faster into the engineers' hands. So this was a big unlock.
Next was triaging feedback. As you can imagine, 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 used a Rovo 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 and 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. And all of 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 slides from scratch. I would love to say that there are no synchronous meetings, but that would be an exaggeration. 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 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. 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 PMs? So we want them to become AI fluent. 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 depending on what it is, they can work with their teams, they can work with other people, 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. 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 evals. Third one was how do you build agents? And then 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.
We are measuring PRs deployed, not PRs written but PRs 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 are being met and like overall throughput.
Sometimes it's easier to measure the throughput of an individual team versus an organization. So you want to do both. You want to 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 you guys are all so lucky to be here today. So that's it. Thank you.
Article published · Updated