Atlassian CEO on the SaaS Apocalypse, AI Agents & What Comes Next

Give people a chat box that can do unlimited power, and they’re like, “Tell me a dad joke.” In the technology world, the underutilized capabilities are so big. It’s almost trite now to say the models are far ahead of the value they’re delivering.

The whole history of software from 1960 until 2022 was that you would take a filing cabinet and turn it into a database. The cool thing about everything that’s happening in AI is that the filing cabinet can do work. The idea that I would vibe-code my own workday and then run it is terrifying. However, there is a great gain we’re seeing internally in the extensibility of software using things like vibe coding.

Everyone has been talking about the SaaS apocalypse. Some people call it the catastrophe. Obviously, there’s a lot happening in the public markets, and a lot of people have different perspectives on how significant it is or what it means. I want to hear from both of you how you interpret what’s been going on and, more importantly, what it means or how we should make sense of it. Why is there too much fear about this, or how should we make sense of it?

Look, I think the world is trying to work out how to rate or value software businesses in a highly disruptive stage. Everyone has hot takes about what the future is going to look like, and depending on those takes, you get a version of the future that’s either really good or really bad for all of software, or for certain companies and categories in software. It’s a really interesting thing.

There’s no doubt in my mind that the risk level has gone up. If you think about it from an investor mindset, you’re like, “This used to be a very stable category. Now it’s a more risky category, so I’m going to step away and watch.” As I always say, investors are trying to work out not necessarily the DCF cash-flow model of a company for all profits of history. They’re really trying to work out, “What are other investors going to do?”

They’re actually betting on what other people think that other people think they’re going to do. Right now, that sort of logically makes sense. You have an interesting world where everyone has a version of what the future is likely to look like, and it seems likely to them. It’s pretty disconnected from the reality on the ground. The answer is always, “What if AI can do that in 2 years or 3 years? What does that mean?”

I think it comes from a very static viewpoint—that people won’t adapt and the world won’t change. It’s like one thing is going to change and everything else is going to remain static.

You have this interesting world at the moment where businesses like ours are doing very well. We’ve had 3 great quarters in a row, and everybody says so. Then you’re like, “Wait, but that used to equate to some value,” and it’s our job to prove that’s not the case for our business. We’re not here to defend all of software, obviously, but for our business, we feel very good about the opportunities we have and the data and results we keep showing.

That doesn’t mean that we don’t have to adapt. It’s this weird world where we are changing how we work radically and quickly, as we always have and as we’ve been doing for a number of years. Some part of that assumes that we won’t be able to change. There are strategic vectors, for sure.

The reality is, as I’ve said, not every SaaS company is going to thrive through the next decade. Just like a bunch didn’t make it to the cloud, a bunch didn’t make it from Windows to the internet era, or whichever era you want to say. No one is going to say that 100 out of 100 SaaS companies are going to make it through and be thriving and growing on the other side.

We also have this version that software kind of dies. A lot of it just ends up as a cash-revenue stream. I can speak for us: this is the best thing that’s happened to our business. We’re in a knowledge world. We have tools to play with that knowledge, act on that knowledge, and do all sorts of other things to solve the jobs our customers have always hired us for. This is logically very good, but it’s up to us to execute through that transition, which I think we’re doing really well. Again, we have to prove that to people over time. The patience part is hard for markets.

Alex, how about you? How do you react to what’s been happening, or how do you make sense of what’s going on?

Well, I hope I’m right in the long run, which is that all this stuff is crazy. I tweeted about this a few weeks ago. My cursory glance is that there are 3 different types of SaaS companies, and the public markets couldn’t tell the difference between the 3.

The first is where seats are tied to outcomes. Seats are being used by people who use them. Going back to the filing-cabinet metaphor, if I’m Zendesk, I’m using Zendesk, and they came up with a very clever pricing model.

Maybe I can take a step back before I even answer your question. There’s this great book by Dan Ariely called Predictably Irrational. I used to give it to all my product managers at my company. It’s like, “Study this to figure out how we charge people for stuff.”

It turns out that people like—and the example that he gives is—imagine you’re locked out of your apartment. It’s midnight. You hire a locksmith. He comes 1 minute later, lets you in in 30 seconds, and says it’s $500. You’re like, “$500? What the fuck? You just did 90 seconds of work.” You leave him a 1-star Yelp review, no tip, and protest the charge on your credit card.

Now imagine a parallel universe. The locksmith comes and spends 9 hours trying to let you in, goes back to his office to get more tools, and finally, by 9:30 in the morning, lets you into your apartment. You’re so grateful that he spent 9½ hours helping you get into your apartment that you give him a $200 tip and leave him a 5-star rating on Yelp. This is an example he gives in the book.

It basically means humans are capable and willing to pay for incompetence. A lot of pricing is about fairness. It feels fair that I give that guy more money, even though he’s completely incompetent, than his counterpart who’s super competent, where I’m so pissed that he overcharged me. It doesn’t make any sense, but it feels fair.

If you think about how we got to SaaS—per seat, per month—in many cases, the additional cost of provisioning a seat digitally is close to 0. Not for everything, but for some things. It just feels fair: if you have 500 seats, you pay more money than if you have 1 seat, even though it’s kind of the same thing going on in the background.

