How Atlassian Ships AI Across 20 Products and 5 Million Users

G'day folks, all the way from Australia. Thank you so much for coming. Really appreciate your time. For those of you who I have not met before, my name is Sharif Mansour. At Atlassian, I run AI across our products, and I also look after the product management craft. A bit of context about what I'm about to share today. Context is super important because these are the learnings that I've had from my time here. I've been at Atlassian 17 years, so thank you so much if you're an Atlassian customer for supporting my family. I appreciate you. And you can probably blame me for most of your complaints about any of our apps. So you can see me afterwards for that as well. As I mentioned, I run AI at Atlassian as well as our product management craft. For a bit of context, we have about 450 product managers across Atlassian. And so what I wanted to share with you today is based on what those teams have learned and what we have learned implementing AI. Across, we have around 20 apps in our portfolio, more than 20 apps. The majority of them we've had for quite a few years, and about 6 apps are AI native. So 6 apps we've just built during the GenAI era, and the rest were, we've had for a while. Across our apps, we have, that number is all now well over 5 million users that are using our apps on a regular basis just for the AI capabilities. And that number continues to grow. So what am I here to share with you guys today? Every single claim that we have read about AI and how to implement AI, I feel like there's been an equivalent claim that is the complete opposite that is also true. And so what I wanted to do is walk you through what we've been wrestling with at Atlassian implementing AI in our SaaS products. So if you're implementing AI in your SaaS products, hopefully this is useful for you.

You're listening to the official SaaStr AI podcast, brought to you by— Hey everybody, starting a business can get expensive fast. Website here, email somewhere else, business phone with another provider. Northwest Registered Agent gives you a complete business identity in one place with free tools, resources, and built-in privacy from day one. Get more at northwestregisteredagent.com/saastrfree. That's northwestregisteredagent.com/saastrfree. S-A-A-S-T-R-F-R-E-E. Hey everyone, if you're listening to The Agents, then you need to be at SaaStr AI Annual. We'll be back next May in 2027, the world's largest B2B and AI event, May 11th and 12th in the San Francisco Bay Area. Look, most conferences and content these days are about what's possible. As you know from The Agents, we're all about what's happening now, the latest and greatest, and that's what we do even more so at SaaStr AI Annual. See the actual work where we bring together 10,000 founders, revenue leaders, and VCs Plus 200 of the very best speakers showing you the playbooks of what's already running in production behind the scenes, deep dive demos, and so much more. Plus over 5,000 scheduled one-on-one meetings so you can actually meet the people doing all this, not just hear from them. If you're a founder, a revenue leader, or you're the one who has to make this all work with agents, this is where you want to be. You already know this from listening to the agents. That's SaaStr AI Annual 2027. Go to saastrannual.com and use our code THEAGENTS for a special discount on your tickets. See you there.

