Atlassian CPO Tamar Yehoshua：AI 如何拓展产品团队的角色，以及何时亲自上手、何时掌舵

Brief Description

Atlassian CPO Tamar Yehoshua explains how AI is changing product management inside a company with more than 10,000 employees. Rather than making product, design, and engineering roles disappear, AI lets people cross traditional boundaries and take on more work. Through examples from Confluence, a new zero-to-one project, and Jira, she shows how PMs decide whether to contribute directly or steer the team, how Atlassian is building AI fluency, and why the right measure is customer and business outcomes rather than activity alone.

Table of Contents

• Product roles are expanding
• Give teams speed through intelligence and context
• Confluence: PMs contribute directly to delivery
• A zero-to-one project: shift from rowing to steering
• Jira: accelerate a mature product safely
• Build AI fluency and measure outcomes

Product roles are expanding

A year or two ago, people in product, design, and engineering worried that AI would make other people’s jobs disappear. That prediction has given way to a more practical reality: the roles increasingly overlap, and a new kind of AI builder is emerging. Some startups hire builders instead of separate PMs or designers. Founders have always worked this way, taking on many responsibilities as they build a company, and now the same pattern is appearing in companies of different sizes.

The question for people in large organizations is how this works beyond a five- or ten-person startup. Yehoshua focuses on Atlassian, where engineering teams use coding agents and refactor code, but her examples center on product managers. Their core job has not changed: find product-market fit, build products customers love, and create a business customers will pay for. What has changed is how they do that work. Everyone can now accomplish more and contribute across traditional boundaries.

AI tools are improving quickly, so nobody can keep up with every new announcement. Yehoshua advises product leaders not to take everything they read on X as evidence. They should find out what actually works for their customers and focus on the value customers can get from AI.

Give teams speed through intelligence and context

Organizational context is another major change. Teams are discussing context graphs and the idea of an enterprise brain because information spread across company tools can now be brought together. Atlassian calls its own representation of that shared organizational context the teamwork graph.

That context can take routine coordination off a PM’s plate. Product managers once spent substantial time taking meeting notes, following up on action items, and telling go-to-market teams when a feature would launch. Tools can now answer many of those questions directly. Yehoshua recounts how Atlassian’s CEO messaged her and a product lead to ask when a feature would launch. Within five minutes, he sent them a screenshot of Rovo answering the question correctly and apologized for taking their time.

Making information available is only part of the change. People need help adopting the tools, so change management matters. PMs are well positioned to guide that transition and accelerate their teams. Yehoshua describes a team as a ship headed toward a destination: the opportunity is to combine model intelligence with organizational context and reach that destination faster.

The PM then has to decide whether to row or steer. Atlassian has experimented with different team structures and measured their output. Its conclusion is that the answer depends on the product and its stage. She illustrates that judgment with three cases: new features in an existing codebase, a product built from zero to one, and improvements to a very large mature codebase.

Confluence: PMs contribute directly to delivery

Confluence launched Remix with Rovo and Confluence Slides. Remix lets a user select text and transform it into different formats. Slides turns a Confluence page into a presentation. Both features rely heavily on AI. The team did not simply ask what to build; it also asked how to build faster and change its working methods, while accounting for the constraints of a large company.

One PM, who had never written code or even used a terminal, partnered with an engineer who built a harness that made it easier for her to contribute frontend code. She submitted 26 pull requests in a month, more than most engineers on the team. She said the product had many UX fixes to make and too few engineers to handle all of them. By taking on work she could do herself, she freed engineers to focus on higher-level tasks and helped the project move faster.

The team also improved its evaluation process. For a feature such as Confluence Slides, getting the evaluations right was important. PMs had traditionally owned this work, so they showed engineers how they wanted the product evaluated. The team then doubled evaluation throughput. PMs also used Atlassian’s Rovo LLM platform to debug prompts and identify issues faster before handing them to engineers.

Another improvement was automating design bug fixes. The team used Figma’s MCP integration to map designs to the actual code and then used a coding agent to make corrections. It could fix about 14 bugs in an hour. Test creation also became much faster: work that had taken engineers half a day could be done in about 10 minutes.

Remix launched in six weeks and Confluence Slides in eight. Those timelines may still sound long to a startup, but enterprise software must meet security and compliance requirements. Work that previously could have taken about six months was completed in six weeks, with much tighter feedback loops among customers, beta users, and internal teams.

In this case, the PM chose to row by contributing code because that was the fastest way to help. The engineering manager provided an isolated repository so the work would not disrupt the larger codebase. The team agreed in advance on contribution boundaries, deliberately blurred roles, and questioned existing processes.