The 3 types of SaaS companies I think of are a great oversimplification, but category 1 is that you have seats, and the seats are being used to produce some element of work. Now, uh-oh, you don’t need the seats anymore to produce that element of work.

Zendesk would be patient 1 there. How many seats does a Zendesk customer need today if they’re using Sierra, Decagon, or rolling their own? Potentially 0.

So, Zendesk: we talk about the present value of future cash flows. It’s imperiled because if the per-seat pricing stays the same—if Zendesk says, “We’re just going to charge you per seat per month for the current thing and never make a change to our code or our pricing”—that revenue stream is 100% going to zero. On the other hand, it could triple or quadruple because they might move to outcome-based pricing and ditch the per-seat model.

It still has to be subject to the laws of fairness and predictable irrationality that we talked about. But something like Zendesk could go up or it could go down; the default path, unless it changes, is going to zero.

On the complete other side of that, you might have per-seat pricing because it feels fair, but the seats aren’t tied to an outcome. Workday has this great pricing model where it’s like, “Oh, you’re GE? You have 340,000 employees. I’m going to charge you per employee per month.” Why? I don’t know. It just feels fair. But those employees who work at GE aren’t using Workday to produce an outcome.

So, Workday, I think, is fine. In fact, if anything—and this kind of goes into what you can do with AI tools—when you hire somebody at GE, they need to do a reference check and make sure that you worked at the 3 companies you claimed you worked at. An HR person has to go look at the file that’s in Workday and call those 3 companies. Workday can call those 3 companies. An AI tool can do that, but only if you’re the system of record.

Something like Workday or Intuit—it’s down 45% in the first, you know, it’s February 26th or 27th today. Nobody’s going to get rid of QuickBooks. These are the 2 tent poles: seats are charged per month or per whatever, and they’re tied to some kind of work; and seats just happen to be a clever pricing trick, but they’re not tied to work.

Then there are things in the middle, like Adobe. Maybe you need more seats, maybe you need fewer seats, but it’s not as stark as the Zendesk example or the Workday example.

Against that, you have this undercurrent of, “I’m going to vibe-code everything,” which I think is just preposterous, having been a software developer for a very, very long time. The person I like to cite as my counterexample here is my second-favorite economist, David Ricardo. In 1817—he’s been around for a long time; he lived a long time ago—this is where the theory of comparative advantage comes from.

You could also grow your own food. You could weld your own aluminum. Even those are bad examples because it’s very simple to grow food or weld aluminum. I have a comparative advantage filming podcasts with you. I could do that too, but I can earn more doing this, even though I might be more productive than the plumber. I should still do the podcast.

That’s actually less important than what I like to call all the edge cases that lie beneath. I could theoretically vibe-code myself some Workday, but what happens in Indiana if the person leaves and they’re on maternity leave? There are all these edge cases that you don’t know about unless you’ve encountered them in the wild.

A lot of software is just a set of deterministic rules that have been learned from, in many cases, decades of experience. The rules aren’t exposed; they’re embedded, and you can’t just replicate them. You replicate them through experience.

I think there are, again, 3 types of SaaS in my oversimplistic view of the world. Then there’s this idea that the IP is worthless because everybody’s going to vibe-code their own thing. For certain subcategories—if it’s a very simple task with no edge cases, or maybe you don’t need all the edge cases that have been built in—I think software is going to do great.

The true systems of record—the ones with sticky software that people rely on and all of these embedded edge cases—are going to start adding AI, where AI does the work. Workday will say, “Do you want us to do a background check?” Intuit will say, “Do you want us to go collect on your outstanding accounts receivable?” You don’t have to hire humans to do that; you hire your software to do these tasks.

That is starting to happen. When that does happen, the present value of future cash flows is going to go up a lot. The present cash flows are going to go up a lot. It’s astonishing to me that a lot of public-market investors can’t tell the difference between these different buckets. They’re very excited about AI, but how do you deploy the AI? You have to deploy the AI through software that’s a system of record.

I think it’s a fascinating time for everyone getting to first principles of what a business really does. You have all these views, right? I personally hate the “system of record” thing because it sounds like a system of record is just a database sitting there. It’s very static: I put stuff into it, I pull it out, and that’s it.

That views a business as a set of filing cabinets in a very industrial-era kind of world. That was very different from the preindustrial era of a business. It had a value, and I get why we have the term “system of record,” but it feels a little bit like why we have a floppy-disk icon as the Save button. My kids ask, “What’s that?” I say, “That’s a disk.” They ask, “What is that?” I say, “You’ve never actually physically seen a disk, but you still have this icon. You know what the Save button does.”

The reason I’m questioning this is that, to me, businesses are a set of processes. They’re not a system of record. These are all process-based systems, right? Everything Alex has just said is totally true, but there are processes like reference checking and other things. Your ability to coordinate a set of processes to happen as cheaply, efficiently, and quickly as possible is, in a knowledge business—not an industrial-era business, but a knowledge-era business—your entire business.

I have more than 10,000 people who walk into buildings every day, bring their brains, and walk out and take their brains with them. That’s it. I don’t have any atoms. I don’t have any bits. I don’t stamp any steel. I don’t even have any filing cabinets, I don’t think. I’m all about coordinating sets of processes, which I think most modern businesses probably are.

