Roles aren't converging—they're expanding | Tamar Yehoshua (Atlassian CPO)
Atlassian's Tamar Yehoshua explains what the AI builder era looks like for product managers in a company of more than 10,000 people. Using Confluence, RovoClaw, and Jira as examples, she covers when PMs should write code and prototypes, when they should steer the team instead, and how Atlassian is building AI fluency in its PM organization.
The AI builder era inside a large company
Tamar Yehoshua opens by recalling the anxiety of a year or two ago, when every discipline seemed to be telling the others that its job was about to disappear. What she sees now is different: roles are overlapping, and a real “AI builder” role is emerging. Startups are hiring builders instead of PMs or designers, and founders have always worn many hats, so this is less a new idea than a newly accessible one. Her point is that the picture changes at a company with more than 10,000 people, where the podcast version of the builder life can feel out of reach. She sets out to describe what it looks like at Atlassian, deliberately leaving engineering aside to focus on the PM.
What stays the same and what changes
The core PM job has not changed: find product-market fit, build products people love, and make sure the business is one customers will pay for. What has changed is how the work gets done, and she names two shifts.
The first is capability. AI tools improve at a rapid pace, and nobody can keep up with all of it. Her advice is to stop trying to track every claim on X and to focus on what actually works for your customers.
The second is context. Enterprise-wide “context graphs” and an “enterprise brain” are no longer aspirational. Atlassian’s teamwork graph lets Rovo, its AI product, see the full context of the organization. She describes the CEO, Mike, sending a screenshot of Rovo’s answer about a feature launch and then apologizing for wasting her time, to illustrate that access alone is not enough. People still need help, and change management is part of the work.
The PM used to be the person taking meeting notes, chasing action items, and telling go-to-market teams when things would launch. Tools now handle much of that. PMs, she argues, have a front-row seat to how the work is changing and can focus on acceleration.
Rowing or steering
She uses a ship metaphor: the team is a ship moving toward a destination, and the question is how to get there faster. Her formula is intelligence plus context, meaning model capability combined with organizational knowledge. The live question for each PM is whether they should be rowing (contributing directly to the work) or steering (setting direction and removing blockers). After running many experiments with different team structures and measuring outputs, Atlassian’s answer is “it depends,” on the type of product and the phase it is in. She illustrates this with three examples: a new feature in an existing codebase, a zero-to-one product, and enhancements to a very large existing codebase.
Example one: Confluence, rowing in an existing codebase
The Confluence team shipped two AI features, Remix with Rovo, which turns highlighted text into multiple formats, and Confluence Slides, which converts a page into slides. The team did not start by asking how to build the features as specified. They asked how to build them much faster and how to change the way they work.
The PM had never written code or used a terminal. With an engineering partner who built a harness for her, she began checking in front-end code. She merged 26 PRs in a month, more than most engineers on the team. Her reasoning was that the UX had many issues, the team lacked engineers to fix them all, and she wanted engineers focused on higher-level work. She could do this herself, so she did.
PMs also took on evals, which Tamar considers critical for something like Slides. Working with engineers to define how the product should be evaluated doubled eval throughput. PMs used Arize, Atlassian’s LLM platform, to debug prompt issues and pass precise findings to engineers faster. They also used the Figma MCP to map designs to code and automate design-bug fixes with a coding agent, fixing about 14 bugs an hour. Test creation dropped from half a day to about ten minutes.
Remix launched in six weeks and Confluence Slides in eight. She acknowledges that a startup may find that slow, but this is enterprise software that must be compliant and secure, and that work usually takes the longest. Before AI, she estimates the same effort would have taken about six months. The gains came from much tighter iteration loops with beta customers and internally. Two enablers stood out: an isolated, clean repository so the larger codebase stayed safe, and an intentional contribution model in which roles were deliberately blurred and existing processes were questioned.
Example two: RovoClaw, rowing and then steering
RovoClaw was a zero-to-one project, not a feature of Rovo. It began with PM Josh and designer Kevin vibe coding the entire thing, from start to a working alpha that internal customers were using. Once they saw promise, engineers joined. The PMs and designers kept checking in code, but Josh noticed the engineers drifting off track because he was busy coding himself. He asked whether writing code was the highest-leverage use of his time and decided to step back to direction setting, prioritization, and unblocking.
His early hands-on work was not wasted. It gave him a real understanding of the blockers and challenges, which made him a better steering partner. He also automated a chore: rather than write weekly updates by hand, he built an agent inside the product to report on its own progress, which Tamar describes as “super amusing.” The lesson is that the same PM can row in one phase and steer in another, depending on what the project needs.
Example three: Jira, steering in a massive codebase
Jira has existed for over twenty years. Its codebase spans data center and cloud deployments, isolated cloud, and FedRAMP, and it serves hundreds of thousands of customers who cannot be disrupted. Under those conditions, a PM checking code into the codebase is risky, so the team did not do that. The goal was to make Jira AI first, building AI features that help customers do software development and rethinking the software development lifecycle, including how to assign work to agents.
The team’s throughput was about three times normal, and it shipped 22 user-facing features in roughly ten weeks. The changes centered on prototyping, feedback, and steering.
For prototyping, the team began with Loom. A recording of the UI to change, Figma designs with a talk track, or a brainstorm could be turned into work items automatically. Moving an item to in progress triggered a coding agent working in the front-end repository, running in a managed cloud environment so PMs did not have to manage local setups. The output was already compliant, accessible, and in the Atlassian design language, so handoff to developers became much smoother.
For feedback, bugs and suggestions arriving through Slack were triaged by the Jira agent in Slack and sent to a coding agent for fixes. For customer insight, the team used Jira Service Management to review videos from user studies, collecting over 900 pieces of feedback. A Rovo agent triaged and categorized it, and the quality of the triage surprised them. The engineering team then knew what to fix.
In this case the PM was clearly steering. The job was to unblock engineers, process feedback, and build reusable prototypes. PMs did not check code into production.
What PMs now do and no longer do
PMs at Atlassian now prototype and test, write evals, go deeper into customer feedback, and absorb information at a much higher rate. All of this depends on AI tools that understand the organization’s context. What they no longer do is manual status updates, research compilation by hand, or building slides from scratch. Tamar says she would love to claim there are no synchronous meetings, which would be an exaggeration, but there are fewer of them.
Building AI fluency
Atlassian’s approach to upskilling starts from the premise that its existing PMs are strong and should become AI native, rather than being replaced by AI-native hires. To guide this, it created the AI fluency index, which covers six capabilities: how to use the tools, how to write effectively with them, how to automate data insights, how to prototype, and the technical literacy needed. Each is rated from one (curious) to five (pioneering), with three meaning capable. Not every PM needs a five in everything. The index is explicitly a development guide, not a career ladder. The ladder measures outcomes delivered to customers, while the index tells people which skills to build. Over time, the expectation is an L3 across the board, with teams focusing on L5 where they need it most.
The training that has stuck best is the AI builder week, held once a quarter. For a week, PMs and designers step away from regular work. The program brings in external speakers, has advanced internal PMs teach their peers, and ends with a hands-on project applying the new skills. Themes have included prototyping, evals, building agents, and checking in code. The results so far include more than 1,000 participants and over 120 new workflows adopted afterward. Atlassian has also packaged the approach as an “AI builder week in a box” on its website.
Measuring outcomes honestly
Tamar is candid that Atlassian has not solved outcome measurement. She calls it the familiar problem of measuring developer velocity. The company tracks PRs deployed to production rather than PRs written, features delivered, and the time from idea to customer usage, which is tricky because a feature’s start is hard to pin down. It also looks at OKRs and at throughput for both individual teams and the organization, since teams can be easier to measure than the whole company. Teams run different experiments each quarter to see what can be measured.
Closing thoughts
Her conclusion is that every role is expanding, and that PMs can do more to get their jobs done well and more to deliver for customers. She calls this the best time in the world to be a PM, says she is an optimist, and expects the people in the room to still be here ten years from now.