Our program is going to begin in a few minutes. It's time to find your seat.
Welcome everyone and thank you for joining us today. Our program will begin shortly. Please make your way to your seats.
As a courtesy to our speakers and fellow attendees, please take a moment and silence your devices.
Please welcome the head of AI from Atlassian, Shri Mansour.
Good 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 Shri 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 six apps are AI native. So six apps we've just built during the Gen AI era, and the rest we've had for a while.
Across our apps, that number is now well over five 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 in your SaaS products, hopefully this is useful for you. 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 three 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, 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 two 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 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, two years ago this was incredibly controversial. We were debating, why add chat? Chat's like—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. Like 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 going to 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? Well, we ended up turning it into a feature. So after we learned from chat, we let people select the cards that 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 product 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 maybe changed or implemented new workflows in your product. So, as an example, the whiteboard 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 into a set of tasks. So, they would type these elaborate prompts in chat only to realize 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 can 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 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.
The third learning, we'll just go to the next one, I think. Yep. Is that still going? Yeah. 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 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 exactly that. So over here, a customer might type in, 'Hey, I've got all my customer feedback from Salesforce and Google Drive or what 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's 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 learn 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 three types of patterns we observed here. One is automate the prompt. You got a prompt, just turn it to a feature and make that part of your experience. Two 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 we've built for humans and expose them 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 at 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. You'll productize 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,' and this is actually a chart from our chat usage internally, where millions of users use Rovo 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 and 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 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 like, 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. I mean, 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.
You know, 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, you know, make a nicer looking kitchen. And so we decided, hey, 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 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. You see many people join Atlassian and in our product teams, and one immediate thing is like, ah, Jira is 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 nontechnical teams that expand beyond that. And we don't market Jira as a business process automation tool. I mean, I don't even know what that is, but that's reality what it is.
If you complain about one of your rides on a ride share 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? Well, we said we don't want to bolt on AI to existing workflows. That's a bad pattern. Nope. That's exactly what we did. We found workflows in our product and we literally bolted on. Two and a half years ago, we were 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 durable 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, 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 customers were—
Gabriel, I think we missed one video on that slide for Google Slides request access. Someone here from the Google team, please fix the request access feature. It drives me nuts. Gabriel, I think we'll just skip this slide and go to the next one, mate. Sorry.
You there? Thank you. Appreciate it. All right, let me go back one. Sorry. What I was going to play for you was a video, but thanks to Google permissions, I can't do that.
What I was going to show you was 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 will 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 had.
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 six months ago. It's like as recent as 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 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, in Slack. I want to be able to chat with the Rovo 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 deployed 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? Two, 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 nine times out of ten, you all 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 the 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 going to be AI builders. And that's the future, right? Everyone's going to become an AI builder.
So I own the product management craft and 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 three that typically work, is that these are the three roles you have today. It's probably or today 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, like what's their career path? 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. There 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 code bases. 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 engineers at hand is that people who were 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 like everyone's an AI builder, but we kind of ended up back in that Venn diagram and that's where we are today. Who knows, it might change, but certainly challenged some of the misconceptions that we had on where the roles 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, our ratio is roughly 1 to 10, one PM and 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, they're 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 don't trust them. There's quality issues. Secondly, well, 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 give me a lot. I have to invest a year in them and I don't really get anything out of them until the second or third year.
Well, 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, we have a workforce 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 like 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. 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 have a research team. There's a link there where you can grab the research report. Internally, juniors are 18, 19 to 38% more likely to use AI, and they do use AI more. They're almost two 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 builder week every couple of months where we—four days across the organization where it's synchronized so everyone takes the same time off. You can't have one person ticking 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 slop and how to make sure that we're building differentiated AI and not just generic AI as well.
And so there's a four-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. 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 experiences 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. 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. I am over time for questions. So, I'll just be around the side here if you have any questions. But thank you so much for your time. Appreciate it.
As a courtesy to our speakers and fellow attendees, please take a moment and silence your devices.
Give a warm welcome to Anthropic's Head of Industries, Eleanor Dorfman.
Testing. All right, apparently the background noise made the last mic challenging, so please bear with me with the handheld. Hi everyone, my name is Eleanor Dorfman. I lead the commercial and industries sales team at Anthropic and I've been at Anthropic for a little over a year and a half now.
We've had a commercial product for the last three years, but it wasn't until the Claude 3 family of models when Claude started getting really good at coding that things started to accelerate. And it wasn't until December of 2025 when things really took off. The launch of Opus 4.6 in December was a bit of a sea change for us and we came back from what was in hindsight an incredibly restful winter break to demand going vertical.
We had not hired for it. We had not prepped our processes for it. We had done extensive planning for the year and what we thought the year or at least the first quarter was going to look like. We were not prepared.
Even if we were prepared to hire and onboard and 3x or 4x or 5x the sales team, you simply can't absorb that number of bodies at the pace that we needed to absorb them in order to deliver against the demand and in order to deliver a positive customer experience.
So the question we had to answer early in January of this year, which now feels like a lifetime ago, was how do you build an AI-native sales org from scratch? Because we fundamentally had to turn everything we'd been doing on its head in order to meet the moment that the market had put in front of us.
Our thesis was that we actually had invested in a really incredible stack of existing tools. All of these tools had threaded Claude natively within them. They had—I think we just heard from someone who had put Claude inside of their tools. And if we had a strong stack and a foundation, we could build coherence and a holistic approach to the customer journey in those tools.
And then thread Claude where we didn't have solutions. So build on the stack we already had and lean on Claude for everything around that stack, in between that stack, and making sure Claude was the narrative thread and the connective tissue. So it wasn't just six tools with Claude bolted on. It was a cohesive customer experience built on top of our existing investments with Claude doing things we hadn't even imagined it was capable of before Opus 4.6.
We'd invested in tools and we used them. So we use LeanData for routing. We use Clay for enrichment. Salesforce is our system of record and source of truth. We use Jira for tickets. Intercom's Fin product we use for customer support as well as for sales support. I joke with the Ironclad team that I'm a daily active user. I am in Ironclad every day working on contracts. We have Snowflake. We have BigQuery. We are the heaviest Slack users you can imagine. We use the G Suite. All of the above. And these were all working for us. And we decided to double down on our investment in them.
So we fundamentally made four investments around the four constraints that we couldn't move. We had demand we couldn't staff. We had Claude inside of our existing stack. We have functions around sales. Sales doesn't operate on its own. Sales sits around legal and deal desk and revops and billing and compliance and customer support and customer success. Sales is not alone on an island delivering a great customer journey. Many, many teams needed to meet the moment alongside of sales.
And we had to just aggressively grow AE capacity without killing them, which is also a constraint I probably should have put on this slide. So we couldn't kill our sales team, but we couldn't grow headcount overnight. We have an extensive recruiting process. We weren't going to sacrifice our bar, our culture, or anything like that in order to service the demand. So, we were left with no choice but to build to support it.
There are a lot of orthodoxies that have governed and really defined the last 15 years of enterprise software. I've been in developer tooling and infrastructure for 12 or four—I'm actually not going to do the math—for a very large part of those last 15 years, and this is one that I really stood behind. There's product-led growth and there's sales-led growth and never the two shall meet. Self-service wasn't the enemy. It was just a different team. It wasn't part of what the sales team did and we had to throw that orthodoxy aside at the beginning of this year.
So, I've always thought and I've always operated with my product counterparts that enterprise plans should be gated by a human. Customers want to talk to an AE during this buying journey and we no longer could make that the case. So, we no longer have enterprise plans gated by humans. We've launched enterprise self-service. We launched an MVP in January. We launched it into production I think in February. And it's been a huge success.
We do not think of self-service as a downgrade. We think of it as a part of the buying journey and a way that we can remove friction and make sure that we get the right customer, the right buyer with the right plan at the right time. All of our leads are enriched and evaluated and qualified by Clay and by Claude.
And then there are two funnels. And we're still working on nailing this. So you might hear some people who feel that they ended up in neither funnel, but we're willing to make sure we're really investing to make sure that everyone who wants to talk to Claude can, anyone who wants to talk to a sales member can, and anyone who wants to buy Claude can.
So Claude and Clay do the qualification, they do the enrichment, and then you can go into the self-serve funnel where Fin from Intercom guides you on their journey. We partnered really closely with the Fin team to build, take their flagship support product and make it a viable tool for sales and it's been amazing. Then they get set up with an enterprise plan. It's real ACV. They have terms of service. They can do invoicing. We get them enrolled and provisioned, enrolled in training and kickstart their journey completely self-served using Claude and our tech stack.
If Claude and Clay qualify you for the sales funnel, the lead goes to the BDR team. They're qualified and they're AE routed. So, we're running these two in parallel at any given time. And since we soft-launched in January, hard-launched in February—this part of the HTML is a little slow. It's still—don't—it's like the wheel of fortune—54% of our new enterprise logos have come through the self-serve funnel in 2026. So this has been an incredibly important funnel and a way that we've tried to meet the moment and drive a more effective sales funnel.
The second investment is that we knew that Claude lived inside of the tools that we had already bought and spent the last three years building around our needs. We have six core tools that really define the journey of a lead. We've talked about Clay. I'm a huge Clay fan. Clay for enrichment. LeanData for routing. Salesforce for op creation and opportunity management. Gong for call coaching. We are heavy, heavy Gong users. Ironclad for contract redlines. And Slack for—'close-won' feels like a really small way of describing the role Slack plays. But Slack is for deal coordination. It's for comms. It's for many other things as I'll show you in a few slides. But for the purposes of a lead working its way through our architecture and our plumbing, these are the six tools.
However, I imagine you don't want to just see an architecture slide that talks about the tools we built. And as I said earlier, Claude isn't just the seventh tool we bolted on. Claude is what makes the tools we've already bought talk to one another, work together, and create a seamless customer journey.
So, let's talk a little bit about how that shows up for the AEs and the sales team on a Tuesday morning, a Monday morning, any day when a new lead comes in and the account's created in Salesforce. We're working on getting all of them in, but it's a work in progress. Prioritization is done. Claude and Clay do the account research upfront. They do the prioritization. They update the account record. They pull in any historical context from Slack, from Google Docs, from previous Gong calls. And when the AE is slotted in, they have all of the context they need that helps drive their prioritization and their actions.
Every single customer-facing rep starts the day in Claude. I'll talk about this a little more later, but we've built a series of skills inside of Claude that enable the AEs to be massively more productive. One is the morning brief, which is built on top of all of the connectors that we use to run our business. So on Gmail, on Gong, on Slack, on Google Docs, on calendar, on Salesforce, on Intercom, on Greenhouse, there are so many systems where little pieces of context are incredibly relevant to ensure you're prioritizing your time, you're operating efficiently, and you're delivering a world-class customer experience.
So, with one prompt, this is how every AE starts their day. I have mine sent to me in Slack every morning at 7 a.m. Eastern because I'm based in New York. But it tracks everything. It looks at your calendar. What do you have that day? What emails have you not answered? What Slacks have you not actioned? What centralized initiatives do you still need to deliver? What marketing events are coming up where you need to prioritize inviting customers? That morning brief is deposited in your inbox or Slack or in claude.ai every single day and prioritizes your day. These three actions need to be taken. These emails need to be responded to.
Further along in the deal cycle, we've leveraged Claude inside of our tooling which we use—I think we use Outline for. So where we—and Google Docs where we publish our policies inside of historical precedent and policy as well as context based on Slack discussions, emails and Gong calls.
So when an AE is ready to draft and ship a proposal to a customer, Claude does it. Claude made sure it's within policy. Claude made sure it lines up with the customer expectations. Claude has all of the knowledge of our products, of our models, of our roadmap. Claude knows where we've won in the past and why we've won. Claude knows who the customer is, what they care about, who are the stakeholders that have been involved, what has been the shape of the negotiation.
And with one prompt, instead of an AE opening up a spreadsheet, opening up nine different tabs with all of the deal desk guidance, listening to Gong calls and looking at transcripts to find the history of what had been negotiated, Claude generates the proposal for you, uploads it into Ironclad, and kicks off the process.
I will be honest, we still start every forecast meeting with at minimum a 10-minute discussion on how we should be—
Forecasting. We're doing a lot of forecasting. We're trying to be disciplined. It is a moving target and a work in progress when the ground is shifting under your feet as rapidly as it is in AI and for the labs today. It's definitely something where I'd like to think we're getting a little bit better at this week. Felt like we had a good forecast call yesterday, but we still have a ways to go. What's most important is forecasts are being largely run by Claude and then inspected and reviewed by managers. So, AEs are using skills to make sure their Salesforce is updated, next steps are accurate, account notes and account plans are current. We have a sense we're a consumption business. So we know where spend is. We know what the commit is that we're talking about. We know what historical patterns have shown for that type of customer in that cohort with that set of products. And AEs are submitting their forecasts using Claude. Managers are then reviewing them because all of the reconciliation has happened between Claude and our existing tools and then submitting them. And forecast calls are for discussion. They're not for gotchas. They're action-oriented and they're focused around where does the AE need help, where do the managers need help, where do we need to make sure that the customer needs are on someone's radar. What is hopefully coming soon is forecast accuracy, but we are not quite there yet.
One other way we've been leveraging our existing stack that shows up for the AEs, and this one to me is critically important because when you're absorbing as many new hires as we are and when you're operating in an environment where things change hourly, I'm confident while I'm up here with you, something will have changed in the AI ecosystem that I'll need to internalize. But with product launches, with model launches, with an incredibly dynamic competitive ecosystem, with many different flavors of customer needs, preserving a culture of coaching is incredibly important. And so we have tried to really make this part of our culture for the AEs and for frontline managers where every week Claude surfaces six coaching moments. And this isn't a static set of coaching based on a methodology. This is dynamic based on how the needs of our business evolve month over month. What was a priority last month is not necessarily the top priority this month, is not necessarily the top priority next week. And the most important thing we can do, the scarcest resource we have is mindshare, and ensuring that we're hitting the coaching moments with the AEs focused on the most important things as the moment is the way to ensure we maintain a culture of coaching. We maintain focus in the field, which is an incredibly important thing in order for the AEs to meet the demand and to be effective. And we maintain a growth mindset.
Nobody has done this before, and if anyone says they have, they are fooling themselves. We are all learning together, and making that part of our DNA and how we work with our managers, how we work with the sales team, how we work with our customers is so important to showing up authentically and ensuring that every member of our go-to-market team is getting even a little bit better every day. And what I always tell the team is, your job is to wake up every morning and figure out how you can make Claude and Anthropic incrementally better that day with our customers, for our cross-functional partners, or for your deals.
Now, you have to do all this. Closed-won is my favorite dopamine hit. It's reliable. It gets me every time. It never gets old. I never get sick of it. But it's a checklist. And when we're growing as quickly as we are, the governance of closed-won really matters. You need to make sure you have terms of service in place. You have a provisioning path for the customer. They're getting enrolled in onboarding. They're receiving an invoice. We have mapped their orgs correctly. We're a complex business. We're available on first-party services as well as through cloud partners. And sometimes just getting all of the little admin pieces in place can accidentally create a horrible customer experience if you don't get them all right. I have personally spent many late nights inside of our billing system trying to reconcile invoices when customers get locked out. This is a very important part of the cycle. And so we have one skill per step for closed-won so that Claude can work across the cross-functional systems and ensure that everything is in place. We do this for self-service too to get the customer's account closed, provisioned, billing set up, and getting them enrolled in an onboarding training.
Again, sales is not an island. There are so many supporting functions that needed to have the same elasticity we were trying to build in the AE in order to meet the demand. This is Deal Desk. This is legal. This is RevOps. This is customer support. And we had had, I mean we still do, but it was a gnarly system. It was a sea of DMs. You needed to have the institutional knowledge or just simply be co-located on the same floor. A lot of AEs would just walk by RevOps and Deal Desk to try and get quotes approved. A lot of people on the East Coast and definitely in Europe were staying up very late chasing approvals. We were creating a very unhealthy side wall and reps. So what we did is we looked at this and said these functions play dual roles. They are there to support the sales team and enable an excellent customer experience, but they're also there to protect the company and to provide governance to ensure you're doing good deals that are in policy that you can stand behind in the future.
So with the supporting functions and all of the systems that they leverage, which are honestly even many more than I had laid out, but Jira is a critical one for us. We structured this and invested in our tools so that reps stopped going to their systems and rather their systems came to them. So we made Slack the front door. Slack comes in, check it out. Claude does the triaging. So Claude, actually co-work now does a lot of this, and that's changed for us probably in the last week since I made these slides. But co-work can check your emails and can submit the Slack ticket in your behalf, or the seller can submit the Slack ticket. Claude will triage and either resolve the ticket based on precedent and policy, or it will escalate the ticket with all of the requisite customer context, all of the history pulled from email, from Salesforce, from Gong, and will assign it to a human and let the AE know that they're in the queue so that the AE can set expectations for the customer and can follow along so that the quote is resolved, the terms of service is resolved, the vendor onboarding, the security questionnaire, all of the compliance pieces that are required to unblock and get a customer started. So we made Slack the front door for all of the support functions.
And so then the last investment we made, and this is the more fun one, sorry, they told me to be not boring with the mic. The last investment we made was taking the best practices of our best reps and encoding them as skills. So this is how we looked at all of the spaces in between our existing tech stack, all of the activities and the patterns that our best reps were doing. We don't have time or the luxury of having incredibly handheld onboarding and a detailed methodology so that we know when a new rep starts on their seventh day, they'll get their first account. On their second week, they'll take their first call. On their fourth week, they'll be able to start working with customers. On their sixth week, we expect their first deal. We aren't able to model out productive capacity like that anymore. We have to get reps in the door. They go through boot camp. We give them a territory and we give them a sales plugin. And a plugin is a combination of MCP connectors and skills. And we built a sales plugin that documented what our top reps do and turned them into five skills that we encoded in Claude that every rep uses every single day.
The first one is the one I talked about before, but it's so helpful and so simple that it merits a second call out, the morning briefing. I simply do not know how I used to operate without it. I am someone who gets lost taking the subway home. And it's incomprehensible to me that I used to navigate my day or week without Claude telling me every morning what's important. So, this is the one we talked about earlier. The second one is call prep. The morning briefing will give you the bird's eye view of what to prioritize and how to think about your day. But before calls, your best reps used to go on LinkedIn and research stakeholders. They used to go through Slack and Salesforce history to find contacts from previously closed-lost opps. They would spend time thinking about how did they want to position, what was their exit criteria for the call, what are the right discovery questions. Claude is now their co-pilot. We use a backslash as the shortcut to summon a skill, backslash call prep, and the rep gets a briefing. Who's on the call? What do they care about? What is the historical context? What does a great outcome look like for the call? What are some discovery questions they should ask? How should they position? What's the competitive landscape? What has this company been saying publicly about their needs and where Claude could fit in? What partners are they working with? What other tools are they using? A succinct one-pager before every call directly to the AE to ensure even if they're back-to-back-to-back-to-back, they can get on that call and provide a seamless, tailored, and personalized customer experience. Now they still have to read it. Claude does not do that for them yet, but I think ever. This is a way that even with five minutes, an AE can show up on a call and know in their bones and manage the context switching that happens throughout their day.
The third one is my favorite. Many things keep me up at night. One of them is wondering are AEs following up on everything. When they tell a customer they're going to do something, do they do it? The customer follow-up skill solves for exactly this. It will extract action items from your email, from your Gong calls, from your Salesforce notes. If you're working with a customer or a partner on Slack, it will extract the follow-ups for you there. It will draft responses and put them directly in your email provider and send you a summary of everything you need to do. And then a reminder in your morning brief the next day if you didn't actually go in, review, and click send, which you still need to do because humans in the loop are still a critically important part of the sales cycle. So the customer follow-up skill is so you can manage all of the volume and the context switching without missing a beat and go to bed every night knowing you have followed up and responded to your customer. We try to set internally a 24-hour SLA to follow up with customers and deliver on action items.
The next skill is called competitive intel. This is a competitive environment and it is changing hourly, certainly daily, absolutely weekly, and there's a lot going on. AEs spend their days on the phone with customers and they're not able to necessarily keep track of every AI newsletter, every competitive release, every small product update from our team, and it's happening over a ton of surface areas. So with the competitive intel skill, rather than having a battle card that product marketing maintains every quarter, Claude will generate an interactive battle card. It will have a matrix of the customers. It will be tailored to the customer you're working on. It's dynamic. It's up-to-date. You can interact with it. And this enables AEs to always be ready from a competitive perspective and to make sure on every call and in every customer interaction they're positioning Claude in order to win the deal and provide the best customer experience.
The last one is very whimsical. It's my favorite. It's called create an asset. Previously in prior lives, if you wanted to build custom collateral for a deal, you either had to be working on a top five deal or you had to have a friend on the marketing or design team who would prioritize your work. With create an asset inside of Claude, for any deal, any stakeholder at any stage, you can generate a completely custom piece of collateral, and Claude will surprise you. You can tell Claude what you want it to do, but you can also let Claude decide what is the best asset for this moment in this deal with this stakeholder at this moment in time. And Claude will generate a prototype, a one-pager, a landing page, an interactive HTML file, a puppet show, probably not a puppet show, usually one of the ones I just said, but Claude will generate that asset for you. You can generate it while you're on the call. Some of our reps like to take Gong calls when they've had a really good discovery call and drop them into Claude Code so that Claude Code can build a prototype, but they can build a completely tailored asset. It could be a proposal. It could be an ROI calculator. It's designed to assess the deal, assess the stakeholders, and assess what the needs are at that time.
This is the only one that got a follow-up slide because I really do like this one and it's the one where the teams are really using it all the time. The skills also know your brand and it's so, so nice to not have to worry on if you've selected the right color or if your A is in the right position. We are very, very, you know, we're protective of our brand. We care a lot about it. We invest a lot in it. We work really hard and we don't want AEs shipping, I heard AI slop mentioned a lot in the previous session. So we don't want them shipping AI slop to customers. We want it to be tailored. We want it to be on brand. We want it to help them win.
This would not be a tech talk at a conference if I did not end with four ways that you can get started today to make your team a little more, I call it AGI-pilled. How can we be an AI-native sales team? How can we do one thing manually once and then make sure we've trained Claude to do it the next time? How can we have Claude spotting the patterns before we can because Claude is the co-pilot on every deal and context is flowing in between Salesforce and Slack, the AE's brain, and back into Claude, and Claude is just getting better and better at our sales motion and delivering for our customers. So number one, turn on Claude where it's already embedded. It's not even just flipping a switch. It's making sure you're being intentional and not just saying, 'Okay, great, we're using this AI feature in Salesforce.' It's how are we using it and how does it connect to the rest of the customer journey. Thread Claude through the sales cycle you're already running. It's an accelerant and with new capabilities, we've moved from just deterministic workflows to probabilistic ones. It is fun to experiment with Claude and to use Claude as your coach, as your partner, as your co-pilot in the deal and to let it make you better and let it push you outside of what always got you here and think about new ways that you can honestly win and close deals. The sales cycle you're running works. So thread Claude through the sales cycle you're already running and think about it from what is the customer experience, what is the AE experience, and how can I track and accelerate these at every single stage. Getting tickets submitted for deal and legal was a massive accelerant for us. This is not something you'd normally spend time thinking about as a sales leader, but sales leaders are rapidly becoming systems thinkers over deal strategists. And you have to think about the system in its entirety.
Number three, really double down there. Make Slack or Teams the front door of one of your support functions. It is a massive enabler. And four, document what your best reps do and ship it as a skill. I cannot fully explain the cognitive relief that comes from knowing that I can take the best practices of my best reps and make them the baseline for how everyone else operates and have total confidence that I have made that the baseline.
This entire deck was brought to you by Claude Design. I did not actually try to pitch any products, so we'll put that to the side. But it isn't a new stack. And I think that's the thing I really wanted to convey today. It's being intentional about your existing stack. These tools are incredible. We have spent years learning them, building around them, investing in them, designing them to fit our sales motion. But if you have Claude in between and Claude around it to enable the reps, your people, your processes, you can massively increase the adaptability of your team and the capacity and productivity that they can manage. Thank you.
I'm exactly on time, which means we have about 10 minutes for questions. I think there are mics and so I know folks probably have another talk, but if you have questions I can definitely stay on and take a few.
First of all, thank you so much for that talk. It's really insightful to see how one of the most tech-forward companies is using tech to get more forward. I have two quick questions. The first one is, in your presentation you gave a lot of examples of automations as you created. They don't come out of thin air. What kind of resources did you stack in order to be able to build these? And what kind of timeline did it take to actually get these all up and running?
We have a three-person go-to-market productivity team that's just focused on building Claude and building tools in Claude. And then we actually have a Slack channel where the AEs share the skills that they've built themselves. A fun one yesterday, skills are, I built my, I built a, for, every time we change the forecast I have to build a new forecast skill, but it's really, really easy. The hardest work is honestly getting all of the data into Salesforce and the data integrity. The things that were always hard, it turns out are still hard. But we just shipped new levels and ladders yesterday and one of the AEs made a skill that he shared with everyone that internalizes your level and gives you coaching at the end of every week on how you performed against your level. So I would say start with one productivity person whose entire job is to make everyone else better on the sales team and then encourage your actual team members to build and share.
And one quick follow-up question. At the onset of your presentation, you said that you thought enterprise sales were gated by humans. That's more of a behavioral thing that a human has to connect with another human. But most of your presentation was about automations that make humans more effective. It doesn't actually remove that gate. So you had 54% of your sales be automated fully. What were the insights that you found that removed the actual gate of you had to have a human involved in the loop?
Honestly, it was necessity. And the way we're thinking about involving the humans now is the sales cycle is ongoing. The very nature of the sales cycle is changing. It lasts forever in a consumption. We have parallel use cases running at any given time and we're trying to elevate the AEs to actually be the advisers we've always said they are. And so we're setting things up so when customers hit a certain spend or a certain threshold, it'll trigger an AE to reach out and to have a conversation and to sort of change the role that they play. The biggest insight was that AEs were spending 70% of their time on internal processes. And they let us know it. And the biggest thing is I was like, we simply will not be able to do what we need to do if 70% of their time is on internal processes, it's not on helping the customers get started. And then the volume of our support tickets of customers saying that they couldn't buy was skyrocketing, which is like, I got a lot of my, I think my number was posted on a Reddit forum, but I got a lot of texts from people sending angry DMs about how they can't buy. And so we had to, honestly it was a necessity to improve the customer experience.
Hi. Great presentation. So I guess to that point you mentioned about 70% of people's time is focused on internal tasks. What KPIs are you looking at in terms of sales productivity, BDR productivity before and after? I guess where are you with that? Because I think that's a journey.
Yeah, we're trying to use Claude for this too. We have Claude coaching running in the background. Claude sends me a weekly report on how my team performed. So, how much pipeline did they generate? What were the input metrics? Like, we're still figuring it out. I look at the reports every day and then send in feedback about why it's not helpful. And so, we've built our version of a Stillwell rubric that we've encoded into Claude so that Claude can assess how the AEs are doing based on their calls, their emails, and we've tried to make them qualitative and quantitative, but it is a work in progress quite honestly.
So you had a Gmail in that workflow. Are you guys getting access to everyone in the sales team? All the emails they're sending out and you're kind of monitoring all that like you're... Okay. And there was a lot of different tools in there. Are you making requests to all the different tools for the data or are you pulling that in and moving that onto Snowflake or somewhere else? Is there somewhere where all the data is being sourced?
Yes, that is how we've decided to run it. I believe it's a combination of Snowflake and BigQuery. And then there are some things that are only in Salesforce. So there's some aspects, but we've been trying to make this read and write so that we can loosen the guardrails as much as possible while still having the right governance and monitoring. So we've actually been reasonably conservative to make sure that we have the right safeguards in place. But I believe some combination of BigQuery is the main source of truth. All the tools push that all into BigQuery, whatever it is, including Gmail and transcripts and all of that.
Cool. Thank you. Is that shared on a team or is that just individual within Claude?
But we also have the native connectors into Gmail. So, we set up MCP connectors for Gmail, Google Calendar, Google Drive, Slack, and all of the tools that we showed. Every team member has to authenticate into it and set it up themselves. And then we set the role-based access controls at the org level to mandate which team members get access to which tools, especially when you can read and write on the Claude org level. Exactly. At the Claude org level.
Hey, great presentation. I had two questions. One is if you can double-click on the enabling functions around sales like legal, finance, because I lead finance at Sprinto. So I'm curious to know what happened. Did you do anything more than create a queue, the triage plus queue, or was there anything else that was done?
That's as far as we've gone thus far. We're actually working, like we're partnering with Ironclad on how can they build Claude in to meet the needs of our legal team. So we're actually working very closely with our vendors on those functions. I think we're using Vanta for security questionnaires. We just bought another tool for, we love buying software. We just bought another tool for vendor onboarding and we worked very closely with the product teams at those vendors to make sure that they're using Claude in the way that we need to be able to roll it out.
Got it. The other follow-up question I had was you said you enabled these new things that you want the reps to do as skills. Any insights for us in terms of how to think about skills versus projects versus other stuff, right? So what's the best way to do that?
I'm very skill-pilled, so I use skills. I made a skill that writes in my tone. I had Claude analyze all of my emails and Slacks and Claude described me as incredibly action-oriented and then told me I needed to take a breath more. But I wanted it to feel like it was in my tone when I was writing. So, I'll summon that skill when I'm saying clear out my inbox, draft responses, use the Eleanor tone skill. And so, I actually would start with skills. Projects are helpful for collaboration where you need to keep it contained, but skills are how you take Claude and make it a part of your organization.
Hello. Hi. Incredible presentation. Thanks. Could you share some best practice on how you're collecting data to develop the skills that will train the best sales rep? Because we're trying to do something similar to that and what we found out is that information is spread across, you know, in-person meetings, Slack, Gmail, and for very complex deals, it ends up getting very clunky to get everything together and build a skill that would truly help. I mean, we still have meetings to put together proposals.
Like the generate a proposal is helpful. In a prior life, I used to call them deals with an S and deals with a Z. And a deal with a Z is when it's right down the middle. You get out of the way. You process it through the systems. You're thoughtful about it, but you get them through. These are for deals with a Z. When we're doing a deal with an S, there are meetings. There are standups. There are multiple sessions with finance and deal desk to make sure we feel really that there's a ton of governance baked in. So for the complex ones, there really isn't a substitute for working on those. The key is that you create the space to give those the focus that they need because otherwise you're spending your time on all the internal admin for the others. That was the online. We still have the meetings.
Hey, quick question about upcoming future. So we see all these skills are coming together like Claude has desktop option where you can click through the interfaces, take screenshots and create presentations, customize communication. When do you see Claude doing a sales pitch without a human being on the call?
It's a little bit what we're trying to use Intercom for right now at the front door when someone's trying to buy and they want to have a conversation with Claude on what plan is right for them. In terms of Claude doing the pitch, I hope that's never because I still want to be able to do that. But I don't know. We're getting closer with every new model launch. So I think that we're all going to learn that one together.
Yes. So your presentation started with the premise that we have more inbound than we can handle and I feel like that's a great problem to have, but just clicking on the outbound side as well. How are you guys using Claude for outbound demand gen?
Yeah, we're still actually running a lot of outbound experiments because you have to plan for what's coming next and we know that this current moment can change at any week. And so we're using Claude to recommend experiments, to recommend where do we think we should be focusing outbound, to design the campaigns, to build the schedule, to run. We're doing a lot of product qualified accounts, like how do we get better at enriching PQAs, building the rubric for signals of what's a high-signal account to target for outbound and then monitoring experiments.
I had one follow-up to that, right? Like something I deal with on a day-to-day basis, like trying to use this very natively within our sales team is something I call context repetition tax. So having to re-explain yourself across like chats or projects, like who I am, what my product is, how I like my emails written. Our team is solving for this by kind of, and you see this like all over Twitter today, by building a brain for your Claude or having a collection of markdown files that kind of outline like all sorts of rules, your outbound style, things like that. Is that something you guys are doing internally or how are you solving for like what I call the context repetition tax within Claude?
These are the org skills. So we have skills at the org level that apply across everyone in go-to-market that the marketing team adheres to, that the sales team adheres to, that customer success adheres to. So there's a lot of org skills that govern that to maintain consistency in brand and context and tone. And then you have to trust your team to manage the rest of it. But we try and build, again, it's like raising the floor and removing the ceiling for how the team can operate. So we've tried to raise the floor significantly with the org-level skills that we standardize on.
Are you doing a lot in your memory.md files or are you like operating purely on skills?
Well, Claude's memory is what's powering it behind the scenes and then a lot of pitch for managed agents, which has been very helpful in that as well, especially for outbound.
All right. This is also another kind of future thinking where you see this going question.
Those are the questions I'm usually not allowed to answer.
Okay. Well, you talked about using Claude as the connectivity, but you still have lots of tools that it's touching. Do you see you starting to shed some of those tools and have Claude do it? Because why would you take info from one place and move it to the next when it has it already?
Honestly, not yet. And I can't, again, I think it's hubris to pretend that I can predict the future when I have yet to submit a forecast within 40% of accuracy. But not yet. We've just doubled down on Salesforce. We use it really heavily. I have to imagine we're one of the heaviest Slack users that exists for them. And so I don't think anytime soon, honestly, we need the domain-specific expertise. All right, we are right out of time. Thank you all so much. Please find me on LinkedIn. Feel free to send questions. I really appreciate and am grateful for your engagement.
As a courtesy to our speakers and fellow attendees, please take a moment and silence your devices.
Please welcome from Scale Venture Partners, Rory O'Driscoll.
Wow. Okay. So, my first conclusion is that Jason lied to me. He said it'd be a small little group, we'd be able to chat and ask questions. Not quite what I was expecting, but okay. I'll yell a little louder. Sorry if I'm screaming. And my second conclusion is I lied to Jason because I don't know what's on the agenda, but I have no intention of sticking to it. I plan to talk about literally exactly what's on my mind right now as a software investor. So, who am I? My name is Rory O'Driscoll. I've been a software investor for 30-plus years, which means I'm in the sweet spot for this talk because I've been successful enough to keep my job and not so successful that I could retire and buy a football team. So, I'm actually here working with you guys. And look, the number one question that we're getting as investors is, you know, is software dead? Is SaaS dead? And that's the question you should be asking. It's a question we're asking. And, you know, as I say, if you spent the last 30 years making money in software, is software dead? Feels kind of like a personal attack. So, I'm pretty focused on this.
So, what's really going on in AI, right? I mean, look, the obvious stuff at the start. Obviously, winning in AI, this is something we articulated in 2018. Winning AI, you're going to have this whole eat the work story. You won't just replace cloud software, you actually will replace the ultimate world of work, and that's a much bigger marketplace. No points for that in 2026. We got the points in 2018. And then the other thing is you're seeing a lot of the AI adoption being in spaces where there wasn't software before. So parts of the story are very expansive. The existing markets are getting bigger and AI is also coming to new markets like healthcare and legal, which let's be frank were terrible markets for software before this. And I should add in parenthetically that after about 20, 25 minutes I'm going to stop and take questions. That is what I did promise Jason to do because I actually like that part of the journey. So expect if you have questions, I'll try and finish a little early and we'll do some of that. So yeah, this is the good news on AI.
The weird thing about AI is nobody has a clue what it means. And this is my favorite stupid graph. I think this originally came from the Financial Times. And it's basically saying AI could mean anything from the end of scarcity, you know, acute human abundance, no more need for material goods anymore, it'll be amazing, to on the other hand, the actual tech singularity and human extinction are somewhere in between like 2% GDP growth. This, to state the obvious, is not a particularly useful freaking slide. It covers pretty much every eventuality except we're all struck by a meteorite and die. So, it doesn't really narrow the discussion. And obviously, as investors, you want to narrow the discussion. I have my biases. We'll come to it in a second. So, that didn't help. And the funny thing is, despite this complete evidence of no one knowing, a lot of this stuff was very knowable. I mean, you had in 2012, you had ImageNet proof that deep learning worked. You had in 2017 proof that transformers worked. You had in 2020 the famous scaling law paper which effectively said if you put money in in the form of compute, you get better results out. And the more money you put in, the better results you get out. That was a real clue if you were paying attention that smart people are going to spend a lot of money and make these models much better. Obviously in 2022, to make it even easier, you had ChatGPT and a little reminder, you know, sometimes things are unpredictable but amazing. That was not what the team at OpenAI expected, but it exploded and suddenly we're all paying attention. And then to make it even easier in 2024, you have the Situational Awareness paper where Leopold, a trader, says, dudes, these are the stocks you should buy to make a ton of money in the next two years. You almost can't miss because the people I know at OpenAI are going to spend a lot of money and this is the stuff they're going to buy. You can't make it any easier than that. And still we all struggle. And here we are in 2026 and we're spending 600-and-something-odd billion a year in capex. So that's kind of big picture what's going on. And it was knowable.
Right now, anyway you cut it, the AI is in invest mode, which is what you say when you're spending more money than you're taking in. Right. And zoom out a million miles. There's a lot of ways to measure this and some ways are unfair, some ways are not quite right. But the big animal, I'm a big believer in investing in the words of John Maynard Keynes, I'd rather be roughly right than exactly wrong. This is roughly right. We are spending in AI capex just among the hyperscalers $688 billion this year. On the other hand, and that's what it takes to make AI. Think of that as all the money, I'm very simplistic, all the money going in to just make AI happen. And then what's coming out the other side? What's coming out the other side is about $110 billion in actual revenues. Most of it, $89 billion coming estimates on a GAAP basis from the two foundation models and then round up everything else, $20 or $30 billion however you want to cut it. And you know, we could be wrong plus or minus $10 billion, but who the hell cares? The bottom line is we're spending half a trillion dollars more than we're taking in. This is meaningful. This is a meaningful fact and anything you do in terms of investing has to bear that in mind. And that's the power. I mean, that's everyone buying into the scaling laws because that shows that putting money in gets good results out and buying into the ChatGPT moment that shows people want to use this. It's as simple as that. American capitalism is saying if we can make money here, we're in. And it's going to go on for a long ass time, right? If you look here again, simple big animal pictures, right? You look at the sum of OpenAI and Anthropic's revenues estimates. Estimates may vary. You can add in everything else plus or minus. You can see by early 2032, plus or minus, a trillion dollars, real money. The stunning thing is it takes until 2031 or 2032 before the revenue from those two companies surpasses the total capex. And again, I want to acknowledge it's not a perfect measure. Some of that capex, Meta will tell you it's being used for other stuff. Yeah, right. Some of that stuff is useful for Microsoft. Yeah, maybe. But the bottom line is most of that capex is going to support the AI buildout. And the AI buildout is the foundation models to a rounding error. So it's going to take probably five or six years before we're not in quote-unquote invest mode, right? And what that means is you just got to acknowledge this fact. When things are in invest mode, when you're spending more money than you're taking in, at any point you could have a hiccup. It would not surprise me, even if the long-term story is amazing, that sometime between now and then, someone wakes up and goes, 'Oh my god, what are we doing? We're spending half a trillion dollars. We're only making 200 million bucks. Maybe we should slow down.' Right? So, I look at this and I go, you know, I think the journey makes sense. Who the hell knows how it shapes out? And then underneath a number I just look at is, is there enough money for these guys to make a trillion dollars? Well, yes, there is. There's a lot of money out there, it turns out. But you have to take an appreciable slug of the total knowledge worker wage bill. I mean, we're talking about an appreciable slug of the largest pile of money out there, right? If you just looked at US knowledge workers, if you said all this money was spent in the US, you'd probably be talking about something like 15, 17% of all knowledge worker dollars, right? And that probably means, to make it real, for software developers, you're probably talking well north of 25%. In other words, for every $200,000 software developer, they're spending $50,000 on tokens. And you all know where you are right now. That's an appreciable shift. So the point here is to make these kind of numbers, a lot has to happen. And these foundation models have to eat a significant portion of what currently is knowledge worker dollars. So possible, maybe even likely, it won't happen without bumps.
So given that that's the framework, the next question is where do you invest? And again, as you'll see, I like simple pictures. This is on the, whatever it is, your left. Had to think for a second there. That silly little kind of pile of blue rectangles that's incredibly ugly because these are just internal slides. That's actually the kind of model that actually Jensen talked about in all his recent talks on how he thinks about the stack. So, I'm going to go with the guy who's made $5 trillion as an approach. And you know, you've got energy, chips, infra, models, apps, right? And as a software investor, my mental model is the bottom three categories are all about making AI. It's about the stuff it takes to build $680 billion of capex. And as investors, when you look into that, 80% of it plus or minus is not really venture-backed stuff. Half of it is chips. Now, we're going to have an amazing venture win in Cerebras in the next few weeks here, which is great. But obviously, the vast bulk of the dollars have gone to Nvidia. At the energy level, obviously, it's all the obvious kind of energy providers. And by the way, that's a big rectangular block because it's hard to get energy,
But the dollars are actually relatively small. Chips are the big spend. And then infrastructure, you know, ranging from some stuff that's pretty, you know, low tech, buildings and stuff like that to some parts where you are dealing with things. I mean, I lump, rightly or wrongly, things like labeling companies and, you know, RL training gyms into that category of stuff that the foundation model companies buy to make AI, right? So, there's been some interesting venture bets there. There's a little bit of software there. It's not a whole ton, but there obviously has been a huge spend. I mean, you've gone from 200 billion in capex four years ago to 600 billion in capex, which means someone is pocketing $400 billion a year, mainly Jensen, but there you go, right? There's been plenty for everyone, including the memory vendors. So, that's the making AI bet. It's not the software space, but just to acknowledge that right now it's the biggest space.
And then next level up, you have the models themselves. You know, the foundation models. Obviously, you have the two dominant venture-backed survivors at this point, kind of OpenAI and Anthropic, and then some of the others that fell away. And we'll talk in a few minutes about do you need to be, what are the opportunities in foundation models from here. But that's kind of, they are, you know, the graphic doesn't do them justice because it's someone else's graphic, but the truth is they are the apex predator of this distribution. They are the guys who have taken the value, the delta value, and probably will continue to do so under those forecasts. And then on the right, you have the using AI in other...
This is all the rest of us. This is the question of how software uses AI to deliver value to corporate customers. And as I'll say in a second, the million-dollar question is how that $1 trillion gets spent between the model companies and then the using AI software companies, many of whom are here today trying to figure out what they should be doing. And that's kind of the big picture framing. So think of it: the $600 billion below the line in making AI, and the $110 billion that has to become a trillion dollars above the line to be divided between the foundation model companies and everyone else. And that's kind of the big picture.
And this is kind of some of, I hate the open questions, hot takes, whatever, I don't like, but if I'm really honest, these are the questions. I mean, one of the reasons I had this deck fairly ready is because internally, you know, we do a quarterly review on what's going on. And as one of my partners said, hm, if people are seriously talking about is software dead and we are software investors, we probably should pay a little attention here, people, and come up with our perspective on that on behalf of our LPs. Right? So these are the questions you're wrestling with. Are the foundation model companies going to take it all? Are the old pre-GPT software companies dead? Do you have to become full stack? Is the enterprise ROI there? You know, where are the weakest points? Where are the strongest points? All these are a list of questions that we were running through. And to the extent I don't cover any of these answers, you're obviously more than welcome to ask, right?
And if you step back, this is the biggest question of them all. How does enterprise want to consume $1 trillion worth of AI over the next five or six years? Right? That's the money question, right? Do they want to buy it all direct from Claude and Anthropic? In which case, you should all go home. I should go home. We're going to need a very, very small conference room in five years and it's going to be a pretty sad moment. Or is there an opportunity for a whole bunch of companies to probably buy AI from the foundation models or from the open source vendors, add value on top of that, be closer to a specific set of customers, build value for those customers and deliver an economically differentiated product and build businesses like that. Right? That is the question. Right?
And it's one version of, it's the modern version of is software dead, because when people say is software dead, what they don't mean is software dead because OpenAI and Anthropic are software and they are most definitely not dead. Sometimes they mean is old school, what I call plain vanilla SaaS dead, and we'll come to that in a second. And then sometimes they mean this question, which is how does economic value get allocated between the foundation models and modern software companies, right? In other words, companies founded post-2022. I put Sierra there because they just raised at 15 billion. You know, obviously you could have any, Harvey, Lovable, many of ours, many I'm sure of you in the audience, right? And you know, worth pointing out that no one knows the answer. And most VCs are betting both ways. They're chucking a bunch of money in at a modest 300 or 600 billion pre at Anthropic, and at the same time they're doing a whole bunch of investments that only make sense if, in fact, there is room separate from that. Right?
So you have to come up with a theory of the case here as to what kind of technology, what does it take to survive in that marketplace, and what kind of companies, and what does it, what technically does it mean, what kind of business models does it take. And this is what we've literally, as I said, been wrestling with right now in the last few weeks, just talking about, because obviously we've been investing post-GPT in a bunch of these companies. But when you step back and say, do you have a kind of clear sense in your head of what works and doesn't work, right? And I edited some. They told me to cut out slides. So, we have about six or eight slides. You know, we meet every Friday and talk about kind of markets. And last couple of Fridays, it was, you know, you have this whole harness discussion. What's one way we kind of come at it from? Sometimes we come at it from a tech perspective like this. And then in the next few slides, we come at it from a business model perspective. And you know, I think partly it depends on each individual partner thinks a different way, right?
But this is some of our infra team talking about, you know, what is a harness? Simply put, what is the software stack on top of a raw model that turns it into a dependable software system, right? Because I don't know if you saw that software convergence article. It is true, many software apps are starting to look the same. It's often a chat interface, a bunch of stuff, interaction with a model, and then back it comes, right? But then the harness is the stuff that makes it all happen. And you know, list of things here that you got to do. You got to decide what context the model sees. In other words, what information you put in, allow the actions to take place, you know, select the outputs, log what happened, and then escalate and manage models depending on what you need. And you can squint one way and say some of this is trivial and Claude and OpenAI will have very basic level harnesses that can do all this. And you can squint another way and say in fact each of these things in and of themselves is a separate product within an overall harness that someone building an app like a Sierra might use. And opinions even within our group differ pretty markedly. Right?
I don't love the word harness. I think it's a weenie word. I actually think a better way of thinking it is like we lived for 15 years in the LAMP stack, which was, you know, how you build a SaaS application. This or something like it is going to be how you build every software application in the age of LLM. And just because every SaaS app had the same LAMP stack doesn't mean they were all the same app. Obviously, they weren't. They were vastly different. And I think in the same way, just because many of these apps will be roughly constructed the same way with the same kind of framework, because you're trying to do the same thing from a technological perspective, access and reason on a model and then distill it into something useful for a business user, they will all sound the same, but how they're instantiated, my gut is, will vary very differently. If you're a legal firm, if you're a customer interaction firm, if you're an app, I mean, the odd thing is if you're a software coding app, because even software coding itself is now an app, right? So my belief is that there are, in fact, that even though they all look and sound the same and in terms of that the descriptives are the same, I think there will be very much differences there. It's a subject of discussion.
And I think, you know, I'm wrestling, and this is literally real time, we have another week talking about it, you know, what's your rule of thumb for simply put stuff that Claude and OpenAI can roll over versus stuff where you really have defensibility, and what are your technical moats, and then on the next slide, what are your business moats. And that's really, yeah, the right-in-right-now question, right? And I'll move on to the next slide just to talk, this is an internal slide. You know, you can imagine lots of different, I mean, I don't love it because there's both business and this is actually, it's an internal slide, so it just has our things, which I don't love. I like to kind of relate to a wider group, but there's a lot of different business moats and some technical moats I want to talk about here.
On the business moat side, there's obvious stuff like you can think of businesses that are sufficiently different from what Claude or OpenAI is doing that you can say, 'Yeah, yeah, I get it. They're not going to be worried by these guys. They're not going to be competed away.' And then you can think of other markets where it's much tighter. And if I'd had time, I would have reordered this slide a little bit. But let's take the ones that are easily different. If you're doing kind of a combination of software and sensors, you've got something that's obviously manifestly different. You know, you've got maybe visual sensors, you've got touch sensors, you got something out there that says OpenAI ain't going to start shipping sensors, right? That's just not a thing. It's just not worthwhile. So, a lot of these deeply vertical, real-world-based apps that are a combination of sensors, then reasoning, vision models to allow business outcomes, I think they're eminently defensible. I don't think it's an issue.
Another category is marketplaces. We just invested in Parform, which helps recruiters find the best candidates. And from a business model perspective, if you're creating an incentive for all sides to want to be on your platform and use your product, where you have those kind of effects, then you will find that that's again not something that a single person can take away with a Claude code app. So do you have a situation where everyone on your platform, where there are, you know, the classic network effect is the more users you have on the platform, the more value it is to everyone else. Marketplaces are typically like that, right?
And I'm going to skip FDEs to capture context and I'm going to skip data flywheel because they're the closest to the Claude side. And then network effects and proprietary data. If you have some proprietary, visibly non-public LLM data that you build your business on, and many of our companies have that, you again eminently defensible. You don't have to talk about why because it just, because the model simply can't do what you do. And then obviously the one at the end, full stack businesses. That's where instead of you as a software company selling software to a business to pursue whatever they want to do, you actually become the business yourself. You integrate forward. And Range, as a company of ours, they're actually doing wealth management using LLMs. But you know, I can tell you OpenAI is not going to get into the business of wealth management. They're clearly, by the way, going to get into the business of hiring wealth managers for literally every one of their engineers. But that's a different point, right? This is just something they're not going to do.
The two I skipped are the trickiest ones because they're, I think of as where you're still dealing with core software companies where you don't have something weird that makes you different, but you're making a much more subtle argument, which is, is that, you know, either a data flywheel from usage. This is this whole context graph and getting the TR where you can build up value over time. You start probably with a simple app and then as you learn how your users do it, you develop a very much a specialist and better and differentiated app. Or in the case of this FDE concept, where to make the software work you need people on the ground, and to some extent that could be differentiated, though obviously you're seeing a lot of even the, I mean, you're seeing the foundation model companies in the one sense admit they need to do that by partnering with PE, and on the other hand making it clear that they will do that, right? So this I would say is a work in progress slide. In fact, I see things now and I'm like, didn't want to do it that way, right?
But you get the point. There are purely software architectural things that are the hardest to distinguish, but I think are really there. And then there's a bunch of really obvious business model or physical instantiation things that together to me say there are plenty of software opportunities that aren't just, oh my god, the model companies are going to roll over you. Right now they're starting with a trillion dollars, they'll be just fine, but there's probably going to be room for everyone.
And then the other version of is software dead that you have is what happened to every software company pre-2022, right? Did AI result in mass extinction event? Because this is what our investors ask, because you've got companies that have been, you know, around a long time, or what happened. And this is, you know, a rough take, which is there was some, we did a lot of pre-AI, pre-GPT AI investing, and about 10% of our portfolio was really DOA when ChatGPT comes out because they solved an AI problem that was just so much easier to solve with ChatGPT that just wasn't fixable. You literally go, 'Oh, we made the thing for $30 million and now they make the thing for $5 per million tokens. You're done.' Right? So, you have a casualty rate, right?
And then the remaining 90%, what you see is roughly thirds, roughly thirds, where you kind of go, there's a third of it that's very GenAI insulated. They do something that's sufficiently different, often with data effects, often using different kinds of AI like predictive AI, that you go, this business won't be impacted by this, it's just orthogonal to it, you don't need to talk about it. There's some businesses actually where it's additive because you have this core product today and then you can add other stuff on top of it. I think one of our companies, DroneDeploy, does a really nice drone management and flight coordination product. Now with AI, you can enhance the value of that product by doing, you know, safety reviews, you can do progress reviews. AI on top of your product increases the value and there's no way that AI is going to replace your value. So that feels good.
And then there's about a third where you're absolutely threatened, where you typically what we call plain vanilla SaaS. You automate a workflow and then you either got to move and survive or you're going to be dead, right? You're either going to be the quicker, the dead, as they say in a crisis, right? And there's no doubt that some of that, and you could argue those percentages might vary. We might have been grading ourselves on a bit of a, we might have been squinting a little optimistically on the last category, but that's roughly how I think about it. And you know, that's going to be the dynamic for all of you in terms of your pre-22, you know, you got to figure out where you are in that world of how your companies are being impacted and where you're facing. So that was the other version of is software dead. It's the is a new software dead killed by foundation models and is the old software models dead, and yes, some are, some aren't.
The other question that's obvious is do you need your own model? Right? I mean, if you think back, and this is a list that DD, a guy at Menlo, who's a very smart investor, did a long list of 65 new labs, and we took it and we sorted into buckets because your venture people are simple people. You just want to put stuff in buckets like the other stuff. And there's around 10 or 15 different categories of non-pure foundation model that may be off because one way to compete with the foundation models is to have your own model. And the obvious category is, you know, LLM replacement companies. You got Thinking Machines, Safe Superintelligence, all the people just going directly at next generation. Then it's worth pointing out that voice, video, and image all had foundation model options that weren't kind of pure the LLM. Anthropic, which doesn't do any multimodal stuff at least until recently, OpenAI did but deemphasized it. So for example, ElevenLabs, they have a speech model and they've built a wonderful business on top of that model.
So there are other AI models that aren't as compute and capital intensive as the core foundation model where you get that model rolling and then you can build a business on top. And there's a bunch of other categories here. There's kind of next-gen coding specialist models. There's chem, you know, models modeling chemistry and physical science properties. There's a bunch of different, you know, we think of this in terms of what bets can you take? There's a bunch of different bets you can take on different model types that we've looked at and tried to figure out. Do you need to do that?
You know, going back to the big picture here, you know, if you step back and think, you know, what's going on with this huge change in venture investing, you know, what do you need to do, right? And then I'm going to wrap here and then take questions. I mean, this is us literally trying to figure out. There's no doubt the game has changed. There's no doubt that some bets, I've been in this business 30 years, I find myself thinking again about things I last thought about 30 years ago, like semiconductors, FPGAs. There's that whole trend of these new deep tech products that were, you know, typically not made in San Francisco, were made down in Milpitas and, you know, Santa Clara, right? Those kind of bets. There's a foundation model bets themselves, which are an order of magnitude, actually two orders of magnitude more capital intense than anything venture has done before.
But then I still think there are going to be over the next 10, 15 years, just as Microsoft dominated the client-server and PC age and was the operating system, but there were hundreds of client-server apps companies that achieved successful and great outcomes in the public markets. Just as AWS dominated the cloud compute space and there was a whole bunch of great outcomes in the public markets of SaaS companies on top of that. I think the same thing's going to happen here. There's no doubt that a two-way or a three-way dominance of the foundation model category will be between OpenAI and Anthropic and Gemini with maybe some other players. They will dominate that. They probably will have, you know, oligopolistic profits. But just as the last two times, I'm pretty sure that there will be a whole bunch of software opportunities on top of that. And because of that, I think software isn't dead. It's gotten harder. There's no doubt. And it's tricky, but it isn't dead. And that's why I'm here to find great deals. So with that, I will stop talking. And I would love to get questions because please don't leave me hanging here for 17 minutes and 32 seconds. I love it.
Test, test. Okay. I admire your energy.
I don't know what you're taking, but kudos.
So as a founder of a SaaS business for the last 10 years, developing agentic voice agent, for example.
What do you recommend as approaching an investor? Do we pitch it as a SaaS that is transitioning to an agentic workforce or as a brand new company starting as AI?
Okay, easy. You can't pretend to be a brand new company because you're not. But I would skip the whole, I would skip the SaaS concept. I would, you know, like you would, I mean, you would say, hope, I mean, a couple, you would say you would want the architecture to be agent-first. You would want the new product to be growing quickly. All right. Just in time to give his Jason, you need to grow like crazy. Are you dead speech, right? I...
Good to see you, man. How are you? Haven't seen you since this morning.
Take a selfie while you're answering.
Okay, good deal. I think...
I think more important even...
Got to smile in the selfie.