A zero-to-one project: shift from rowing to steering

A different project began from scratch with PM Josh and designer Kevin. They used AI-assisted coding to build a working alpha, then put it in front of internal customers. Once they saw that the idea had promise, they brought engineers onto the project. The PMs and designers continued contributing code alongside the engineers.

As Josh spent more time coding, however, he noticed the engineers beginning to veer off track. He asked himself whether coding was still the highest-leverage use of his time. He stepped back from implementation and returned to setting direction, prioritizing, and unblocking the team. The work moved faster.

His early coding experience still mattered. Because he had built part of the product, he understood the engineering challenges and could steer the team more effectively. He also used AI to eliminate other routine work. Instead of writing weekly reports by hand, he built an agent into the product that generated weekly updates about the product itself. The updates were amusing, and he no longer had to write them.

The PM’s role therefore changed with the project phase. He started by rowing, then shifted to steering when that became the fastest way to make progress. The lesson is to understand enough of the work to recognize blockers, then focus on whichever activity has the greatest leverage at that moment.

Jira: accelerate a mature product safely

Jira has existed for more than 20 years and has a large, complex codebase. It supports data center and cloud deployments, isolated cloud environments, FedRAMP, and extensive customer customizations. Hundreds of thousands of customers depend on it, so allowing PMs to commit directly to production code would carry too much risk.

At the same time, the team wanted to make Jira AI-first and help customers use AI in software development. It explored how to reinvent the software development lifecycle, assign work to agents, and make agent use seamless throughout Jira. From work in progress to shipment, the team achieved roughly three times its usual throughput and shipped 22 customer-facing features in about 10 weeks.

A streamlined prototyping workflow helped. PMs could record a UI change, talk through Figma designs, or capture a brainstorm in Loom. The recording could generate work items; moving an item into progress then triggered a coding agent. The agent worked in the actual frontend repository through a managed cloud environment, so PMs did not need to configure local development environments. The resulting code already followed accessibility, compliance, and Atlassian design requirements. This made prototypes easier to reuse and hand off to engineers.

The team also automated feedback triage. Internal feedback and bugs arriving through Slack were triaged with the Jira agent and routed to a coding agent for fixes, saving engineering time. For customer research, Jira Service Management helped review user-study videos. The team collected more than 900 pieces of feedback and used a Rovo agent to categorize them. The triage quality was better than expected, helping the team identify what engineering should fix.

Here the PM was primarily steering. The PM focused on unblocking engineers by processing internal and external feedback more effectively and creating prototypes that could be reused. PMs did not commit code into the production environment. The appropriate boundary differed from the Confluence case because Jira’s scale and customer risk were different.

Build AI fluency and measure outcomes

Across these examples, PMs are doing more prototyping and testing, writing evaluations, examining customer feedback in greater depth, and consuming information at a higher rate. These workflows work best when AI tools can understand the organization’s context, which at Atlassian is provided by the teamwork graph. PMs are doing less manual updating, hand-compiled research, and slide creation from scratch. There are still synchronous meetings, though Yehoshua believes there are fewer.

Atlassian wants its existing PMs to become AI fluent rather than assuming it can hire only people who are already AI-native. The company introduced an AI fluency index with six capabilities, including using tools, writing, automating data insights, prototyping, and technical literacy. People assess themselves on a scale from one to five, from curious to pioneering, with capable at level three. The index is for development, not promotion: it gives people a direction for building skills as the tools change. Atlassian expects PMs to reach level three across the capabilities over time, while teams can identify the areas where level-five expertise matters most. Career ladders, by contrast, remain focused on customer outcomes and what people produce.

The company’s AI Builder Week is a quarterly training week for PMs and designers, during which they set aside their regular work to learn and build. It combines external speakers, internal peer instruction, and a practical project. More than 1,000 people have participated, and they have created over 120 workflows that continued to be used afterward. Each program focuses on a particular skill: earlier weeks covered prototyping, evaluations, and building agents; the most recent one focused on contributing code. Atlassian has also published an AI Builder Week in a Box with sample agendas and materials.

Measuring the effect of AI remains difficult. Yehoshua says Atlassian has not solved it and does not think anyone has. The company tracks pull requests deployed to production rather than merely written, features delivered from idea to customer use, whether OKRs are met, and overall throughput. It looks at both individual-team performance and organization-wide progress, since one can improve without the other. Teams continue to run experiments each quarter to learn which outcomes can be measured reliably.

The overall change is an expansion of each role. PMs can do more to perform their jobs effectively and deliver more to customers. Yehoshua sees this as an exciting time to be a PM: the work is changing, but the opportunity is to use broader capabilities to build better products and businesses.