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 tried now to say the models are far ahead of the value they're delivering.

The whole history of software from 1960 until 2022 was you would take a filing cabinet

and you turn it into a database.

The cool thing about everything that's happening in AI land is that the filing cabinet can do work.

The idea I would vibe code my own workday and then run it is terrifying.

However, there is a great game we are seeing internally

in extensibility of software using things like five code.

I've been talking about the SaaS apocalypse, some people call it the catastrophe.

Why is there too much fear about this?

As I've said, not every SaaS company is going to thrive to the next decade.

We're not going to defend all of software, obviously.

Her seat pricing built software fortunes for two decades.

It felt fair.

More users, more money.

But beneath the logic, we're very different kinds of businesses.

Some seats were tied to work that AI can now do instead.

Others were just a pricing proxy for headcount.

And those companies may actually benefit from AI.

The public markets so far haven't reliably told them apart.

When the SaaS sell-off hit, valuations dropped across the board,

regardless of whether a company looked more like ZenBesk or a workday.

That's the gap worth understanding.

Companies that survive the transition face a harder job than adding an AI feature.

They have to redesign how humans and software work together,

where loops belong, went to interrupt,

and how much trust an agent has to earn before it acts.

Alex Rampell and I speak with Mike Cannon Brooks,

co-founder and CEO of Atlassian.

The whole history of software from 1960 until 2022

was you would take a filing cabinet

and you turn it into a database.

So the first example of this is a company called Saber Systems,

which was started in 1960 by IBM and American Airlines.

Because it took the reservation system,

which literally was stored in like vaults of filing cabinets,

manned or womanned by lots of lots of secretaries

in like the 1950s and 1940s,

airlines have been around for a long time.

And then it put them in a early database,

back when 10 megabyte hard drive probably cost $100 million.

And then that's what happened with electronic health records.

And the first one was called Mops.

It was built by a mass general hospital

where the first seabull systems predating Salesforce

or actually the first CRM was called ACSystems in 1987.

So basically every single filing cabinet became a database

and there were benefits to that,

but it didn't actually make the world that much more efficient.

Because whereas before you would have a human

go fetch you the HR file for Eric.

Oh, go to the HR filing cabinet,

get me that file.

Now it's in workday.

But now you have to have a CISO to make sure

that your workday doesn't get hacked.

You have IT people to provision accounts in your SSO to work day.

So did the world get that much more efficient?

It did if you had multiple offices

now people can collaborate.

You could do complex joins in a database

much, much harder to do that on pieces of paper.

But that was kind of software from 1960 to 2022

because the filing cabinet couldn't think for itself.

And now this is the cool thing

about everything that's happening in AI land

is that the filing cabinet can do work.

Like QuickBooks can actually accomplish a task by itself

versus just relying on a human to retrieve the file

from QuickBooks and the same at the human in 1500

would retrieve a file from yield filing cabinet

from the yield accounting department.

So it gets interesting.

It's actually a great segue into, of course,

what is everyone talking about?

The SaaS apocalypse.

Some people call it the set catastrophe.

Obviously what's happening in the public markets

and a lot of people have different perspectives

of how significant it is, what it means.

Only 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.

Well, 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, right?

And everyone has hot takes about what the future's

gonna look like, right?

And depending on the takes,

you get a version of the future that's either really good

or really bad for all of software, certain companies,

certain categories in software.

It's a really interesting thing.

There's no doubt in my mind that the risk level has gone up.

So if you think about for an investor mindset,

you're like, this used to be a very stable category.

Now it's a more risky category,

hence I'm gonna step away and watch.

And 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 gonna do?

And they're actually betting on what other people

think that other people think they're gonna do.

And right now that it sort of logically makes sense,

you have a 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.

But the answer is always,

what if I can do that in two years or three years?

What does that mean?

And I think it comes from a very static viewpoint, right?

Like that people won't adapt, the world won't change.

It's like one thing is gonna change

and everything else is gonna remain static.

So you have this interesting world at the moment

where businesses like ours are doing very well, right?

We've had three great quarters in a row

and everybody says so and then you're like,

wait, you know, that used to require to some value.

And it's our job to prove that that's not the case

for our business, right?

We're not here to defend all of software, obviously.

But for our business, we feel very good

about the opportunities we have,

the data we keep showing, the results we keep showing.

And now I always say this as well,

it doesn't mean that we don't have to adapt.

It's this weird world that like,

we are changing how we work radically and quickly

as we always have, as we've been doing for a number of years.

Some part of that I think assumes

that we won't be able to change, right?

There are strategic vectors for sure.

And look, the reality is, as I've said,

not every SaaS company is going to thrive

through the next decade, right?

Just like a bunch didn't make it to the cloud,

a bunch didn't make it from, I don't know,

Windows to the internet era, whichever era you want to say,

no one is going to say I think that a hundred out

of a hundred SaaS companies are going to make it through.

And be thriving and growing on the other side.

Also, we 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, right?

We're in a knowledge world.

We have tools to play with that knowledge,

to act on that knowledge, to do all sorts of other things,

to solve the jobs our customers have always hired for.

This logically is very good,