When you get to how that relates to Alex’s commentary, I think it’s totally true. We have different types of processes within a business. There are what I like to call input-constrained and output-constrained processes.

The customer-service example with Zendesk is input-constrained. Your customers ask a certain number of questions. How quickly you process those is about your efficiency, cost, speed, and quality in running that queue. If you do it 10 times as fast, you don’t get 10 times as many questions. You have so many customers, and there’s a relationship or a ratio: for every customer, they ask 5 questions. How can I make them ask fewer questions or process questions more quickly?

There’s a lot in a business that is an input-constrained kind of process. I always use our legal team as an example. Their job is not to generate legal work; it’s to answer it. How many leases do we have? How many NDAs? How many contracts? It’s a fixed total set. For that work, I’m trying to do it as efficiently as possible, and you have one entire vector for that set of processes.

But then I have output-constrained work. If I think about anything creative—marketing, and I would argue software development and technology—I can theoretically do an unlimited number of tasks. I’m constrained by my creativity, if you like, and by how many things I can think of to do and how much value I can deliver for my customers.

Those are the places where I’ll take the efficiency gain and probably do more output rather than limit input, within the bounds of making my company profitable and all those sorts of things.

The challenge is to look at a business and try to make this analysis from the outside, because all of your input-constrained and output-constrained processes work together to make a business. They all have to liaise in all these interesting ways, and that’s why you see weird pieces of software that are just coordinating, quote-unquote, humans who are running processes.

What you’re saying about Indiana is totally true because some of those processes have outside rules. We call them laws, governance, and compliance. In Indiana, I have to do a certain thing for employees. The processes are both how I want my business to run and how it has to run. The business is really just a collection of all these processes put together.

I’m just saying it’s a totally different view from “we have a system of record and a system of action” or whatever. That’s not how I think most businesses actually run, but it’s often how we think about them.

I totally think that’s a great framing. Despite the fact that I love Intuit, it’s like TurboTax: the tax code is published, right? You can download all of these rules. It’s highly deterministic, and then your files are in your messy Downloads folder. Make those 2 things happen.

In that case, it’s one of these bizarre situations where everything is actually transparent in terms of the processes. I think it’s quite a rare situation where the edge cases are published in one place—or maybe 50 places. There are 50 states in the United States of America.

Each one has its own tax code. There’s the federal tax system; they have a tax code. Go download that stuff and make it work. There probably still are edge cases and processes that you learn, versus the real world, which normally isn’t as neat as that. It’s just that you learn by doing.

And a business has value. There are a lot of businesses where, theoretically, you would say, “All the assets leave every night because they go down the elevator and go home.” That’s more knowledge-economy-type stuff. But these businesses do have value. Does McKinsey have value outside of all the employees that work there? That’s a knowledge-economy business where they produce outcomes, and it’s tied to labor. It’s not a product, but they probably have some top-secret handbook that they use around how they hire people, how they fire people, how they produce outcomes for clients, and so on and so forth.

I haven’t seen it, and that’s actually great, because I can’t replicate it. It’s probably been built over 100 years. What is it that nondigital, nonsoftware products do? What is their product? Their product is the accumulated knowledge from potentially centuries or decades.

I love going to Japan and seeing that a noodle store has been around since 1587. There’s probably something going on there. It’s this accumulated set of culture, knowledge, and know-how, beyond the recipe list for making noodles. Maybe that’s a bad example because making noodles is a little bit easier and probably doesn’t have as many edge cases. I don’t know—maybe there are edge cases. What happens if you run out of flour? What do you do? How did the noodle shop survive the Great Flour Shortage of 1623? They probably did something, and that’s accumulated in this secret book of know-how, as opposed to, “I’m just going to replicate something where all of the rules are published to the public.”

Again, this is where I think it’s so fascinating. It forces us to rethink our businesses, right? Is Intuit filling out the tax code for you, or does Intuit know the tax code as well as anyone else can? What they’re helping you do is take your life data and your understanding—they’re asking you the right questions. Intuit is almost more like McKinsey. It can be considered that way: their process and special ability are in how they ask you the right questions to fill out the tax code, rather than in filling out the tax code itself.

Yeah.

Right. All these businesses are having to look at this: Maybe I have 50 processes internally that I think are my secret sauce and are unique. Maybe only 20 of them are, but now I have to really consider which of those processes are actually unique and which are not, because we haven’t had to think about it in that manner before.

I think it’s also a question of this Goldilocks zone: Is it worth doing yourself or not? If you take this independent variable of, “Should I now Claude Code myself some X?”—if it’s 99% of my cost and my business is going to fail because this evil company is overcharging me for software, it might make sense. If it’s a dollar a year, it probably doesn’t make sense.

Not all systems of record are the same. I think of a system of record as the atomic unit of something for a business. Calendars could be a system of record for time, or an ERP could be a system of record for inventory. You have all these different systems of record.

If I have an office in Miami that I don’t go to very often, and there’s a system of record for conference rooms—Google Calendar—am I willing to change that system of record? Yeah, because it’s my Miami office and I only go once a year. Who cares? Versus something that touches my revenue: It’s not that expensive, so am I really going to grow my own food?

