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.
Source link AI Strategy: How the Enterprise Added Intelligence Across 20+ Apps, Shipped Chat, and Changed Hiring
Sherif Mansour has spent 17 years at Atlassian, where he leads AI across the product portfolio and oversees the product management craft, including 450 PMs. The company has more than 20 apps: six were built during the generative AI era, while the rest are established products. More than 5 million users regularly use their AI features, according to Mansour.
In his SaaStr AI session, Mansour presented the Atlassian AI strategy as a practical enterprise case study, not independent company research. He addressed how an organization can add Atlassian Intelligence and Atlassian Cloud capabilities without disrupting existing work, data, or content. His guide focused on three decisions: shipping chat, adding AI to established workflows, and redefining teams and hiring. An “AI builder” means someone whose primary job is using AI tools to ship software.
Atlassian tested competing assumptions with real teams and users. This article summarizes that presentation and its plan for turning product lessons into features.
Decision 1: Why Atlassian Almost Left Chat Out of Its Apps
About two years ago, Atlassian debated whether to add Rovo chat to Jira, Confluence, Jira Service Management, and its other apps. Critics argued that chat was not the right interface for every task: completing a structured service request, for example, is often faster through a dedicated form. Supporters saw chat as a way to learn what users wanted from Atlassian Intelligence. It could answer questions, provide search access to knowledge, and understand the context around everyday work.
The practical decision was to ship it. Atlassian already needed a chat backend to support AI features across its portfolio, so it made the capability available across more than 20 apps, including Confluence and Jira Service Management. The goal was to observe real teams, their content and data, and the use cases that emerged. Chat became a product-research tool as well as a service interface.
Mansour compared this approach with DOS and its command line. The command line supported many tasks before dedicated applications appeared, and it still handled the long tail. In the same way, chat can reveal which questions deserve purpose-built features, while giving users a flexible guide to Atlassian’s apps and service management tools.
One Confluence Whiteboard Prompt Became a Feature, a Workflow, or an Agent Tool
Mansour used Confluence whiteboards to show how teams turn prompts into product decisions. By studying user content, Atlassian identified three use cases: a dedicated feature, a repeatable workflow, or a conversational request that should remain in chat.
- Prompt becomes a button. Teams repeatedly asked chat to group sticky notes into themes. Atlassian turned that request into a feature: select cards and group them. This action is faster than asking an agent to repeat the same task.
- Prompt becomes a workflow. Users wanted to turn notes into Jira backlog items, or create new items in Trello or Linear. The early request failed because the necessary tools were missing. The resulting workflow lets users select cards, choose which pages belong in the backlog, and create tickets with the right permissions.
- Prompt stays a prompt. “Pull my customer feedback from Salesforce and Google Drive and put the insights on my whiteboard.” This request combines data, context, and search across systems, so Atlassian is not building a separate page. It starts in chat, places the answers on the canvas, and lets users return to chat.
Atlassian did not initially plan for every feature to support agents. Now group-into-themes and whiteboard-to-backlog are tools Rovo agents can call. Depending on the plan and availability, customers can expose these features through MCP or Atlassian’s CLI, including to Claude Code and Cursor. The same knowledge base, teamwork graph, and Confluence content can support work across Atlassian apps, whether users are inside the service or using Rovo externally.
Atlassian also expected chat to be temporary because customers already had ChatGPT and Claude Code. That assumption was wrong: Mansour says millions use Rovo chat daily. People often choose the AI closest to their work, while admins still need control over access, permissions, and data. The lesson is practical: use Rovo chat to discover repeated questions, draft new features, and improve the guide before committing to a dedicated interface.
His recommendation is specific: if users return to your product every day, ship chat, then use what they type to decide which features to build and when.
Decision 2: Atlassian Added an Agent Step to Jira Workflows 2.5 Years Ago
Many AI strategy guides recommend rebuilding an existing product from scratch instead of adding AI to it. Atlassian took the opposite approach: it added one agent capability to a mature product and used customer behavior to decide what to build next.
Jira is more than a developer tool. It acts as a workflow engine for many teams, including use cases in enterprise operations and service management. A request about a rideshare complaint or a disputed phone bill can move through a Jira Service Management workflow, while Jira Service supports broader team processes. Confluence provides the surrounding context and knowledge that teams may need.
About 2.5 years ago, Atlassian added one box to its Jira automation designer: use a Rovo agent at this step. The bolt-on let an agent perform an action inside an existing workflow, without replacing the product, its data, or its human approvals. The feature was a learning tool, not a claim that every integration was generally available.
Customers extended the pattern with conditions, branches, and chained agents. For example: a ticket arrives; an agent reviews the request; a marketing agent may call Canva to create new assets; and a social agent can evaluate the result before posting it. The exact tools, access rules, and permissions depend on the product plan and configuration.
Mansour compared the approach with living in an old kitchen before renovating it. Existing users and workflows reveal which problems matter. Teams can evolve a product incrementally, while a from-scratch approach may suit new AI-native apps. The lesson is to preserve the asset you already have, then add features where the evidence supports them.
The Rule Across the Portfolio: Anything You Can Do With a Human, You Can Do With an Agent
About six months ago, Atlassian formed a principle from its AI work: agents need the same tools, context, goals, accountability, and visibility as people. That applies across Jira Service, Jira Service Management, Confluence, and other apps. In enterprise service management, access and permissions still determine what an agent can see or change; the principle means equivalent product patterns, not unlimited authority.
Atlassian’s practical guide is to review each feature and workflow:
- You can @mention a human; you can @mention an agent.
- You can add a human to a workflow step; you can add an agent.
- You can assign work to a human; you can assign it to an agent, with permissions and auditability.
- You can chat with a human in Slack or Microsoft Teams; Rovo agents can participate where available.
The teamwork graph, Atlassian Teamwork principles, and shared knowledge help connect people, content, data, and goals. Teams should ask whether an agent needs a different pattern or simply the same page, service, and management controls. As a plan for every organization, preserve accountability while extending human-centered features across the work.
Decision 3: 10 AI-Builder Teams Moved Fast, Then Stalled
Sherif defines an AI builder as someone whose primary job is using AI tools to ship code. Atlassian tested whether product managers, designers, and engineers would effectively become one role. With 450 PMs and about 800 designers, the organization had enough scale to test that assumption across its product teams.
The company launched about 10 software projects with selected AI builders: engineers, plus PMs and designers who could code with AI, working across new and existing codebases. The teams initially moved quickly, using Atlassian Intelligence and Atlassian Cloud tools to create new features and accelerate routine work.
After several weeks to a few months, however, progress slowed sharply. Mansour described the problem as “everyone was rowing and no one was steering.” The teams lacked clear decisions about priorities, customer needs, and what to build next. PMs and designers eventually returned to their core responsibilities because customer context, product judgment, and prioritization were more valuable than having them produce more code.
The staffing ratios made the bottleneck clearer. Atlassian typically has about one PM and designer for every 10 engineers on product teams and about one to 20 on platform teams. AI increased engineering throughput, making the effective ratio feel closer to one to 30 or 40. Engineers finished tasks sooner and needed decisions sooner; a PM focused on coding could not provide the necessary direction, data, or customer insights.
Atlassian is adding an AI-builder role, but the experiment does not show that every PM or designer should fill it. A practical guide for an enterprise is to preserve product leadership, research, permissions, and management ownership while using agents and AI tools to expand the team’s work. Small startups may make everyone a builder; larger organizations need a deliberate plan.
The Hiring Pipeline Flipped: More Juniors, More Seniors, Fewer in the Middle
Many executives argue that companies should hire fewer juniors and replace them with one senior using AI. Atlassian took the opposite approach: its pipeline now emphasizes junior and senior talent, with fewer mid-level hires. The aim is a balanced team, not an age-based rule.
Mansour says experienced employees may need to unlearn 10, 20, or 30 years of habits, while new graduates have less to unlearn. Atlassian’s internal research found that juniors were up to 38% more likely to use AI and nearly twice as likely to experiment. The company did not provide the study’s sample, measurement period, or full data, so these figures need context.
Senior employees adopted more slowly but were better at identifying poor output and improving results. Juniors explored tools and use cases; seniors contributed judgment, quality control, and knowledge. Together, they could use Atlassian Intelligence and Atlassian Cloud to create features, organize content, draft pages, and improve a Confluence knowledge base.
AI Builder Week brings the groups together for four days. Juniors share tools and answers to frequently asked questions; seniors address quality, permissions, access, and service management. Teams can then turn asked questions into a practical plan, while the teamwork graph connects people, work, and data across the organization.
The guide is to build a 10x team rather than a 10x individual: combine experimentation with management judgment, and verify the research before changing an enterprise hiring plan.
About the Author
