Atlassian AI负责人：20+应用接入Chat

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.