Actually, this is the cool thing about farming, right? If you take that metaphor, it’s a lot cheaper to go to a restaurant if I just want one hamburger versus getting myself a cow, feeding the cow, and waiting. A lot of food is actually cheaper if you consume it in a restaurant because of comparative advantage and economies of scale.

There probably are systems of record that, outside of any of the factors we’re talking about, are more susceptible just because they’re overpriced or they’re not as valuable in terms of what they’re storing and keeping records for. Carta keeps track of cap tables for a lot of companies. How often do you access your cap table? Not very often, but it’s super valuable. You can’t fuck that up, right?

I’d probably rather use Carta for that, and they don’t charge me that much money. Sure, I’ll use Carta. It’s not a daily-use kind of product, so it’s not even that dimension.

I think the vibe-coding thing is so fascinating to me because someone in software thinks, “Oh, people are just going to vibe-code all these replacements to tools.” The idea that I would vibe-code my own Workday and then run it is terrifying. I have some really smart engineers. First, I have other stuff for them to do. Secondly, that has way more downside than upside for me.

However, that’s the sort of replacement theory. There is a great gain we’re seeing internally in the extensibility of software using things like vibe coding. Most of these applications are highly configurable and customizable—in our case, all the way through to true extensibility. You can write pieces of software and apps that run on top of our platform and have all sorts of different capabilities. Lots of customers do, but those customers need to put a technology team on that job.

Their ability to quote-unquote vibe-code extensions, customizations, and very tailored applications to their very specific use case is powerful. For example, I want an app for the Miami team to do conference-room booking, and Miami has some weird HR policy. So that app needs to look at Workday and this and that. It’s used by 20 people.

I probably wouldn’t have been able to afford to put the internal IT team on building that because the bill would have been too big. But now maybe I can build that. It uses Workday’s data and rules around the world underneath, but it just gives me a very custom interface for the person on the front desk in Miami to do something very specific to what they need. That is super powerful, but it’s not a replacement for Workday. Poor Workday. I feel like Aneel is the butt of a lot of these conceptual examples.

That’s really powerful, right? That actually makes Workday stickier in the enterprise and more valuable because you can build all these applications on top, which is the power of AI, vibe coding, and creativity to make it more tailored for what I need.

But we’re going to have to be really careful about these layers of stability, rules, and process versus customization. You could argue that OpenClaw and similar tools are examples of building very personal apps just for yourself. Most of those people aren’t software developers. They’re building apps that work just for them on top of their Gmail or something else, right?

It still uses Gmail as a rail. They still go to Gmail to read and do their email, but they build some specific thing for themselves to solve a problem they have and probably only they have. A couple of them may turn into companies. Most of them are just solving something they needed themselves. That’s it, and that’s great. That’s really powerful.

That’s why I’m curious about—maybe I’d call it my bucket, too—this pricing fairness where the back end is not the front end. If you think of Salesforce, they charge for licenses. I think we have 600 people at our firm. We might have 600 Salesforce licenses. I’ve never logged into Salesforce, but I bet we pay for one for me.

I use the output of it sometimes because it actually is the system of record. Not to overuse that term, but it stores all of our relationships. I’m part of a table in a relational database. I’m user ID number 422 here, and whenever I meet with a company, user ID 422 is matched in this other database. But we really just want to pay for a database.

In a world where the front end is not the back end, that’s the thing. For Workday, I think they’ve come up with a very clever pricing paradigm. “Trick” undersells it. I think it’s a powerful pricing paradigm that feels fair. The more employees you have, the more you pay. Why is that fair? Because GE has more profits than a 10-person company. GE is going to pay more for this thing, but it’s still a drop in the bucket. It’s totally within the Goldilocks zone of pricing.

I don’t think anybody’s going to balk at that. They’re going to add all this AI revenue, but most importantly, their pricing feels fair. Whereas for these things where the front end is somewhat divorced from the back end, I don’t know what the fair format for pricing is.

What will happen to software pricing? Obviously, if nobody’s going to vibe-code their own thing and there’s not going to be any competition, pricing will stay unchanged. But you can imagine a world where people are building things on top to read from the database, because a system of record has a database that represents that. That’s the abstraction layer beneath everything.

Will there be pricing pressure on any of these categories? For me, I think if the front end is not the back end, there’s more susceptibility than if they’re very, very tightly intertwined. QuickBooks is used by small businesses. They don’t have seats; the owner of the business just logs into QuickBooks.

So the front end is kind of the back end, versus Salesforce, where you can imagine nobody gets rid of Salesforce, but maybe they have fewer seats because they need fewer front ends. They still really need the back end desperately. They’re not going to eliminate or do anything with the back end.

It depends. I think fairness and optics in pricing are really, really important: people need to understand what they pay for and feel like what they pay for relates to their usage in some broad way. I would say that a 10,000-person company paying for Workday and a 20,000-person company probably pays twice as much, plus some discount, because they’re buying more and generally have twice as much complexity of stuff. They see that as fair. That’s what you mean by: it seems reasonable that I would pay by employee for my HR system.

I think the question with a lot of these things is: what processes? When we talk about front end and back end, as an example, it’s not a database; it’s a database plus a set of processes. We used to call it business logic when I was growing up. That business logic is not irrelevant, so why does a business have it? Because it runs as a collection of processes, and they want some level of standardization of process, right? So that 2 teams work the same way, so someone can manage them, understand them, and track output.