but it's up to us to execute that,

through that transition, right?

Which I think we're doing really well,

but again, we have to prove that to people over time

that the patient's part is hard for markets.

Alex, how do you react to what's been happening?

How do you make sense of what's going on?

Well, I hope I'm running the long run,

which is all this stuff is crazy.

I think I tweeted about this a few weeks ago,

where my kind of cursory glasses

were the three different types of SaaS companies

and the public markets couldn't tell the difference

between the three.

And one is where seats are tied to outcomes.

So seats are being used by people who use

kind of going back to the filing cabinet metaphor, right?

If I'm Zendesk, I'm using Zendesk

and they came up with a very clever pricing model,

which by the way, I may have to take a step back

before I even answer your question,

which is there's this great book by Dan Arieli

called Predictively Irrational.

And I used to give it to all my product managers

on my company, study this to figure out

how we charge people for stuff.

These are turns out, like in the example it gives us,

imagine you're locked out of your apartment,

it's midnight, you hire a locksmith,

it comes one minute later,

lets you in in 30 seconds as it's 500 bucks

to like 500 bucks, what the f?

Like you just did like 90 seconds of work,

you leave them on one star,

a Yelp review, no tip,

protest the charging or credit card.

Now imagine parallel universe,

locksmith comes,

spends nine hours trying to let you in.

Goes back to his office to get more tools.

Finally, by like nine, 30 in the morning,

finally lets you into your apartment.

You're so grateful that he spent nine and a half hours

helping you get into your apartment,

that you give him a $200 tip,

leave him a five star rating on Yelp.

This is an example that he gives in the book.

And it basically means humans are kind of capable

in willing to pay for incompetence.

Like it's like a lot of pricing is about fairness.

Like it feels fairer that I give that guy more money,

even if he's completely incompetent,

than his counterpart who's super competent,

where I'm so pissed that he overcharged me.

And it doesn't make any sense,

but like it feels fair.

And if you think about how we got to SaaS,

like per seat per month,

like when you're giving away,

in many cases it's like the additional cost

of provisioning a seat digitally is like close to zero,

not for everything, but for some things.

Like it just feels fair.

It's like, oh, you have five seats,

you pay more money than if you have one seat,

even though it's kind of the same thing

going on in the background.

So the three types of SaaS companies that I think of,

great, great oversimplification era,

but category one is you have seats,

the seats are being used to produce some element of work,

but now, like you don't need the seats anymore

to produce the element of work.

So like Zendes could be like patient one there,

where it's like how many seats does a Zendes customer

need today, if they're using zero, a decade on

or roll the road, and it's like potentially zero.

So Zendes can talk about the present value

of future cash flows.

It's like, well, they're in peril,

because the per seat pricing,

like if Zendes said, we're just going to charge you

per seat per month for the current thing,

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 just move to outcome-based pricing

and ditch.

I mean, it still has to be subject to the laws of fairness

and predictable irrationality that we talked about.

But, you know, something like Zendes,

it could go up, it could go down,

but like the default path,

unless it changes, going to zero.

On the complete other side of that,

is you might have per seat pricing

because it feels fair,

but the seats are not tied to an outcome.

So, like, Workday has this great pricing model.

We're like, oh, you're a GE,

you have 340,000 employees.

Yeah, I'm going to charge you per employee per month.

Why, I don't know, it just feels fair.

But those employees that work at GE

are not using Workday to produce an outcome.

So, Workday, I think, is fine.

In fact, if anything,

and that this kind of goes into like,

what can you do with AI tools?

Well, when you hire somebody at GE,

they need to do a reference check

and make sure that you worked at the three companies

that you claimed you worked at.

An HR person has to go look at the file that's in Workday

and go call those three companies.

Workday can call those three companies.

Like an AI tool can do that,

but only through the system of record.

So, it is something like Workday or like,

into it, it's down 45% in the first,

like, it's February 26th or 27th today,

down 45%.

Nobody's going to get rid of QuickBooks.

So, these are the two tent poles,

is like, per seats are charged per month

or per whatever,

and it's tied to some kind of work.

And then seats just happen to be a clever pricing trick,

but it's not tried to work.

And then there are things that are in the middle,

like Adobe, like, yeah, it's maybe you need more seats,

maybe you need fewer seats,

but it's not as stark as the Zendest example

nor the Workday example.

And then against that,

you have this kind of undercurrent

of Alameda Vibe code, everything,

which I think is just preposterous,

having been a software developer for a very, very long time,

because the person that I like to cite

as my counter example here,

is my second favorite economist, David Riccardo.

And in 1817, it's been around for a long time.

You lived a long time ago,

but it's like, this is where the theory

of comparative advantage comes from.

It's like, you could also grow your own food,

you could weld your own aluminum,

but even those are bad examples,

because it's very simple to grow food or weld aluminum.

It's just, I have a comparative advantage,

filming podcast with you.

I can do that too,

but I can earn more doing this,

even though I might be more productive than the plumber,

but I should still do the podcast.

That's actually less important than the,

what I like to call like all the edge cases

that lie beneath, right?

So I could theoretically vibe code me some Workday,

