Sherif Mansour has been at Atlassian for 17 years. He runs AI across the product portfolio and owns the product management craft, which means 450 PMs. Atlassian has more than 20 apps. Six were built in the gen AI era and the rest are years old. More than 5 million users now use those apps regularly for the AI capabilities.
His SaaStr AI session was built around a problem every founder with an existing product has right now. For every confident claim about how to build AI into B2B software, there’s an equally confident claim saying the opposite. Go headless, because chat is the only interface you need. Chat is a terrible UX, so build real features. Never bolt AI on, rebuild from scratch. Everyone on the team should be an AI builder.
Atlassian tested all of these at scale, with real teams and real users. Here are the three decisions they had to make and what happened with each.
Decision 1: Atlassian Almost Didn’t Put Chat in Its Apps
Two years ago, adding Rovo chat to Jira, Confluence and the other apps was controversial internally. The case against: chat isn’t the end state, and for plenty of tasks it’s the worst possible interface. Try filling out a form through chat. The case for: nobody knew what users would try to do with AI, so give them an open box and watch.
What settled it was mundane. Atlassian had to build a chat backend anyway to power AI features across the portfolio. Once it existed, they shipped it to all 20+ apps to see what they’d learn.
Sherif’s analogy is DOS. The command line was the universal interface to the operating system. You could do spreadsheets, word processing and games in it. Over time the common use cases became dedicated apps with real UIs. The command line never went away, and it still covers the long tail. Chat plays that role for AI: it handles unlimited use cases, and it shows you which ones deserve a real interface.
One Whiteboard Prompt Turned Into a Feature, a Workflow, and an Agent Tool
He walked through Confluence whiteboards as the example. Three patterns came out of reading what users typed.
- Prompt becomes a button. Users kept asking chat to group their sticky notes into themes. Chat couldn’t do it. Atlassian built it as a feature: select cards, group into themes.
- Prompt becomes a workflow. After brainstorming, users wrote long prompts asking to turn sticky notes into Jira backlog items (or Trello, or Linear). It failed because the tools weren’t there. Now you select cards, choose which ones go to the backlog, and the tickets get created.
- Prompt stays a prompt. “Pull my customer feedback out of Salesforce and Google Drive and put the insights on my whiteboard.” Atlassian isn’t building a UI for that. It starts in chat, lands on the canvas, and the user can go back to chat.
One thing they didn’t plan for: every one of those features built for humans also had to be exposed as a tool for agents. Group-into-themes is now a skill Rovo agents can call. So is whiteboard-to-backlog. Customers can expose those skills through MCP or Atlassian’s CLI to whatever else they run, Claude Code and Cursor included. Atlassian’s features get used whether the user is inside an Atlassian app or not.
The assumption going in was that chat was temporary. Learn from it, build the features, then remove it, since customers already had ChatGPT and Claude Code. That was wrong. Millions of users use Rovo chat every day. When Sherif calls customers, they tell him they also use Gemini and Claude Code and everything else. People use the AI closest to where they’re working. He built the deck for this session in Google Slides and used Gemini for the layouts for the same reason.
His recommendation is specific: if your product has users in it every day, ship chat. Atlassian used what people typed to decide what to build and when.
Decision 2: Atlassian Bolted One Agent Step Onto Jira Workflows 2.5 Years Ago
The standard advice is to never bolt AI onto an existing product and to reimagine everything from scratch. Atlassian did the thing you’re told not to do.
Some context on Jira first. New PMs at Atlassian arrive thinking Jira is for developers. Most Jira users aren’t software engineers. It’s a workflow engine for every kind of team. Sherif’s examples: complain about a ride in a rideshare app and the complaint moves through a Jira workflow. Dispute a phone bill with a big telco, same thing.
So 2.5 years ago, Atlassian took the existing Jira automation designer and added one new box: use a Rovo agent at this step. It was a literal bolt-on to an existing workflow, shipped because they didn’t know where the market was going and wanted to learn fast.
Customers took it much further than expected. They added branching and conditions and chained agents together. One pattern he described: a ticket comes in, an agent picks it up, a marketing agent calls Canva to generate assets, and a social agent reads the assets and posts them. Those customers already had human-run workflows in Jira, and they automated the ones they had.
Sherif’s kitchen analogy: his family bought a house and lived with the old kitchen before renovating. Living in it told them which problems were worth solving. They changed pieces over time and eventually gutted it. If you have users and workflows, that’s the asset, and you evolve it. From-scratch is for new products, and Atlassian has done that too with its six AI-native apps.
The Rule Across the Portfolio: Anything You Can Do With a Human, You Can Do With an Agent
About six months ago the team landed on a principle that came out of the bolt-on work. Every problem they had to solve for agents was one they’d already solved for humans. Humans need tools, context, goals and accountability, and visibility into what teammates are doing. Agents need the same four things. Once everyone is firing off agents, planning across humans and agents becomes a bigger problem too.
The scale differs but the primitives are nearly identical. So Atlassian went through the portfolio item by item:
- You can @mention a human. Now you can @mention an agent.
- You can add a human to a step in a Jira workflow. Same for an agent.
- You can assign a Jira ticket to a human. Same for an agent.
- You can chat with a human in Slack or Microsoft Teams. Rovo agents are there too.
The design review rule that came out of it: when a team shows something an agent does that a human couldn’t or wouldn’t do in the product, ask why it’s different. Sometimes there’s a good reason. Nine times out of ten, per Sherif, the agent should follow the pattern already built for humans.
Decision 3: 10 “AI Builder” Teams Moved Fast for a Few Weeks, Then Stalled
Sherif defines an AI builder as someone whose primary job is shipping code with AI tools. The popular conclusion is that PM, design and engineering collapse into that one role. With 450 PMs and roughly 800 designers, Atlassian needed to know if that was true.
They started about 10 software projects staffed with hand-picked AI builders: engineers, plus PMs and designers who could code with AI, across new and existing codebases.
The first weeks were great and the teams moved very fast. Then, after a few weeks to a few months, they slowed down badly. Sherif’s description: everyone was rowing and no one was steering. Nobody was making the key calls on what to build, so teams spun in circles. The PMs and designers drifted back to their old jobs on their own, because supplying customer context and making decisions was the most useful thing they could do to unblock the team.
The ratios explain it. Atlassian runs roughly 1 PM and designer per 10 engineers on product teams and about 1 to 20 on platform teams. With engineers shipping far more with AI, PMs and designers say it feels like 1 to 30 or 1 to 40. Engineers come back sooner asking what’s next and whether this is the right thing. A PM who spends the day vibe coding isn’t there to answer.
Atlassian is adding an AI builder role, but it won’t be most PMs or designers. In a small startup, everyone can be a builder. In a mid-size or large org, Sherif says no.
The Hiring Pipeline Flipped: More Juniors, More Seniors, Fewer in the Middle
He hears the same line from C-level execs all the time: stop hiring juniors and hire one senior with AI. Juniors produce slop, a senior does more work, and juniors take a year or two to pay back.
Atlassian went the other way. The pipeline used to be a few juniors and a lot of mid-level and senior hires. Now it’s weighted to both ends with less in the middle.
The reasoning: Atlassian has thousands of people in R&D who have to unlearn how they’ve worked for 10, 20, 30 years, and unlearning is harder than learning. New grads have nothing to unlearn. Sherif’s 12-year-old went from a visual coding language straight to vibe coding and is building an App Store app on Replit. He skipped syntax entirely and thinks this is what coding is.
Atlassian’s internal research backs it up. Juniors are up to 38% more likely to use AI, nearly twice as likely to experiment, and use more tools. They also produce a lot of slop and don’t report feeling especially productive. Seniors adopted more slowly but are much better at spotting slop and at getting better output from the AI, because they’ve spent years refining work with juniors.
Atlassian put the two groups together on purpose. Every couple of months the whole R&D org runs AI Builder Week: four days, synchronized so everyone is off regular work at the same time. Juniors present new tools and techniques. Seniors present on quality control, slop, and building differentiated AI over generic AI. Atlassian has open-sourced the program, the schedule and the session videos.
Sherif’s summary of the people question: hire AI builders if you can find them, but build for a 10x team over a 10x individual.
Sherif’s Top Mistakes and Wrong Assumptions
- Debating whether to ship chat at all. It was controversial internally two years ago, and it only shipped broadly because the backend had to exist anyway.
- Treating chat as temporary. The plan was to learn from it, build the features, and take it away. Millions of users now use Rovo chat daily.
- Assuming customers with ChatGPT, Gemini and Claude Code wouldn’t use in-app AI. They use all of them, and they pick whichever one is closest to the work.
- Shipping chat before the tools behind it existed. Users wrote long prompts to push whiteboard notes into Jira and got failures.
- Building features for humans only. The need to expose each one as an agent tool and through MCP came later, by accident.
- Taking about two years to see that agents need the same primitives as humans. Agents went into Jira workflows 2.5 years ago. The “anything a human can do, an agent can do” rule is about six months old.
- Believing everyone becomes an AI builder. About 10 teams were staffed on that premise.
- Reading the first few weeks of speed as the result. The same teams stalled within months once no one was making decisions.
- Letting PMs and designers code while the effective ratio went from 1:10 to 1:30 or 1:40. The steering job got bigger at the moment they stopped doing it.
- A hiring mix heavy on mid-level and senior, light on juniors. It’s now flipped.
- Slow early AI adoption among seniors. The people best at catching slop were slower to pick up the tools.