If I have a bunch of car factories, I want to track the total amount of cars in and out consistently across them. Where the business logic gets baked in is somewhat where the value is, because you may need it. Again, maybe a16z is not a great example of a Salesforce customer, given that it actually has a huge amount of sales going on in traditional terms. The processes you bake into that for your sales teams are totally valuable to you, and you would think that’s a fair way to pay.

The question is, your sales-adjacent teams—the sort of collaborators rather than the core users—how much do they need those processes, and how much do they not need them? I assume Salesforce Sales Cloud has an MCP server. That MCP server doesn’t go to the database; it probably involves your processes and the rules on the way through. So the question is, if someone is sales-adjacent—maybe they’re in marketing or customer success—if they need those processes, governance, controls, and rules, like, “Hey, we only do X for customers in Japan; we do Y for customers in this area,” that sort of stuff, even their MCP server is going to need an account. Whether the customer thinks that’s fair is a different question, right? It’s just the challenge of how that gets priced.

I’ll tell you, because we get this all the time talking about consumption-based pricing, usage-based pricing, and outcome-based pricing: there are a lot of categories where that makes sense. I definitely do not believe that it will be the primary pricing model for all software or all SaaS-based software, because when you talk to customers, they hate it—with the asterisk that it’s not related to the value they consider they put in.

I have usage-based pricing for Splunk. If I send them twice as many logs, I pay more money. I get it. But the logging is up to me, right? I can log more or I can log less. I can yell at teams, like, “Hey, how come you’re logging so much? This is expensive. Are you using these logs?” I can control the amount of data I put in.

It’s the same with storage and S3, canonically. I put in 1 gigabyte, I put in 2 gigabytes. Fine, right? The problem is those are relatively transferable and controllable by me as a customer. A lot of the examples people give of either outcome-based or consumption-based pricing are not in control by me as a customer and not exchangeable.

The AI token world, the AI credit world, is really, really difficult for customers because they’re like, “I don’t really understand what this casino chip you’ve given me is,” right? I can take a gigabyte from AWS and put it in Azure, and I know how much they’re going to charge me because the gigabyte is kind of constant. When I have these AI credits, I don’t know if your credits are the same as yours or the same as yours.

By the way, you keep adding features that chew up my credits because my users use them. I’m like, “Wait, I don’t know what they’re doing with those credits.” It’s not the company choosing to use them; it’s the vendor adding features that make the software better that seem to just happen, right? I can 10x my customer’s credit usage overnight by adding a whole bunch of stuff, like, “Hey, I built these great summaries for you.” And they’re like, “Wait, I didn’t do that.”

So I think when you talk to customers about outcome-based pricing, they want seats, probably because today they understand it, and secondly, they’ve been burned by a lot of this consumption-based pricing, where the bill just goes up massively and they’re like, “Wait, how do I control this?”

Right. It will take some adjustment.

It will certainly be present in a lot of categories. We have a bunch of areas of our business at Atlassian that you would argue have consumption-based pricing, or are literally just consumption-based pricing, but we try to stick to areas where customers do twice as much stuff, they get twice as much value, they pay twice as much money, and it’s in their control. A lot of these other things aren’t in their control.

The last example of outcome-based pricing is that those outcomes are also dynamic. The problem with, say, customer service is that I’ve saved you money: you used to spend $20 on customer service, and with our tool, you’ll only spend $10. That’s a great sales pitch in year 1. In year 2, the customer goes, “But I only spent $10. Now I want to spend $5. Otherwise, you didn’t deliver any value.” And the vendor goes, “Well, if you took me out, you’d be spending $20.” And it’s like, “Wait, but I don’t spend $20; I spend $10.” My ability to save you money each year is difficult from an outcome basis, right? I’m eliminating tasks.

I’ve started 2 payment companies. This is why I know Workday: I envied them, and I would talk to my sales team about Workday because they know from the outside in how much money they make from GE. They’re like, “Okay, GE uses PeopleSoft. They have 330,000 employees. Maybe we charge them $4 a month, but probably $5 per employee per month. This is how much money you make from that account.”

It’s so much easier to scale a sales team if you’re selling a software product or anything, by the way, if you know that company will pay us $3 million versus when we were starting Affirm and signed up 1-800-Flowers. We had no idea how much we were going to make from them. What really made the business work? Casper, the mattress company. It’s like, what? This stupid mattress company? You just don’t know.

You think you get a big account. We got Walmart; it didn’t really work out that well in the beginning. We got Casper, the mattress company. Oh my God, incredible. Workday has predictability in both directions, right? It’s predictability for the spender of the money, which is the customer, but it’s also predictability for the management team, knowing that you should spend your time trying to sign up GE and not sign up a 10-person company, because GE is bigger than the 10-person company.

Whereas it’s crazy in internet land, where Stripe might make more money from a 10-person company than GE. I guess you could get to higher levels of predictability there, but when you have outcome-based pricing or consumption-based pricing or something, consumption-based pricing is not bad per se. But if you don’t know from the outside in how much you can make from an account, it just becomes exponentially harder to scale a sales and marketing team, because as an entrepreneur, you just don’t know.