but what happens in Indiana,

if the person leaves and they're on maternity leave,

like all these edge cases,

where it's just you don't know about them

unless you've encountered them in the wild.

So a lot of software is just a set of deterministic roles

that have been learned from like,

in many cases, decades of experience

and the rules are not exposed,

the rules are, they're kind of embedded,

and you can't just replicate them.

You replicate them through experience.

So I think it's like, again,

there are kind of three types of tasks

in my oversimplistic view of the world.

And then there is this like, uh-oh,

like the IP is worthless

because everybody's gonna vibe code their own thing.

And I think on maybe for certain subcategories,

if it's a very simple task with no edge cases,

or maybe you don't need all of the edge cases

that have been built in.

I think software is gonna do great

because it's the true systems of record

that have sticky software that people rely on

that have all of these embedded edge cases,

they're gonna start adding AI,

where AI does the work, right?

It's like, you know, Workday will say,

do you want us to do a background check

into it will say, do you want us to go collect

on your outstanding accounts receivable?

You don't have to go hire humans to do that.

You go hire your software to do these tasks.

That is starting to happen,

but when that does happen,

the present value of future cashflow,

like that's gonna go up a lot.

Like the, the future, like the present cashflow

is gonna go up a lot.

And I just, it's astonishing to me

that a lot of public market investors,

they can't tell the difference

between these different buckets,

and they're not giving any kind of,

like 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.

So like you have all these views, right?

I personally hate the system of record thing

because it sounds like,

oh, a system of record is just like a database sitting there.

It's very static, I put stuff into it

and I pull it out and that's it.

And that views a business as a set of filing cabinets

and very sort of industrial era kind of world, right?

Now that was very different

than the pre-industrial era of a business.

So totally it had a value

and I get why we have the term system of record,

but it feels a little bit like we have

a floppy disk icon as the save button, right?

Where my kid's like, what's that?

And I'm like, that's a disk and they're like,

what is that?

And I'm like, oh shit,

you've never actually physically seen a disk,

but you still have this icon,

you know what the save button does.

And the reason it's questioning this is,

to me, businesses are a set of processes.

They're not a system of record.

These are all process-based systems, right?

Everything Alex is just as totally true,

but there are processes like reference checking

or other things and your ability to coordinate

a set of processes to happen as cheaply

and efficiently and quickly as possible

is actually in a knowledge business,

not an industrial era business,

but a knowledge era business, your entire business, right?

I have 10,000 plus people who walk

into buildings every day and bring their brains

and walk out and take their brains with them.

And 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 that I don't think, right?

And I am all about coordinating a set of processes,

revealing most modern businesses probably are, right?

When you get to, how does that relate to Alex's commentary?

I think it's totally true.

We have different types of processes within a business.

There are, what I'll example,

input constraint and output constraint processes.

The customer service example with Zendesk,

that's input constraint.

Your customers ask a certain amount of questions.

How quickly you process those

is about your efficiency, cost, speed,

quality of running that queue.

If you do it 10 times as fast,

you don't get 10 times as many questions, right?

Like you have so many customers,

there's a relationship or a ratio

for every customer they ask five questions.

How can I make them ask those questions

or process questions quicker, right?

There's actually a lot in a business

that is an input constraint kind of a process.

I was using our legal team as an example, right?

Their job is not to generate legal work.

It is to answer it.

How many leases do we have?

How many NDAs?

How many contracts?

It's like a fixed total set.

And 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 kind of output constraint work.

If I think about anything creative, marketing,

I would argue software development technology,

where I can theoretically do an unlimited amount of tasks,

right?

I'm constrained by my creativity, if you like.

And how many things I can think of to do,

how much value I can deliver from my customers,

those are actually 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 these sorts of things.

The challenge is to look at a business

and try to make this analysis on the outside

because all of your input constraint processes

and output constraint processes

actually work together to make a business.

And they'll have to kind of liaise

in all these interesting ways.

And that's where you see weird pieces of software

that are just coordinating quote unquote humans

are running processes.

And what you're saying about Indiana is totally true

because some of those processes have outside rules.

We call them laws, governance, compliance

that I have to do.

In Indiana, I have to do a certain thing for employees.

So the processes are both how I want my business to run

and how it has to run.

And the business is really just a collection

of all these processes put together.

Like I'm just saying it's a totally different view

from the sort of, we have a system of record

and a system of action or whatever.

And I'm like, that's not how I think

most businesses actually run

but it's often how we think about it.

So I totally, I think that's a great framing.

Like, despite the fact that I love into it,

it's like turbo tax.

Well, like the tax code is published, right?

You can download all of these rules.

It's highly deterministic.

And then your files are in your,

your like messy downloads folder.

And it's like make those two happen.

In that case, it's like one of these bizarre situations

where everything is actually transparent

in terms of the processes.

I think it's actually a quite rare situation

where the edge cases are published in like,

maybe one place or maybe 50 places,

but it's like, oh, you just,

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.

And there probably still are edge cases

and processes that you learn

versus like the real world normally isn't as neat as that.

It's just like you learn by doing

and a business has value.