And in particular context here is we're dealing with quite large teams and fairly big applications as well. So I want to walk you through 3 contradictions that we have wrestled with, and we've often found the answer is not this or that, but sometimes it's somewhere in between. So the first one, the claim that, hey, chat is the universal interface for AI and you don't need to build any UI for your product and all your products should be headless. And, or the complete opposite that, hey, you should take the experiences that people are doing in chat and build dedicated SaaS apps for some of those use cases. Where do we wrestle between these 2 worlds? An analogy I love to use with my teams to help Maybe make it easier to work out where we're going is this old command line prompt. So maybe dating myself here in the crowd, MS-DOS or Terminal if you're a Unix user. I see one person nodding who remembers that era. DOS was the universal interface to the operating system. For many years it existed, and we used it for lots of different kinds of apps. You could play little games, you could actually do little calculations and spreadsheets in the terminal. You could do word processing. And over the years, the universal interface turned into a bunch of user experiences, dedicated UIs. We built Windows, and we built spreadsheet apps, and documentation apps, and all that kind of stuff. We built much richer games. Did DOS ever go away? Nope. It's still around today. In fact, it still is the infinite use case of all the things you could do. But we also have dedicated experiences that provide a much better experience. I think this analogy is super helpful as you are all building AI in your products, because in the world of AI, chat is the universal interface. These large language models are conversational, and so chat is the infinite use case of how you can apply AI to your products. But there are probably lots of examples where you want to take some of those chat conversations and turn them into dedicated experiences. So across our 20 apps at Atlassian, on the left side by there, we added chat to each of our apps. It's called Rovo. Rovo is our AI offering, and we added it to Confluence and Jira and the 20 apps. Now, believe it or not, 2 years ago, this was incredibly controversial. We were debating, why add chat? Chat's— it's not the endgame. Let's build the features that people want from chat. Don't add chat. It's like the worst experience for some things. Imagine trying to fill out a form via chat. It's a terrible experience. You shouldn't add chat to your products. You should just focus on building dedicated UIs. On the inverse side of the argument is, wait, there's so many things people could do with this. We don't know what they'll do. So let's give people chat and see what happens. We ended up having to build a chat backend anyway to power all our AI features across all our apps. And when we did that, that went to all our apps. We said, you know what, let's put it in our products and see what we can learn from that. And we did. So what I'm about to walk you through is just one example of one of our 20 apps where we implemented chat and what our product teams learned from that. And I'm gonna pick a visual example. So over here we have Confluence Whiteboards. It's a whiteboarding tool in our portfolio. You can go in and collaborate with your teams or agents and do a whiteboard together. And we added chat to the whiteboard and we learned what people were typing. So an example here, this lady's typing, hey, here are all my sticky notes on my whiteboard. Hey chat, I want you to group all the ideas that I've got into common themes. I've just finished my planning, group it into common themes. That's something we couldn't do in chat, but we learned that people were trying to do it in chat. So what do we do with this? We ended up turning it into a feature. So after we learned from chat, we let people select the cards they want to group into themes and seems obvious, but this was a learning that came from the universal interface. It helped us prioritize and discover what use cases in our products to build as specific capabilities. So a simple example of how putting a universal interface in your chat app, in your SaaS apps, will help you discover what use cases you should prioritize. But it wasn't just simple turning chat prompts into buttons in your UI. There were other use cases as well that may be changed or implemented new workflows in your product. So as an example, the Whiteboards team learned that people were actually trying to then, when they finished brainstorming, they wanted to take all their sticky notes and put it in their Jira backlogs or post it into Trello or Linear or whatever it is they were using. And they wanted to turn it to a set of tasks. So they would type these elaborate prompts in chat only to realize, ugh, it failed because it didn't have the tools to do it many years ago. And so we realized, hey, chat not only can let us build one-off features, But could it help us introduce new workflows in our products? So we learned from a bunch of experiences, and now you can select specific cards that you want. You don't have to type this in an elaborate prompt and just type all the cards you want to do, and then choose which cards you want to add to your Jira backlog. And you can do that. So chat didn't only just help us build one feature, it also helped us build a new workflow of a human doing an AI workflow inside our products. So this is the second biggest learning. So you can select them and then create the tickets and put them in your backlog. So once they're added, they appear there. So the third learning we had is that we thought when we put chat in, maybe chat won't exist for a while. We'll just take it away. Most people will probably use Claude Code, ChatGPT or something, and we, it probably won't exist. We'll just build all the features that we learned from chat and then take it away or something like that. There are many use cases of your products in your SaaS apps where the UI might actually start from a conversation. And so you actually may need to go from conversation to dedicated experience and back to conversation. So the third example I want to give you here is that exactly. So over here, some customer might type in, hey, I've got all my customer feedback from Salesforce and Google Drive, or my sales team are giving me. Can you extract all the insights from that and stick it on my whiteboard? I just want to learn what's happening. So you can do this today in Rovo, and they do that. But that's an example where we're probably not going to build a UI for doing that. That's a great use case where you might start from a conversation, and then it'll just draw it with you in your whiteboard, and you can collaborate with it, and it'll extract all the insights from Salesforce or Google Drive and do that. So the learning here is that, hey, there are even some use cases where you might want to start with chat or go from chat to a dedicated UI. And then even come back to chat. So this debate that we had a while ago on, should we even be doing chat? There are so many chat solutions out there. If your SaaS app out there has any sort of user workflow proximity, so you have users that use it every day, I would highly recommend it. We learned so much about what to prioritize, when to prioritize it. So chat is the universal interface and gives us unlimited use cases. You may not have filled all of them out, but you'll quickly learn what you need to fill out. You can then take some of them and turn those use cases into a human interface. And I gave you 3 types of patterns we observed here. One is automate the prompt. You got a prompt, just turn it into a feature and make that part of your experience. 2 is you may have a prompt to a more AI-specific workflow where you can go highlight my tickets and create my Jira items in my backlog. Or the third idea is you want to design these handoffs between chat, your UI, your dedicated experience, and back to chat, like the Salesforce example I just gave you. So we learned so much from chat. And what we accidentally fell into as we were building these features in each of our apps— and this happened in Jira and Confluence and everything— is that those experiences we're building for humans, we realized we need to build them as skills and tools for agents. And so, the summarize my sticky— group my sticky notes into common themes feature that I showed you earlier. Sounds simple, right? We built that for humans, but then we exposed that as a tool so that agents can use as well. Turn my whiteboard into my backlog. We built it for humans, and then we exposed that as a tool for agents so they can use it as well. So the example here I've got is in chat, you can say, tell me all the tools you have access to, and we're slowly building that toolbox. that AI agents have access to. And the advantage of you doing this in your SaaS apps is that not only are you doing it for your users and your agents on your platform, but the agents on your platform need to work with the rest of the customer's world. So not only could you ask your AI, hey, now can you do these things for me? These are all our skills that we have, and Rovo is our AI. But the reality is the customer can then, via MCP or our CLI tool, take the skills that were built for humans, And expose them to, via MCP, to all the other SaaS apps that they're using. That's great. It's good for us. Customers are still using our apps on and off Atlassian, or their agents, whether they're using Claude Code, Cursor, whatever it is. So those experiences that we built for agents were derived from learning by shipping the universal interface to all our customers. So chat. I would argue if you've got an existing SaaS app out there, accelerates your product discovery. Your product has common use cases, and you'll work out what experiences need to be native in chat and what experiences need to be in your app and how the two fit together. Now, when we keep thinking, oh, okay, our chat usage will go down, this is actually a chart from our chat usage internally. When millions of users use Revvo Chat every day, and that always blows me away because I pick up the phone and I call them, Oh yeah, we also use Gemini, we use Claude Code, and yeah, we've got everything. And so the lesson here is workflow proximity matters. If you have a SaaS app where you have a ton of users, they'll use it. In fact, working on this slide last weekend, I was using some stuff in Atlassian's world and I switched to Google Slides. This is a Google slide deck. Naturally, I just found myself using Gemini to make some of these slide layouts happen. And so I was just using the AI that was in closest proximity to me. And I think that's a good thing. And the last big learning is you'll realize that every feature you build for your humans, you want to expose as a tool or a skill for agents on and off your platform as well. So this big polarized view of, ah, chat's the universal interface, you should just go headless and build everything for agents, or the other extreme of don't ship chat in your products, only build dedicated UIs. I think that the value here is actually having a bit of both, and it's a bit of a circular loop. Which will help your teams accelerate what you build every day. All right, the second big tension that we deal with is, hey, you shouldn't be bolting on AI to your existing products. Bolt on, that already sounds bad. No one wants to admit that they bolted on AI to their products, right? Instead, you should reimagine your whole product from scratch. You should reimagine the complete AI workflows. I was thinking of an analogy for this, and Many years ago, we bought a house and this is the kitchen in the house that we bought in. And we were fortunate enough to buy the house and be able to live in it before we did some renovations. And we wanted to renovate the kitchen. Because we lived in it for a while, we could actually use it for a bit to then work out what are the problems we want to solve other than make a nice looking kitchen. And so we decided what are the things we want to change in the kitchen? How do we make it better? And we could change bits at a time. And then at some point we gutted the whole thing and then redid the whole kitchen. I actually think the same thing applies to anyone out there who's got any sort of SaaS software today. And it takes people a while to, to feel okay with that because the initial inclination is we need to rebuild everything from scratch. Again, if you're an existing SaaS vendor and you've got users and you've got workflows, that's a huge advantage. You should work out how to evolve rather than start from scratch in those experiences. So to give you an analogy here, I want to just give you a bit of history on some of the aha moments many of our product managers who join Atlassian often come into. Many people join Atlassian in our product teams, and one immediate thing is like, oh, Jira's for developers. And Jira isn't really for developers. It's often for planners, which are often not developers. Developers just pick the next task off the list. And the vast majority of our users who use Jira Aren't software engineers. They're actually non-technical teams that expand beyond that. And we don't market Jira as a business process automation tool. I don't even know what that is, but, but that's really what it is. If you complain about one of your rides on a rideshare app, it goes through a Jira workflow. If you call up a big telecommunications company and have an issue with your phone bill, that goes through a Jira workflow. Yes, you could be a software team that goes through a Jira workflow. But one of the aha moments that takes people a while when they join the company is realizing Jira is largely modeling workflows for all sorts of teams. So how does this relate to this learning? We said we don't want to bolt on workflows, AI to existing workflows. That's a bad pattern. No, that's exactly what we did. We found workflows in our product and we literally bolted on 2 and a half years ago. We're one of the first SaaS vendors. to add agents to the platform. And we were not sure where this would go. We wanted to learn as quickly as possible. And so this is a Jira workflow designed in automation here. And we literally added that square there where you can now use a Rovo agent to do something. So the playbook says don't bolt on AI in your workflows. That's exactly what we did. We bolted on AI in our workflows. Arguably, it's probably one of the best things we did because we didn't know where the market was going to head. We didn't understand where this would go. Now, all of you out there are building SaaS apps with existing workflows that you probably have today. And if you are, don't— you don't need to start from scratch. You already have users that use this every day. So work out where you can add AI in those workflows. And when we did that, we found very quickly that people started going crazy with agents in their workflows. They started doing branching and conditions, and so many customers have multiple agents going at a time. When a ticket happens, I want an agent to pick it up, and then I'm going to kick off a marketing agent to talk to Canva and generate the assets. Then I'm going to create a social media agent that'll read the assets and post to social media. And so by bolting AI to our existing workflows, we learned that customers are just automating a whole bunch of workflows that they already have. So your customers already have human-driven workflows, and adding AI to that workflow may actually be the best thing you'd ever do. So much so that we started looking at our whole portfolio and asking ourselves, What do humans do and what do agents do? And is it any different? And honestly, this wasn't an aha moment 6 months ago. It, like, is recent learning. Turns out every problem you need to solve for agents, you had to solve for humans. Humans need access to tools. Agents need access to tools. Humans need context. Agents need context. Humans need goals and accountability. Agents need exactly the same thing. You need to know what other humans are doing in your team. Guess what? Agents need to know what other humans and agents are doing in the team. And when you've got everyone firing off agents that are doing lots of work, planning becomes a bigger problem to solve. So now you'll need to plan between your humans and agents and so forth. And so one of the aha moments we learned, we kind of fell into, was that all the problems we solve for humans on our platform, we need to solve for agents. And it actually wasn't terribly different. Yes, the scale is certainly different, but the fundamental principles and the primitives are almost the same. So we started going through across our portfolio and saying, what do we do with humans and make sure the same thing you can do with agents. So that's now a principle that we apply to all our product portfolio. I can mention humans. Why can't I mention an agent? We can do that now. I can add humans to a specific part of a Jira workflow. I can now add agents to my workflow. I can chat with humans in Microsoft Teams and Slack. I want to be able to chat with the robo agents in Microsoft Teams and Slack and so forth. I can write with agents. I can assign individual Jira tickets to agents. So as a principle, we deploy the principle of anything you can do with a human, you should be able to do with an agent. Now, there are a couple of edge cases, but the vast majority of the time it applies. So if you're building a SaaS app out there, have a think about, one, what are the human workflows that already apply today? 2, are those the same set of problems that you probably will need to solve for agents? My gut And my learning is, yep, they're probably going to be exactly the same. And if it is, make it a principle for your teams to say, start with a default. When you see a design or something that teams built that is not something a human would do or can do, ask yourselves, why is that different? It might be okay, but you often find 9 times out of 10, you want to follow the same patterns of what you've done with humans as you have with agents. All right, so that's the second big tension we're dealing with. Reimagine your workflows versus bolt-on AI to existing workflows. You kind of need to do both. For new products, reimagine your workflows. If you're existing products and you have humans in the loop, yep, work out, bolt-on agents to those workflows and work out how you'll get better and evolve from there. Now, the third big tension I want to share is really about people, because I think we don't talk enough about people and our teams that are building this software in the world of AI. And that is, One, you need to hire this 10x AI builder. And I'll define AI builder for this talk loosely as someone whose primary job is to ship code using a bunch of AI tools to do that. And you see this everywhere. AI builders are like everywhere. You need to hire more AI builders. Your team's gonna be AI builders. And that's, that, that's the future, right? Everyone's gonna become an AI builder. So I own the product management craft and my, my, I have a counterpart in the design who owns design and engineering and so forth. And so the logical conclusion of the product trio or the triad, the 3 that typically work, is that these are the 3 roles you have today. It's probably, or today it's, there's a Venn diagram merging. So now they're merging more. And obviously the next logical conclusion is everyone is an AI builder. So one conclusion you could take, I don't believe this, is that you won't need product managers, designers, whatever in the future. Everyone's an AI builder and that's it. And so we were like, whoa, our crafts are changing. We need to think about my 450 product managers, Charlie's 800 designers. What's their career paths? How are we going to evolve or change and apply this? So we did some things to maximize our learning. We started about 10 projects across Atlassian, software projects, with AI builders that we picked. And these AI builders weren't just engineers. They were product managers or designers who could also code with AI. We selected the top talent from all of them, and we mixed them in new and existing codebases. What we learned? They moved really fast. We felt amazing. It was like, this is incredible. This is working so good. Then after a few weeks or months, they slowed down terribly. We realized everyone was rowing, but no one was steering. And what happened organically, again, with a company with thousands of engineers or a lot of engineers at hand, is that people who are designers and product managers naturally went back to doing their old role. So they went back to The best thing I can do to unblock this team from making a decision is give them the context of a customer, a vision, and all that. And so it's not saying AI builders won't exist. I totally think they exist. And certainly in small teams, you can still have them. It's just the misconception that we had that everyone's going to become an AI builder. Actually, when everyone's rowing, you need to be clear on who's steering and directing and who's playing that role. So the irony is we started with this assumption that Everyone's an AI builder, but we ended up back in that Venn diagram, and that's where we are today. Who knows, it might change, but certainly it challenged some of the misconceptions that we had on where the role's headed. Now we're introducing an AI builder role for sure, but we don't think that's going to be the majority of our product managers and designers. In fact, our engineers, where our ratio is roughly 1 to 10, 1 PM in design to 10 engineers, in product teams, platform teams, it's about 1 to 20. With AI, Most PMs and designers will tell you it feels like it's 1 to 30, 1 to 40, because engineers are churning through a lot more work. So they're coming back to me to like, what are we doing next? Is this the right thing? And so that becomes even more important to ensure that those that are in positions of steering are making sure they're getting the highest leverage. If that person who's supposed to be steering is vibe coding, they're spending no time actually directing the ship. And What we thought was immediate speed gains, and we did get immediate speed gains, crashed very quickly for most of these teams that we deployed because they were spinning in circles and no one was making the decisions on some of the key things we needed to do. The second big misconception that we have around people is, I hear this all the time from C-levels, I don't need to hire juniors anymore. You know what I'm going to do? I'm just going to hire a senior person with AI. You know why? Juniors, there's so much AI slop that comes out of a junior staff. I need, I, I don't trust them. There's quality issues. Secondly, I just can hire a senior who could just do more work than a junior. So I'm getting a better investment there. And the third investment here is I have to invest a lot to get time from AI, from a junior. Juniors don't gimme a lot. I have to invest a year in them and I don't really get anything outta them until the second or third year. This has been a huge misconception that we've debunked. College students are experts at cheating in their universities, in their assignments. And they're actually very AI native. And so one thing, we have a workhorse with thousands of people in R&D who need to unlearn how they've done their job for the last 10, 20, some 30 years. The hardest thing you can do is unlearn how you do something and then learn the new way of doing it. My son, 12 years old, has gone from visual coding language to vibe coding. He's using Replit actually to build his app in the App Store. This is normal for him. Like, he's missed that whole step of learning a crazy amount of syntax. He just thinks this is how you code now. So what have we done? We've actually changed our hiring pipeline from, we used to hire a few juniors, lots in the mid, seniors, to flipped it completely. We're now hiring a lot more on the junior end and more on the senior end and less in the middle. And it's worked wonders for us. What have we learned? We do, we have a research team. There's a link there where you can grab the research report internally. Juniors are 19 to 38% more likely to use AI, and they do use AI more. They're almost 2 times likely to experiment. They use a lot more tools. But here's where the complementary teams come in. They're actually not great at feeling super productive, but they're doing a lot of stuff, and there's a lot of slop. Ironically, the seniors that use AI, we don't have as many seniors that used AI initially, But they were really good at identifying slop, and they're really good at working out how to make the AI give better results because they're used to working with juniors and refining it with them. So we've taken this and actually applied across all of R&D. We run an AI Builders Week every couple of months where we— 4 days across the organization where it's synchronized. So everyone takes the same time off. You can't have one person tinkering with AI. We have the juniors come in. And share all the new tools and techniques. And the seniors come in and talk about quality control and AI swap and how to make sure that we're building differentiated AI and not just generic AI as well. And so there's a 4-day program. We've open sourced the program. There's a link there. You can watch videos from our internal event that we've published externally. We've got a schedule and timetable of what we do for all of that. So this last misconception that I need to hire a 10x AI builder. Don't get me wrong. If you can hire more AI builders, you probably should.

Yeah.

But it's not just only that. You really should be focusing on getting a 10x team, not just a 10x builder. So I hope I've debunked some what looks like binary polar opposite misconceptions. Everything from chat being the universal interface to no, dedicated experience still matter, and it's a bit of both. You should reimagine your workflows from your products and start from scratch versus bolt stuff on. Nope, it's been a bit of both for us too. We have new products with new workflows. And we've bolted on and worked really well. And everyone's an AI builder? Uh, yeah, maybe in a small startup that probably is the case. Certainly not the case for any medium to large organization. I hope this has been incredibly useful for you folks. Thank you so much for your time. I appreciate it.

You're listening to the official SaaStr AI podcast brought to you by— Costs can add up quickly when you start a business, so stop paying for 5 different services. Northwest Registered Agent gives you a complete business identity in one place with free tools and resources to actually launch your business for real. Get more at northwestregisteredagent.com/saastrefree. That's northwestregisteredagent.com/saastrefree.