As an entrepreneur, one thing I want to go back to is how you guys are adapting in this era. Can you share more about the biggest ways in which that’s manifested for you, and how it’s made you change your business?

Look, I think the way that we think about it is: we sell collaboration tools that solve human collaboration problems, right? In lots of different areas—service teams, broad business teams, HR, finance, software teams—lots of different types of teams buy different sets of apps from us, collections and sets of apps. Fundamentally, they’re all collaboration problems that involve a lot of text. So this is really good for us. What those people are doing is probably the important part, right?

The technology world often runs to, “We’re going to reinvent everything, and that’s the way of the future.” That generally is true in the medium- to long-term arc of time. Our challenge is always that we have a lot of customers that work in today’s manner, today’s workflows, and today’s set of apps. They’re very smart. They want to get to tomorrow, but they also have to move a lot of people.

When we’re building AI features—and I can give examples of any of these—we need to understand what that technology is and how it can help us. That’s how we think about it, firstly. Secondly, what fundamental platform componentry do we need to build for whatever that future will be? This stuff is accelerating so fast, right?

That’s how we got to our AI gateway, the Teamwork Graph, and enterprise compliance and controls. You have to separate that out from the features you’re building for customers in a given app. Then you have to build features for customers that they use, right? So where do you put those features? What are those features? A whole bunch of them are in existing workflows to help the customer do that existing workflow faster, better, with higher quality, and more efficiently.

Those tend to be very unexciting from a magic point of view in terms of what sells a 30-second animated GIF on X, but they're incredibly exciting to the customer because they can use them today. Their existing way of working just got better. They're like, “This is amazing.” They rave about that stuff, and in the AI world, I'm like, “But that's pretty simple,” and they're like, “But it actually helps them today in a massive way.”

I tell people internally, though—and you can give an example in service—that's not enough, because you also need to use their existing workflows with new apps, or look at new workflows and be able to handle that as well. We have to do all of these things. If you look at Jira, it's a canonical example. In the Service Collection, in our HR and IT service management products, summarizing a ticket is something we can do way better than we ever could because there are a lot of existing workflows we have in the enterprise.

Maybe 4, 5, or 6 people work on a ticket internally to try to resolve a problem. The fourth person who shows up has a whole lot of attached files, a lot of conversation, and a lot of different things going on. They would normally have taken 30 minutes to read it all and understand what's going on so they can bring their expertise to bear on the problem.

Literally just summarizing that makes the customer way better. It's not as simple as sticking it into an LLM and getting back a summary. You have to be very careful because the context is so powerful for them. But they haven't changed their workflow one iota. It's still Alex saying, “Hey, Erik, can you come help me with this ticket?”

Erik shows up, and Erik has to bootload his brain with all the information. That's an existing workflow where we can use LLMs just to make that customer way better. They love it. They rave about all these types of features, but they're very simple. They're usually not agentic.

Then we can say, “Cool, but in that service workflow, we need to put agents in at various spots.” Most people are taking a workflow and finding a step that trips them up a lot or costs them a lot of time, and asking, “Can we make this step faster?” That's absolutely something for which we have to provide agent frameworks ourselves. We have a pretty great agent framework that uses all the Teamwork Graph and all the context you have. It's pretty simple and very affordable.

Or you bring your own agent framework. Most businesses, I think, will have 3 to 5 large-scale agent platforms running internally, and they'll say, “Hey, I use Agentforce for this, or I use Gemini for this.” Great. Bring that agent, we'll put it in the workflow here, and we'll make that work. We have to be able to do that.

But you're still in the existing-workflow world. You're just doing the old task and then doing a new, more efficient task within the existing workflow. Then you get people asking, “What if the service ticket didn't exist at all?” You're reimagining whole categories of software into new workflows, and we have to help our customers make it across that gap because they don't generally have 1 service team. They have hundreds.

If they have hundreds of different service desks running, they might say, “These 20 are going to work in this new way,” but they have to manage them all. I guess we're trying to bring data in the Teamwork Graph together with this, and also approach it from a customer-driven lens. I think that often gets left out here. We're trying to take them 5 years into the future. It's our job to actually get them 1 year, 2 years, and 5 years into the future simultaneously, which we're trying to do.

The last thing I'd say is that we're investing a lot in design. I think that always gets left out of any conversation because there's a lot of foundational design to do in how this works. We're seeing the first elements of this, but if I look at the mobile era, the first set of apps were basically taking desktop or web things and sticking them in a phone.

Then we evolved new patterns of interaction and experience—not even just the visuals, but how we use these things. What were push notifications for? They didn't exist at the start. Drag to refresh is a very obvious, simple example. That's a canonical design pattern that was successful there and got moved across.

The whole question of how I use my mobile and my desktop together, and how I move back and forth, presents so many design challenges for us to solve. Those challenges actually help people understand what's there. The average customer, the average user, doesn't want to understand. If AI doesn't exist for them, that's fine, but they want the outcomes of it. They don't need to know all of the technical detail. It's our job to hide that and just give them the answer they're looking for, or make a task more effective or efficient.