I mean, there are a lot of businesses

where theoretically, I mean, this is where it's like,

you'd say like all the assets leave every night

because they go down the elevator and they go home.

Like that's like more knowledge economy type things.

But actually, these businesses do have value.

Like, you know, does McKinsey have value outside

of all of the employees that work there?

Because that's a knowledge economy business

where they produce outcomes

and it's tied to labor.

It's not like a product,

but still like they're probably,

they probably have some top secret handbook

that they use around how do they hire people?

How do they fire people?

How do they produce outcomes for clients

and so on and so forth?

I haven't seen it and that's actually great

that I haven't seen it because I can't replicate it.

And it's probably been built over a hundred years.

And like, you know, what is it that non digital

non software products do?

What is their product?

Their product is the accumulated knowledge

from potentially centuries or decades.

I mean, I love going to Japan

and you see like, oh, this noodle store

has been around since like 1587.

And it's like, yeah, there's probably something going on there.

It's like this accumulated set of kind of culture

and knowledge and know how, besides, you know,

here's the recipe list for making noodles.

Maybe that is helping us make noodles

as a little bit easier.

Probably not as many edge cases,

but maybe there are edge cases.

Like, what happens if you run out of flour?

What do you do?

How did the noodles shop survive the great flour shortage

of 1623?

You know, they probably did something

and that's like 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.

Or maybe like Intuit, 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 is you to take your life data,

your understanding, they're asking you the right questions.

Intuit's almost more like a McKinsey.

It can be considered that way.

It's there a process

and there's special ability is how to ask you

the right questions to fill out the tax code

rather than the filling out of the tax code.

Yeah, and all these businesses are having to look at,

maybe I have 50 processes internally

that I think are my secrets also 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 kind of a question of how,

like there's this Goldilocks zone probably of like,

is it worth doing yourself versus not?

Like if you take this kind of like third,

not third rail, but kind of this independent variable

of should I now cloud code myself?

Cloud code myself some X?

Well, if it's like 99% of my cost

and like my business is gonna fail

because this evil company is overcharging me for software,

it might make sense.

If it's like a dollar a year, it probably doesn't make sense.

And then not all systems of record are the same.

So like, you know, I kind of think of a system of record

as like the atomic unit of something for a business.

Like it could be calendars or a system of record for time

or I don't know, ERP is a system of record for inventory.

Like you have all these different systems of record,

but like the example I was giving somebody is

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.

There is a system of record for conference rooms.

It's like Google Calendar.

Like, am I willing to change that system of record?

Yeah, because it's like Miami office

and now together once a year, like who cares?

Versus like this is something that touches my revenue.

It's not that expensive.

Am I really going to grow my own food

for something where, I mean, actually this is a cool thing

about like farming, right?

As you kind of take that metaphor,

it's actually a lot cheaper to go to a restaurant.

If I just want like one hamburger

versus like get myself a cow and feed the cow

and wait to, a lot of food is actually cheaper

if you consume it in a restaurant

because of comparative advantage and economies of scale.

So there probably are systems of record

where it's like there's some where outside of any

of the factors that we're talking about,

they're more susceptible just because they overpriced

or they're just not as valuable

in terms of what it is that they're storing

and keeping records for.

I mean, like, Cardi 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 f'd that up, right?

I'd probably rather use Cardi for that

than like in the only,

they don't charge me how much money,

like sure, I'll use Cardi.

And it's not like a daily use kind of product.

So it's not even like that to mention.

I think the VOD coding thing is sort of fascinating to me

because yes, as someone in software,

they're like, oh, people are just gonna VOD code

all these replacements to tools.

I'm like, the idea I would VOD code my own work day

and then run it is terrifying.

Like, I have some really smart engineers.

Firstly, I have other stuff for them to do.

Secondly, I'm like, wait, I feel like

that has way more downside than upside for me.

However, and so that's the sort of replacement theory.

There is a great gain we are seeing internally

in extensibility of software using things like VOD coding.

So most of these applications are highly configurable,

customizable, in our case,

all the way through to true extensibility.

You can write pieces of software,

apps to run on top of our platform

that have all sorts of different areas

and lots of customers do,

but those customers need to put a technology team

on doing that job.

Their ability to quote unquote,

VOD code, extensions, customizations,

very tailored applications

are their very specific use case of something.

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 work day and it's not.

It's used by 20 people.

I probably wouldn't have been able to afford

to put the IT team internally on building that

because the bill would have been too big,

but now maybe I can build that, right?

But that uses Workday's data and rules

around the world underneath,

but it just gives me a very custom interface

for I don't know 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 work poor work day.

I feel like a nail is like 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 and vibe coding and creativity

to make it more tailored for what I need,

but we're gonna have to be really careful

about the sort of layers of stability and rules

and process versus customization, right?

And you could argue, I don't know,

open-core and stuff is an example of building

very personal apps just for me.

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?

But it still uses Gmail as a rails.

They still go to Gmail to read their email

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 be turning into companies,

most of them are just solving some stuff

that 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

of this pricing fairness where the back end

is not the front end.

So if you think of Salesforce,

they charge for licenses,

