Roles Are Expanding, Not Converging: Tamar Yehoshua on PM Work in the AI Era

1. Guest Background

This episode of Lenny's Podcast is hosted by Lenny Rachitsky and centers on Tamar Yehoshua, identified in the indexed guest context as CPO at Atlassian. The title frames the topic directly: roles are not converging, they are expanding. That matters because the conversation is not a generic debate about whether AI will replace product managers. It is an episode analysis built around a specific executive's account of how product work is changing inside a large software company.

The supported background for Tamar in this evidence is her Atlassian role and her discussion of Atlassian's internal product practices. She speaks about the teamwork graph, Rovo, Confluence Remix with Rovo, Confluence Slides, PMs contributing to code, and PMs working on evals. The guest context also positions Atlassian as a company with more than 10,000 people, using products such as Rovo, Confluence, and Jira internally.

That makes her perspective especially useful for teams that cannot simply copy a five-person startup's AI-builder pattern. The episode's strongest material comes from the tension between new AI-enabled individual capacity and large-company constraints: existing codebases, compliance, security, design systems, customer scale, and cross-functional coordination.

2. What the Episode Covers

Tamar opens from a recent anxiety familiar to product organizations: over the past year or two, PMs, designers, and engineers were often pointing at one another's craft and predicting that someone else's job would disappear. Her current observation is different. The practical change she sees is not simple elimination, but overlapping responsibilities and expanded capability. She acknowledges that the AI builder role is real in both startups and large companies, and that founders have always worn many hats. But she asks what that means in a company with more than 10,000 people, where teams do not operate with a blank slate.

Her anchor point is that the PM job itself has not fundamentally changed. PMs still need to define product-market fit, build products people love, and create a business users will pay for. The change is in the operating model. AI tools have improved quickly, and organizational context can now be exposed through systems. At Atlassian, she points to the teamwork graph and Rovo as examples of that shift. Her CEO Mike asked when a feature was launching, then sent a Rovo screenshot minutes later asking whether the answer was right; the team confirmed it was. For Tamar, that illustrates a broader movement from asking a person who knows to asking a system with context.

The rest of the episode is organized through her ship metaphor: is the PM rowing, or steering? Atlassian ran experiments, organized teams in different ways, and landed on an unsatisfying but important answer: it depends on the product and the phase. She then walks through three cases, each showing a different PM posture and where organizational context changes information access. Confluence Remix with Rovo and Confluence Slides show a PM directly rowing through code, evals, and quality loops. The zero-to-one rovoclaw project shows a PM starting by coding and later stepping back to steer. Jira shows a mature, high-stakes product where PMs do not change production code, but still accelerate engineering through prototyping pipelines, feedback triage, and customer-insight processing.

3. Core Views: Reasoning, Examples, and Limits

Tamar's most important view is that AI does not simply collapse product, design, and engineering into one universal role. It expands what each role can do and creates more overlap at the edges. That distinction matters. If the only question is whether PMs should become engineers, the discussion becomes a status argument. Tamar's examples point to a more practical question: at this moment in this product, what is the highest-leverage contribution a PM can make to customer value and team throughput?

Her argument rests on a stable definition of PM work. The PM is still responsible for product-market fit, products people love, and a business people will pay for. AI changes the means, not the mission. The Confluence case makes this concrete. For Remix with Rovo and Confluence Slides, the team did not only ask what to build; it asked how to build much faster and change the way it worked. PM Iya had not written code and had not used a terminal before. With an engineering partner's front-end harness, she checked in 26 PRs in a month to fix UX issues and keep engineers focused on higher-level work. In Tamar's ship metaphor, this was rowing: the PM personally moved the product forward because the available work was clear, bounded, and valuable.

But the example also carries its own limitation. Iya was not simply dropped into a production system with encouragement and a coding agent. The engineering manager provided a clean, isolated path so the larger repository would not be disrupted, and the team defined an intentional contribution model. That is why this case should not be reduced to “PMs should write code.” A better reading is that PM coding can work when the contribution surface is designed, the risk is contained, and the team agrees on what kind of work belongs to whom.

Tamar also expands PM work beyond coding. In Confluence Slides, PMs worked with engineers on evals and achieved 2x eval throughput. They used Atlassian's Arise LLM platform to debug prompt issues and send them to engineers faster. The team used Figma MCP to map designs to actual code and automate design bug fixes with a coding agent, reportedly fixing about 14 bugs in an hour, while engineers reduced test creation from half a day to 10 minutes. These examples show that the PM's AI-era leverage is often about connecting quality standards, design intent, prompt behavior, test creation, and engineering flow, rather than personally producing the largest volume of code.