I feel like in the technology world, sometimes we get so obsessed with model quality. It's almost trite now to say that the models are far ahead of the actual value they're delivering. The underutilized capabilities are so significant. A huge part of that equation is design and experience. How do I give people a chat box that can do unlimited things, and they're like, “Tell me a dad joke”? It's unlimited power, but it's very hard to help them utilize that power, which is where a huge amount of our challenge goes: bringing agents and all their power into workflows and collaborative loops, and having humans and agents work together.

I love the skeuomorphic point. First, it's like you had pieces of paper. The early web was just like a webpage—that's why it's called a webpage. It's like 8.5 by 11, right? Then mobile was, “Oh, we'll make it a tiny webpage.” It turns out that if you don't just go into the skeuomorphic world, but think from first principles and take advantage of the power of the device, you can do all sorts of other things.

The pull-down-to-refresh gesture was a new concept that came with mobile. I was thinking about this the other day. Have you tried Nano Banana 2?

Yes.

It's really good. One of my colleagues just said, “For an American tourist visiting Japan, make an infographic about what to do and not to do.” It one-shots something that's amazing. How do you edit that output? That's where it feels very well executed, but you could edit the text, you could edit the graphics, you could just one-shot something new, or you could ask, “What is the state?”

I guess this is my question for you: What do you think the state of the art is, or should be? How have you been thinking about this, just because you mentioned design for editing AI output? There are the classic GUI interactions where you click here and change that, but it feels like that's very skeuomorphic.

I would zoom out 2 levels from that to answer that question, because it's a great question. First is that customer trust is really hard in these areas. When you talk to users, sit down, do research with them, ask them questions, and ask the 5 W's, they're very scared of AI—not because of its power, but because it does stuff and they're like, “How do I know that was right, and what did it do?”

It's like the idea that, “Don't worry, my AI bot has gone and sent 15 emails and managed your inbox. Your inbox is empty.” You're like, “Okay, did it? I don't trust it yet.” So I have a trust question around AI generally doing things really quickly. To gain trust, it has to come back to you and say, “Here's what I'm about to do. Are you sure you want me to do this?” without being annoying—without making you say, “Just effing go and do it.”

That's a whole design question: How often does it do that? How do you build trust with any of these tools? The second question is, does it have enough data? So much of AI is one-shotting things. Sit on X, and you'll see a thousand posts like, “Hey, this is the magical prompt, the incantation, the Harry Potter spell that runs you a 1-person, $1 billion business. Just put this prompt in and paste it.”

That's kind of ridiculous because the reality is that you also have a lot of iteration on the data side. One-shotting things is really useful, but you often need to go back and edit the output and the input. I'm not very good at this. I've used this example for a while: You say, “Hey, go write me an essay for my homework.” It'll spit out an essay, and you're like, “Wait, no, no, it's a history class.” It's like, “Oh, okay. Well, let's deliver an essay.” You're actually changing the input, and somewhat this is chat iteration.

But if you've ever tried to do image editing with chat iterations, it's super frustrating. It's like, “Oh, no, you changed the thing I didn't want you to change.” You come back and you're like—there's an input design and experience problem. Part of that is, how do I have the right amount of context? Then there are output and iteration problems.

Our Teamwork Graph can access largely all of your organizational knowledge. It's insanely accurate, has great search, and has amazing relevance. You're like, “Sweet, I have full organizational memory.” Now, the Teamwork Graph knows that I used to write code in 2002, and it knows that because it has this insane memory. I'm like, “It's actually not useful. Don't use that to answer any query I give you,” other than one thing: “Mike used to be a developer. Maybe a bad one, right? He wouldn't get hired nowadays anywhere. But maybe that helps in explaining something to me in a way that says, ‘Oh, you have a computer science degree.’”

I can help explain it to you in this way, but I don't want to know all that information. Why is that an input challenge? You kind of see all these boxes at the moment where it's like, “Search the web, don't search the web; search my organization, don't search my organization.” You're asking the user to make all these choices they don't quite understand.

That's not a design flow, right, where it says, “Hey, this question—I suspect you want me to do this and that. Is that correct?” You see that a little bit in Deep Research, but it's a bit frustrating. And it leads to this whole, “Man, I've got 17 different agents running off and doing stuff.” I'm like, it's the problem of having a lot of interns: the problem with having 50 interns is you get a lot of work done; the problem with having 50 interns is they ask you 50 questions a minute, and you're like, “All you're doing is answering questions for interns.”

So there's an input problem of experience that you really need to solve. Then you get to the iteration problem, which in a corporation is much more difficult, right? We gave this great example of brainstorming, where it's not usually 1 person brainstorming. So in our whiteboard and Confluence, you can bring in agents and say, “Hey, I want to brainstorm about this topic.”

They're really good at going off and getting all the information from your organizational knowledge to the Teamwork Graph and coming back with a really good brainstorm. We get better and better at drawing it and putting the cards in the right places and everything else. If you just take that randomly and say, “Go,” you lose human input and trust.

So, actually, usually what happens then is we've got a bunch of data, we're going to have a meeting, we're going to get people together, and we're going to say, “What do we all think?” Add our intuition, the brain matter—which of these are useful or not useful? And then that information has to go back into some other agentic loop to say, “Cool. Now we've kind of voted,” although the voting is the output of a human process.

Then you're going to go and do something, and then we're going to work out what to do. Did we do it correctly? And all these things. It's, as you said, very nondeterministic in the quality of output, but it requires, I think, this human-agent loop. And getting that right is a design problem: too many loops, it's frustrating; not enough loops, you lose trust. It just happens.