like I think we have 600 people at our firm,

might have 600 Salesforce licenses,

I'd never logged into Salesforce,

but I bet we pay for me,

but I use the output of it sometimes

because it actually is the system of record

not to overuse that term,

but it stores like all of our relationships,

but I am like part of a table and a relational database

of it's like, you know,

I'm user ID number 422 here,

and then whenever I meet with a company,

like, oh, well, like user ID 422

is mapped in this other database,

but we really just want to pay for a database.

So like in a world where the front end

is not the back end,

I mean, that's the thing,

it's like for work day,

I kind of think they've come up

with a very clever pricing trick.

The trick under sells it.

I mean, I think it's a powerful pricing paradigm

that feels fair.

It's like the more employees that you have

and why is that fair?

Because GE has more profits than a temperous company,

GE's going to pay more for this thing.

It's still a drop in the bucket.

It's totally within the Goldilocks zone of pricing,

and I don't think anybody is going to

divide code that they're going to add all this AI revenue.

But most importantly, their pricing feels fairer,

whereas for these things where it's like the front end

is somewhat divorced from the back end,

that one is, I don't know what's the fairer format

for pricing, like what will happen to software pricing?

And obviously, like if nobody's going to

divide code their own thing

and there's not going to be any competition,

the pricing will stay unchanged.

But you can imagine a world where people

are building things on top to read from the database, right?

Because any system of record has a database represented.

That's like the abstraction that you're building

beneath everything.

Will the pricing, will there be any pricing pressure

on any of these categories?

And for me, I think it's like if the front end

is not the back end, there's more susceptibility

than if they're like very, very tightly intertwined.

Like QuickBooks is used by small businesses.

They don't have seats.

It's like the owner of the business

just lies into QuickBooks.

So the front end kind of is the back end.

Versus Salesforce where you can imagine like

nobody gets rid of Salesforce,

but maybe they have fewer seats

because they need fewer front ends,

but they really still need the back end desperately.

They're not going to go,

they're not going to eliminate

or do anything with the back end.

It depends on a ways, like I think you're fairness

and optics in pricing are really, really important.

People understanding what they pay for

and feel like what they pay for is

relates to their usage in some broad way, right?

I would say that a 10,000 person company

paying for workday,

the 20,000 person company public place,

twice as much plus some discount

because they're buying more

because they generally have twice

as much complexity of stuff and they see that as fair.

That's what you mean by, like 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.

Those business logics are not irrelevant.

So in the world of what,

why does a business have them

because it runs as a collection of processes

and they want standardization of process to some level,

right?

So the two teams work the same way.

So someone can manage them, understand them,

track output, I don't know if I have a bunch of car factories,

I want to track the total amount of cars

in and out consistently across them.

The business logic where it gets baked in

is somewhat where the value is

because you may need, and again, maybe A16Z

is not a great example of a Salesforce customer

that actually has a huge amount of sales going on

in terms of traditionally.

The process is 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 collaborator rather than the core user,

how much do they need those processes

and how much do they not?

So I don't know, I'm assuming Salesforce,

Salesforce Cloud, I guess we're talking about,

Salesforce 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, someone sells adjacent,

I don't know, they're in marketing

or they're in customer success or something like this.

If they need those processes and governance

and controls and rules and, you know,

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 gonna need an account.

Whether the customer thinks that's fair,

that's a different question.

It's just the challenge of like, how does that get priced?

I'd say, because we get this all the time

talking about consumption-based pricing,

usage-based pricing, outcome-based pricing,

there are a lot of categories where that makes sense.

I definitely do not believe that it will be

the majority pricing manner for all software,

for all SaaS-based software.

Because when you talk to customers, they hate it.

They really hate it.

Where, asterisk, it is not related

to the value they consider that they put in.

So I have usage-based pricing for Splunk.

If I set them twice as many logs,

I pay more money, I get it,

but the logging is up to me, right?

I can log more, I can log less,

I can yell at teams where I'm like,

hey, how come you're logging so much?

This is expensive.

And, you know, you're using these logs,

I can control the amount of data I put in,

same with storage in S3 or something canonically.

I put in a gigabyte, I put in two 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 or consumption-based pricing

are not in control by me as a customer

and not exchangeable.

So the AI token world, the AI credit world,

is really, really difficult for customers

because I'm like, I don't really understand

what this casino token you've given,

casino chip you give me is, right?

I can take a gigabyte from AWS

and go put it in Azure

and I know how much they're gonna charge me

because the gigabyte is kind of constant.

When I have these AI credits,

I'm like, I don't know if your credits

are the same as yours or the same as yours.

And by the way, you keep adding features

which chew up my credits because my users use them

and 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 like features

that make the software better

that seem to just happen, right?

I can 10X my customers 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 the outcome-based usage,

when you talk to customers, they want seats.

Probably because today they understand it

and secondly, they've been burned by a lot of this

consumption-based that the bill just goes up massively

and they're like, wait, how do I control this?

Right, it's a bit of an adjustment.

It will be certainly present in a lot of categories.

You know, we have a bunch of areas of our business

at Atlassian that are, you would argue consumption-based pricing