The rovoclaw case adds an important counterweight. PM Josh and designer Kevin initially vibe coded a working alpha that internal customers used before engineers joined. That supports the AI-builder idea for early exploration. But once the project evolved, Josh noticed it was veering off track because he was busy writing code. He stepped back to focus on direction, prioritization, and unblocking, and Tamar says things moved faster. The lesson is not that PMs should avoid coding. It is that coding can create technical empathy and reveal blockers, but the PM must still notice when their highest-leverage job has shifted from rowing to steering.

Jira is the clearest boundary case. Tamar describes Jira as more than 20 years old, with a huge and complicated codebase, Data Center to Cloud history, isolated cloud, FedRAMP, customizations, and hundreds of thousands of customers. In that environment, PM production code changes could be dangerous, so the team did not take that path. Yet PMs still accelerated the AI-first effort. Loom recordings of UI changes, Figma designs, or brainstorms became work items; moving a work item to in progress triggered a cloud managed coding agent that wrote in the real front-end repository. The output was already compliant, accessible, and in Atlassian design language. Internal Slack feedback went through a Jira agent for triage, and more than 900 customer-insight feedback items from user-study videos were categorized with Jira Service Management and a Rovo agent.

The broader view is that organizational context is the enterprise unlock. Model intelligence alone is not enough; it must be joined to company knowledge, workflows, repositories, design language, compliance requirements, and customer feedback. Tamar is also careful about uncertainty. She says not to believe everything on X, that the right PM posture depends on product and phase, and that Atlassian has not fully figured out AI outcome measurement. Deployed PRs, delivered features, idea-to-customer usage, OKRs, and throughput are useful signals in her account, but not a settled universal metric system.

4. Learning and Application

The first practical use of Tamar's argument is to separate the essence of PM work from the way that work gets done. A team should not start with “should PMs code?” It should start with “what would most accelerate validated customer value right now?” In a new AI feature with obvious UX fixes, constrained front-end changes, and too few engineers, a PM contribution path may be high leverage. In a phase where direction is drifting, dependencies are unresolved, or priorities need hard calls, more PM coding may be the wrong answer.

The second application is to design the contribution model before celebrating the tool. The Confluence example worked because the PM had an engineering partner, a front-end harness, an isolated path, and an explicit agreement about contributions. The Jira example shows the other side: in a complex, high-risk product, PMs can stay out of production code and still make prototypes more reusable by connecting Loom, work items, managed coding agents, and real repositories. A mature organization should define which repositories, change types, quality gates, review steps, and environments are appropriate for PM involvement.

The third application is to treat evals and feedback systems as product-management skills. AI products need PMs who can define what good looks like, participate in eval design, notice prompt failures, and convert messy customer signals into engineering-ready input. Tamar's examples include 2x eval throughput, prompt debugging through Arise, automated design bug repair, Slack bug triage, and more than 900 customer-insight feedback items processed through Jira Service Management and a Rovo agent. The common thread is not automation for its own sake; it is faster conversion of context into better product decisions and shippable improvements.

A fourth application is organizational training. Atlassian did not reduce its answer to hiring AI-native people. Tamar says Atlassian already had strong PMs and wanted them to become AI fluent. The AI fluency index gives people a development map across capabilities such as tool use, eval writing, automated data insights, prototyping, and technical literacy, with levels from curious to capable to pioneering. The crucial boundary is that the index is not a promotion ladder. Promotion remains tied to outcomes and customer production. That makes the index useful as a learning map rather than a performative scoring system.

AI Builders Week is the operating version of that map: once a quarter, PMs and designers pause regular work for training, external speakers, internal peer teaching, and project practice. Tamar says more than 1,000 people have gone through it and more than 120 workflows continued afterward. Other organizations can copy the principle without copying the exact format: choose one bottleneck, practice on real work, let advanced practitioners teach peers, and measure whether workflows survive after the training week.

The final application is measurement discipline. Tamar openly says Atlassian has not fully figured out AI outcome measurement. That honesty is useful. Teams should avoid treating generated PRs, agent invocations, or prompt volume as final value. Better indicators combine deployed PRs, delivered features, time from idea to customer use, actual usage, OKR progress, defects, rework, compliance, accessibility, and whether low-leverage manual work is actually decreasing. AI can reduce hand-written weekly updates, manual research synthesis, from-scratch slide creation, and some synchronous meetings. It does not remove the PM's responsibility to decide what matters, where the product is going, and which risks are unacceptable.

Source

• Original episode: Roles aren't converging—they're expanding | Tamar Yehoshua (Atlassian CPO)