And so we see that. We just shipped agents in Jira in a lot of ways, so you can assign work to an agent and it goes off and does stuff. When we test it with people, they're like, “What's it doing? Do you want to give us 1,000 steps?” They're like, “Why are you telling me all this crap?” I'm like, “Wait, because you said you didn't know what it was doing.”

So there are lots of design challenges with just bringing them into workflows. And back to the business processes, the security team is involved in a lot of places, the accounting team, the finance team. There are lots of places—even in sales, finance usually has sign-off on a deal, or someone in finance does. How do you do that and make that workflow better when you're just assigning to agents?

You need to be very careful about the experience. How does it come back? When does it come back? Is it frustrating? Does it come back in a new way? Can I interrogate what it's doing right now?

Our first- or third-party agents running in Jira can be chatted with while they're doing a task. You can say, “What are you doing?” Which helps you build trust in the short term, we believe. But in the long term, if you trust this particular agent doing this task—man, it's got it right the last 20 times—the odds are it's right. It's good. I'm just going to ignore it.

These are all, I would argue, fundamental, foundational design and experience problems. They're not a technology problem, right? They're about getting millions of people who use our apps every day to trust this and the gains they get from removing the blank box. “I can do unlimited things for you,” which just leads to paralysis.

It's an open question, right? It's clearly not the yesterday version of “Click your mouse here,” and it's not the today version of “Just do a new prompt.” It's both. As long as humans are involved in some way, shape, or form—which I firmly believe they will be, because these tools serve humans—you need to be able to get your head into the model, both from a trust perspective and from an iteration perspective.

It's a design problem, and I don't think anybody's quite nailed it yet. Or, I don't know, maybe they have, but it feels like we're at the very, very beginning of this process of coming up with a better design for editing the one-shots, which, impressive as they are today, are not going to be just a Harry Potter spell incantation.

I'm going to steal that phrase. That's a good one. I think 1 interesting example is just writing documents, which is something we all do so naturally. There is a huge design challenge and experience challenge, which I can describe with AI document writing, but, secondly, there's also a huge people-learning challenge.

We sometimes forget that pretty much people in technology know what a prompt is, what it does, and what the LLM is doing in the background. You go to people in the broad business world, and they don't have time to learn all this. They probably know what ChatGPT is, but they don't quite know how it's working.

The reason it's a design challenge of document creation is we have a whole set of features which we call Create with Rovo. Instead of writing a document by giving you a blank page and just starting to write—“Okay, I got a heading, I put some text in, I put another heading, I put some text in, I put a table,” et cetera—we've all been trained for decades as knowledge workers to write a document that way.

With Create with Rovo, you can literally say, “Start with a prompt. I want a document that roughly does this or looks like this shape.” Give me a template, and it'll spit out a template. You can say, “Hey, I want a document. Can you go off and research this, that, and the other and bring it back?”

But in most of those documents, the research is actually a small category of tasks. It's like, “Help me get started with my document in some way.” Teaching users that they should start that way is really, really hard.

Once they're running, though, they now have 2 panes: 75% of the screen is the document itself, and 25% is a chat window. Think of Microsoft Word without a toolbar, but with chat only. Now I can type text in, I can edit it, I can change it. And you need to say, “Hey, you should be totally comfortable changing everything on the left.”

But you can do operations on the right, like, “Hey, I want you to add a new section that goes and researches this other stuff and put it after the summary.” And it'll go and do that.

When you watch power users, they're like, “This is amazing,” and they're moving back and forth, getting the whole paradigm. They're doing things, and they can write commands like, “You know what? Make every heading blue,” which you can't do in Word, and they're like, “Bang, it's all blue.” They're like, “This is cool. I can kind of give it commands across the document, and I can go get more information.”

I can ask, “Hey, can you resummarize it quicker?” Or, “How do you think the board is going to read this document as a board member? Is it simple enough?” It'll give you information in chat that you may say, “Cool, go action that out,” or don't. It's a completely different paradigm to writing a simple document, which is, at the end of the day, headings and bullets and text and stuff. And when you watch power users, they love it.

Normal people—regular business users who are very smart—are like, “So I just type on the left? That's all I do?” I'm like, “Well, yes. It's a whole paradigm shift.” I suspect as we get more of these tools and experiences, just like mobile, 2 years from now and 5 years from now, that'll be very standard. They'll all say, “Yeah, I get how to do this.”

Maybe the first time someone looked at Excel, they were like, “Wait, where do I type the paragraphs?” And you're like, “Oh, no. You have to think differently about it.” Now it's just like, “Oh, yeah, I get Excel. I know how it works.”

The experience challenge we have, I think, is to take all this power and put it into something as simple as writing a document with all my organizational knowledge. Like, okay, I get the maths of why that's possible, but now help me actually help people do it. Massive amount of challenge there. Massive amount of excitement, right? When they get it, they're like, “This thing is amazing.” But it's going to take us a lot of time to get the experiences correct for people to learn.

That's a great place to wrap. Mike, thank you so much for coming on the podcast. It's been an excellent discussion.

Yeah, no worries, guys.

It was great meeting you, Mike.