or literally just consumption-based pricing.

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

and the last example of outcome-based pricing is

those outcomes are also dynamic.

So the problem would say customer service

where I've saved you, you know,

you used to spend $20 on customer service

without totally only spend 10.

That's a great sales pitch in year one.

In year two, the customer goes, but I only spend 10.

Now I want to spend five, 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.

So like my ability to save you money each year

is difficult from an outcome basis, right?

I'm eliminating tasks.

I think also like from a sales perspective,

I've started two payment companies

and it was really, I used to, this is why I know Workday

is I envy 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 people's soft.

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.

And 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 like, you know, we, when we were starting a firm,

we signed up 1,800 flowers.

We have no idea how much we're gonna make from them.

And it turned out like, you know what really made

a business work, Casper the mattress company.

It's like, what, like this stupid math link,

but it's like, you just don't know.

And you think like, you get like a big deal,

like we got Walmart, didn't really work out that well

in the beginning, we get Casper the mattress company.

Oh my God, incredible.

Workday has the, it's predictability in both directions, right?

It's predictably for the spender of the money,

which is the customer, but it's also the 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 a 10 person company.

Whereas it's crazy in internet land,

where it's like, strike might make more money

from a 10 person company than GE.

And I guess you could get to like higher levels

of predictability there, but like,

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, a sales and marketing team.

As an entrepreneur, one thing I want to go back

to sort of deal with 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 look, we sell collaboration tools

that solve human collaboration problems, right?

In lots of different areas, service teams,

broad business teams, HRF finance, software teams,

lots of different types of teams

by different sets of apps from us,

collections and sets of apps.

Fundamentally, they're all collaboration problems

that involve a lot of texts, so this is really good for us.

What are those people doing

is probably the important part, right?

The technology world often runs to,

we're gonna reinvent everything

and that's the way of the future

and that generally is true in the medium to long arc of time.

Our challenge is always, we have a lot of customers

who work in today's manner,

today's workflows in today's set of apps

and they're not, they're very smart,

they wanna get to tomorrow,

but they also have to move a lot of people.

So when we're building AI features

and I can give examples of any of these,

we need to understand what that technology is,

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?

Because this stuff's accelerating so fast, right?

So that's how we got to our AI gateway

in the teamwork graph

and the enterprise compliance and controls.

You have to separate that out from the features

you're building for customers in a given hour.

Then have to build features for customers of their 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, higher quality 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 from the customer

because they can use them today.

Like their existing way of working just got better.

They're like, this is amazing.

Like they rave about that stuff.

And in the AI world, they're like,

but that's pretty simple.

And it's like, but it actually helps them today

in a massive way.

I tell people internally though,

and you can give an example in service, right?

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, right?

So we have to do all of these things.

So if you look at, you know,

Gira's canonical example,

you know, 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's a lot of existing workflows we have

in an enterprise, maybe a four or five,

six people work a ticket internally

to try to solve a problem.

The fourth person that shows up,

there are a whole lot of attached files.

There's a lot of conversation.

There's a lot of different things going on.

They would normally have taken 30 minutes

to like read it all and understand what's going on.

So then they can bring their expertise

to bear on the problem.

Literally just summarizing that

and it's not a simple stick it into, you know,

an LLM and get back to summary.

You have to be very careful about the context

is so powerful for them,

but they haven't changed their workflow when I own it.

It's still Alex saying,

hey, Eric, can you come help me with this ticket?

Eric shows up, Eric has to bootload

his brain with all the things.

So that's like an existing workflow

where we can use LLMs just to make that customer

way better and they love it, right?

They rave about all these types of features,

but they're very simple.

They're usually not agentic.

Then we can say cool, but that service workflow,

we need to put agents in at various spots, right?

And most people are taking a workflow

and finding, you know what,

this step trips us up a lot.

This costs us a lot of time.

Can we make this step faster?

And that's absolutely something

that we have to provide agent frameworks ourselves.

We have a pretty great agent framework

that uses all the tumor graph

and all the context you have.

It's pretty simple.

It's pretty very affordable.

Or you bring your own agent framework, right?

Most businesses, I think, will have three to five

large-scale agent platforms running internally

and they say, hey, I use agent force for this

or I use Gemini for this.

Great.

Bring that agent and we'll pop into the workflow here

and we'll make that work, right?

We have to be able to do that.

But you're still on the existing workflow world.

You're just doing the all task

and then doing kind of a new and efficient task

but in the existing workflow.

Then you get people like,

what if the service ticket didn't exist at all, right?

So you're reimagining whole categories of software

to new workflows and we have to help our customers

make it across that gap because they don't generally have

one service team.

They have hundreds, right?

And if they have hundreds of different service desks

running, they might say,

these 20 are gonna work in this new way.

But they have to manage them all.

So I guess we're trying to bring data in the teamwork graph

in the teamwork graph together with this

and also from a customer-driven lens.

I think that often gets left out here, right?

We're trying to take them five years into the future.

It's our job to actually get them one year and two years

and five years into the future simultaneously,

which we're trying to do.

And the last thing I'd say is we're investing a lot in design.

And I think that always in any AI conversation

gets left out because there's a lot of foundational design

to do in how this works, right?

We're seeing the first elements of this.

But if I look at the mobile era,

the first set of apps were kind of just

canonically taking desktop or web things

and sticking them in a phone.

And then we evolved new patterns of interaction

and experience, right?

Not even the visuals.

How do we use these things?

Well, push notifications for it.

They didn't exist at the start, right?

Drag to refresh is like a very obvious simple example

that's a pretty canonical design pattern

that generally it's successful here

and it gets moved across.

But the whole like,

how do I use my mobile on my desktop together?

How do I move back and forth?

We have so many design challenges to solve

that actually help people to understand what's there.

The average customer we have,

the average user they don't want to understand.

If the AI doesn't exist for them, that's fine.

But they want the outcomes of it, right?

They don't need to know all of the technical detail.

Let's out job the hide them

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 by like model quality.

It's almost tried now to say the models

are far ahead of the actual value they're delivering now.

The underutilized capabilities are so big.

A part of that equation is actually design experience.

Right, how do I get this?

Give people a chat box that can do unlimited power

and they're like, tell me a dad joke.

Like it's like unlimited power

but it's very hard to help them utilize that power

which is where a huge amount of our challenge

goes in terms of bringing agents

and all the power of them into workflows

and collaborative loops and having humans

and agents work together.

I love the Schumorfic point.

Well, you know, it's first,

it's like you have pieces of paper

that early web was just like a web page.

That's what's called a web page.

It's like eight and a half by 11, right?

And then mobile, oh, they get a tiny web page

and then it turns out if you dog just go

into the Schumorfic world

but you just think from first principles

and take advantage of the power of the device,

you do all sorts of other things.

It's like, you know, the scroll to refresh, right?

Like the pull down to refresh

that was a new concept that came from mobile, right?

So I was thinking about this the other day.

I'm like, have you tried nano banana two?

Yes, it's really good, right?

So one of my colleagues just said,

hey, for an American tourist visiting Japan,

make an infographic about what to do and not to do.

And it's like it one shot something that's amazing.

How do you edit that output, right?

And that's where it's like, you know,

it's feels very, it's like, well, you could edit the text,

you could edit the graphics,

you could just one shot something new.

Or, you know, what is this data?

I guess this is my question for you.

It's like, what do you think the state of the art is

or should be and how have you been thinking about this

just because you mentioned design

for editing the output of the AI output, right?

Because they're like, they're the classic.

It's like, oh, I'll use a GUI and click here and change that.

But it feels like that's very Schumorfic.

I would zoom out two levels from that to answer that question

because it's a great question.

First is customer trust is really hard in these areas, right?

When you go talk to users,

you sit down, you do research with them,

you sit, you ask them questions, you ask the five wise,

they're very scared of AI, not because of its power.

Because it does stuff and they're like,

hey, how do I know that was right?

What did it do, right?

It's like the idea that, oh, don't worry,

my AI bot's gonna send 15 emails and manage your inbox.

And you're like, okay, I don't trust it yet.

So I have a trust question on generally AI

doing things really quickly.

To gain trust, it has to come back to you

and say, here's what I'm about to do.

You sure you want me to do this

without being annoying it like just F and go and do it.

So that's a whole design question.

And how often is it, how do you build trust

with any of these tools?

The second is, does it have enough data, right?

So much of AI is one-shutting things.

Sit on X, you'll see a thousand like,

hey, this is the magical prompt

incarnation Harry Potter spell that does this

like runs you a one-person billion dollar business.

Just put this prompt in and paste it.

And like, that's like kind of ridiculous

because the reality is you also have a lot of iteration

on the data side, right?

One-shutting things is really useful

but you often need to go back and edit the output

and the input, right?

I'm not very good.

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.

They're like, oh, okay, well, that's totally an essay.

And like, you're actually changing the input

and somewhat this is chat like iterations.

But if you've ever tried to do that

image editing with chat iterations,

it's super frustrating.

Where it's like, oh no, you changed the thing.

I didn't want you to change and you're going back,

you're like, ah!

So like, there's an input design and experience problem.

Part of that is, how do I have the right amount

of context?

And then there's an output and iteration problems.

Our teamwork graph can access largely

all of your organizational knowledge.

It's insanely accurate.

It's got great search.

It's got amazing relevance.

And 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

and 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?

It wouldn't get hired nowadays anywhere.

But maybe that helps in explaining something to me

in a way that, 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 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.

Like, you're asking to use and make all these choices

that don't quite understand.

That's not in 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 like, man,

I've got 17 different agents running off

and doing stuff and I'm like, it's like the problem

of having a lot of interns.

We like the problem with having 50 interns

as 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?

Because we gave this great example of brainstorming

where it's not usually one person brainstorming.

So in our whiteboard and confluence,

you can bring an agent and say,

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 team of graph

and coming back with a really good brainstorm.

And we get better and better at drawing it

and putting the cards in 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.

We're going to go and say,

what do we all think?

Add our intuition, the brain matter,

which of these are useful and not useful.

And then that information has to go back

into some other agentic loop to say, cool.

And now we've kind of voted,

although the voting is like 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.

And did we do it correctly and hold these things?

It says you said it's very non-deterministic

in the quality of output.

But it requires, I think, this human agent loop, right?

And getting that right is a design problem.

Too many loops, it's frustrating.

Not enough loops, you lose trust,

and it just happens.

And so we see that.

We've 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.

And when we test it with people, they're like,

well, what's it doing?

I'm like, do you want to give us a thousand steps?

And 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.

And so there are lots of design challenges

with just bringing them into workflows.

And back to the business processes,

like the, I don't know, the security team

is involved in a lot of places.

The accounting team, the finance team,

there's lots of places, like 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

where 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?

Like our agent, first or third party agents

but running in JIRA, if they're off doing a task,

you can chat to them while they're doing the task

and say, what are you doing?

Which helps you build trust in the short term, we believe.

But in a long term, if you trust it,

this particular agent doing this task,

man, it's got to write the last 20 times.

The odds are right, it's good.

I'm just going to ignore it.

These are all, I would argue,

a fundamental foundational design and experience problem.

They're not a technology problem, right?

They're getting millions of people who use our apps every day

to trust this and the gains they get

and removing the blank box.

I can do unlimited things for you,

which just leads to paralysis, I think, for most people.

It's an open question, right?

It's like, because it's clearly,

like, it's not the yesterday version

of, like, click your mouse here

and it's not the today version of, just do a new prompt.

It's like, it's like, it actually is,

like, as long as humans are involved

in some way, shape or form,

which I firmly believe they will be,

is 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

and it's a design problem.

And nobody's quite nailed it yet, right?

I 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 modulating, not even modulating,

but just kind of editing the one shots,

which impressive as they are today,

it's just like, that's not gonna be,

I just don't believe it's just like,

ah, Harry Potter's spelling can't teach,

I'm gonna steal that phrase, that's a good one.

I think one interesting example

is just writing documents is something we all do so naturally.

And there is a huge design challenge,

an experienced challenge which I can describe

with AI, document writing.

But secondly, there's also a huge,

like, people learning challenge.

So like, we sometimes forget to take,

pretty much people in seconds

you know what a prompt is and what it does

and what the hell I'm doing in the background.

You go to people in the broad business world

and have time to learn all this,

they kind of probably know what JetTPT is,

it's kind of how it's working.

And the reason it's a design challenge

of document creation is we have a whole set of features

which we call create with rovo,

which 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 it,

I put another heading, I put some text in it,

I put a table, et cetera, all right,

is we've all been trained for decades in knowledge worker

to write a document that way.

With create with rovo, you can literally say,

start with a prompt, right?

Hey, I want a document that roughly does this

or looks like this shape,

give me a template and I'll spit out a template.

You can say, hey, I want a document,

can you go off and research this and the other

and bring it back?

But 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 two pains, right?

They have 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 touch text in, I can edit it, I can change it

and you need to say,

hey, you should be totally comfortable

to change 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 other stuff

and put it after like the summary

and it'll go and do that.

Trying to watch power users are like this is amazing

and they're like moving back and forth

and they're getting the whole paradigm

and they're like 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 and they're like,

this is cool, I can kind of give it commands

across the document and I can go get more information

and I can like, hey, can you resummerize it quicker

or man, how do you think they can ask questions?

Like, how do you think the board is gonna read this document?

As a board member is it simple enough

and it'll give you information in chat

that you may say cool, go action that or don't.

It's a completely different paradigm

to writing a simple document, which is just,

at the end of the day, headings and bullets

and texts and stuff.

And when you watch power users, they love it.

Normal people like regular business users

who are very smart, they're 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, two years now and five years now,

that'll be very standard.

They'll all say, yeah, I'd get how to do this, right?

Maybe the first time someone looked at Excel,

they were like, wait, where do I type the power graph

or something?

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.

That's the experience challenge we have, I think,

to get all of this power and put it into something

as simple as writing a document

with all my organization or knowledge,

like, oh, yeah, I get the maths of why that's possible,

but now help me actually help people do it.

Massive amount of challenge there.

Maths around excitement, right?

It's, when they get it, they're like, this thing is amazing,

but it's gonna take us a lot of time to get,

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

and then an excellent discussion.

Yeah, no worries, guys.

Hope it was great.

Yeah, there's a lot of you, Mike.

Thanks for listening to this episode of the A16Z podcast.

If you liked this episode, be sure to like, comment, subscribe,

leave us a rating or a review,

and share it with your friends and family.

For more episodes, go to YouTube, Apple Podcast,

and Spotify.

Follow us on X, at A16Z, and subscribe to our substack

at a16z.substack.com.

Thanks again for listening,

and I'll see you in the next episode.

As a reminder, the content here is for informational purposes only.

Should not be taken as legal business, tax, or investment advice,

or be used to evaluate any investment or security,

and is not directed at any investors or potential investors

in any A16Z fund.

Please note that A16Z and its affiliates

may also maintain investments in the company's discussed

in this podcast.

For more details, including a link to our investments,

please see A16Z.com forward slash disclosures.