In an a16z interview with Atlassian's CEO, it was noted that AI is not the end of SaaS but rather a catalyst for industry differentiation. Software designed to handle complex real-world business processes will not disappear; instead, AI will drive significant growth for these solutions. The biggest bottleneck in current AI implementation is human trust in AI. Future software competition will not only hinge on model capabilities but also on the interplay between barriers in business logic and the psychology of pricing.
In response to the public market's extreme panic over 'AI destroying SaaS,' a16z partner Alex Rampell argues that this fear stems from static thinking detached from reality. Core business processes that are truly built to handle real-world scenarios will not only survive but also experience a surge in cash flow.
On March 6, renowned investment firm a16z and Atlassian’s CEO Mike held an in-depth discussion on the narrative of the 'SaaS apocalypse' that has captured significant attention in the public market.
Participants believe that the current panic is somewhat detached from reality. AI is not the end of SaaS but rather a catalyst for industry bifurcation. Future software competition will hinge not only on model capabilities but also on the barriers of business logic and the psychology of pricing strategies.
SaaS Valuation Divergence: Who Will Go to Zero, and Who Will See a Cash Flow Boom?
Public market investors today often lump all software companies together. However, in reality, the impact of AI on different SaaS categories varies significantly. Alex pointed out that current SaaS companies can be roughly divided into three types, yet the market lacks the ability to differentiate among them.
The first category comprises highly vulnerable businesses where accounts are directly tied to output, such as Zendesk. Alex stated:
“Zendesk is the ‘patient zero’ here. If Zendesk customers now use Sierra, Decagon, or opt for in-house solutions, the number of accounts they need could drop to zero.”
For such companies, unless they shift to outcome-based pricing and fundamentally transform their existing models, “that revenue stream will go to zero without a doubt.”
The second category includes core business systems with strong moats, such as Workday. These systems appear to charge per account, but this is merely a 'smart pricing strategy.' Their true competitive advantage lies in decades of embedded implicit rules and 'edge cases.' Alex emphasized:
“Much of this software represents a set of deterministic rules accumulated through decades of learning… What if an employee in Indiana leaves while on maternity leave? Unless you’ve encountered it firsthand, you’d have no way of knowing these edge cases.”
For such deeply embedded enterprise systems, AI will not eliminate them but instead add significant incremental value.
"True core business systems, sticky software that people rely on and which incorporates all edge cases, will perform exceptionally well... When this fully materializes, future cash flows will grow dramatically, which is astonishing."
The third category includes products in an intermediate state, such as Adobe. The AI era will reduce the demand for these products, though not as drastically as for Zendesk, nor will they remain completely unaffected like Workday. The impact falls somewhere in between.
Why do customers dislike 'pay-per-result and pay-per-Token' models?
As AI becomes more widespread, front-end applications are gradually decoupling from back-end databases, posing a severe challenge to software pricing models. There is growing advocacy in the market for transitioning to 'pay-per-consumption (Token/credits)' or 'pay-per-results,' but implementation faces substantial resistance.
Mike pinpointed the root of customer resistance:
"When you talk to customers, you realize they absolutely hate it; they are really averse to asterisk-laden terms."
He explained that traditional cloud storage billing is predictable, but the world of AI Tokens remains a black box for customers.
"Customers feel they don't understand what these tokens or credits you give them really represent... I can make my client's usage explode tenfold overnight simply by adding a bunch of features like generating great summaries for them. Customers will feel they never asked for that."
Furthermore, billing based on results (e.g., cost savings) works as a strong sales pitch in the first year, but by the second year, customers perceive the baseline as already lowered, making it difficult to measure the incremental value provided by AI. Hence, Mike concluded:
When you communicate with clients, they still prefer account-based billing. This may be because they now understand this model better and have been burned by many usage-based billing models.
Vibe Coding cannot replace core processes.
A prevailing 'replacement theory' in the tech community suggests that through AI programming (Vibe Coding), enterprises can write code themselves to replace all traditional SaaS tools. However, Mike frankly stated that this idea is unrealistic.
Mike pointed out that the core of a knowledge-based enterprise lies in coordinating thousands of input-constrained processes (such as legal or customer service approvals) and output-constrained processes (such as R&D or creative marketing).
I personally dislike the term 'core business system,' because it sounds like a static database... To me, a business is a process-based system, not a record-keeping system.
The real change brought about by AI programming is not enabling companies to rewrite an entire Workday from scratch but allowing them to build highly customized applications at extremely low cost on top of these foundational systems. Mike added:
For instance, I might want a meeting room booking app developed specifically for my team in Miami... In the past, I definitely couldn’t afford it... But now, I might be able to build it easily. This app relies on Workday’s global data and rules at its foundation.
This actually makes the underlying SaaS giants 'stickier and more valuable in the enterprise market.'
The Last Ten Kilometers of AI Implementation: It's Not About Model IQ but Trust Design
In exploring the imaginative space for future products, the interview revealed the experiential gap AI software must bridge before generating revenue. Current model capabilities far exceed the value being delivered, with the bottleneck lying in UI/UX design and human trust mechanisms.
Mike pointed out that the biggest challenge in introducing intelligent agents into complex business approval workflows is not underlying computing power, but rather how to eliminate the sense of a 'black box.' If AI processes dozens of emails instantly, users' instinctive reaction is panic rather than gratitude.
"Blindly promising 'I can do anything for you' will only leave users at a loss."
The future of software interaction is undergoing an evolution from 'skeuomorphism' to first principles. Take document workflows as an example: traditional typing and layout are being replaced by an AI collaboration model where the left side displays document entities and the right side features a chat window.
Although changing users’ habits formed over decades is highly challenging, this represents not only a paradigm shift in product design but also an essential path for SaaS companies to convert AI potential into tangible subscription revenue. As Mike stated:
"The reality is that not every SaaS company will thrive in the next decade... but for us, this is the best thing that has happened to our business."
The full transcript of the interview follows:
Alex: From 1960 to 2022, the entire history of software has been about turning filing cabinets into databases. The first example was the SABRE system developed by IBM in collaboration with American Airlines in 1960. It replaced paper reservation systems previously managed by numerous secretaries and stored in safes, transferring that data into early databases. Keep in mind that during that era, a 10MB hard drive could cost hundreds of millions of dollars. The development of electronic health records followed a similar trajectory; Massachusetts General Hospital (Mass General Hospital) created one of the earliest systems, MUMPS. Similarly, Salesforce and the first CRM company founded in 1987 did the same—they essentially turned filing cabinets into databases.
This approach does have its advantages, but it hasn’t made the world significantly more efficient. In the past, if you needed Eric’s file, you would send someone to retrieve it from the HR department's filing cabinet. Now, while all the data resides in Workday, you need to appoint a Chief Information Security Officer to prevent hacking, and IT personnel are required to configure user accounts (seats) in single sign-on systems. Efficiency improvements are noticeable only in cross-regional collaboration, where people can now collaborate and execute complex join queries on databases—something much harder to achieve in the era of paper documents. However, essentially, software from 1960 to 2022 remains static because filing cabinets themselves cannot think.
The coolest thing happening in the AI field today is that filing cabinets can now work on their own. For instance, QuickBooks can now independently complete certain tasks instead of merely relying on humans to retrieve files from the system—akin to leaving behind the old-fashioned accounting departments of the 16th century sifting through archive cabinets. This is truly fascinating.
Erik: That’s indeed an excellent entry point. Everyone is now talking about the 'SaaS apocalypse' or even the 'SaaS catastrophe,' clearly referring to what is happening in public markets. Many people hold different views regarding its significance. I’d like to hear how both of you interpret it. What exactly is happening? More importantly, how should we make sense of all this? Why is everyone so fearful?
Mike: I believe that the entire world is currently trying to figure out how to rate or value software businesses during this highly disruptive phase. Everyone has their own sharp perspective on what the future might look like. Different viewpoints paint two extreme scenarios for the entire software industry, certain companies, or categories—either extremely positive or extremely negative. Undoubtedly, the level of risk has risen at present.
From an investor's perspective, SaaS used to be a very stable category. Now, due to heightened risks, people tend to step back and adopt a wait-and-see attitude. As I often say, investors are not necessarily trying to calculate all historical profits of a company through a discounted cash flow model. Instead, they are actually speculating on what other investors might do—or in other words, they are betting on how others perceive the direction of the future.
The current panic is somewhat detached from reality. People keep thinking, 'What does it mean if AI can achieve a certain function within two to three years?' I believe this concern stems from a very static way of thinking—as if people won’t adapt and the world won't change, as though only AI technology is evolving while everything else remains static. Therefore, the current situation is quite interesting: enterprises like ours continue to perform well, with excellent results for three consecutive quarters. Although we are not here to defend the entire software industry, regarding our own business, we are very optimistic about the current opportunities, as demonstrated by the data and outcomes we consistently show.
Of course, this does not mean we don’t need to adapt. We are fundamentally and rapidly changing the way we work, just as we have done in recent years. Many mistakenly assume that we cannot change or respond, which is clearly incorrect, although there are indeed many strategic uncertainties ahead. The reality is that not every SaaS company will thrive over the next decade. Just as in the transition from the Windows era to the internet age, a large number of companies failed to successfully migrate to the cloud; it’s impossible for all 100 SaaS companies to survive and grow stronger. Some even argue that software will somehow become obsolete or merely degrade into a cash revenue stream. However, speaking on behalf of our company, this is the best thing that has happened to our business. We operate in a knowledge-driven world, equipped with tools to explore and act upon knowledge in order to solve the tasks our clients hire us for. This is logically perfect, but we must prove it in practice during the transformation process because maintaining market patience is challenging.
Erik: Alex, what about you? What is your reaction to recent events, or how do you interpret what is happening?
Alex: I hope my judgment will be proven correct in the long term because what is happening now is simply insane. A few weeks ago, I posted a tweet on this topic. My preliminary observation is that there are roughly three types of SaaS companies in the market right now, but the public markets are unable to distinguish between them. One type ties account (seats) permissions directly to output, where accounts (seats) are occupied by actual users of the system—this brings us back to the earlier analogy of the filing cabinet.
Before diving deeper, I’d like to take a step back to address your question. Dan Ariely wrote an excellent book called Predictably Irrational. I used to distribute this book to all product managers in the company so they could learn how we should charge users. There’s a classic example in the book: Imagine you get locked out of your apartment at midnight and call a locksmith. He arrives in one minute and spends 30 seconds opening your door, then charges you $500. You would likely think, 'He only worked for 90 seconds and charged me $500? What’s going on?' So, you leave him a one-star review on Yelp, give no tip, and possibly even dispute the charge with your credit card company.
Now imagine an alternate scenario: The locksmith comes, spends nine hours trying to open your door, returns to his office to fetch more tools, and finally gets you inside by 9:30 in the morning. At this point, you would feel incredibly grateful that he spent nine and a half hours helping you, give him a $200 tip, and leave a five-star review on Yelp.
This example essentially illustrates that humans, to some extent, are both able and willing to pay for 'incompetence.' Much of pricing strategy revolves around perceived fairness. We feel it’s fair to pay more to someone who struggled all night, even if they were entirely incompetent, while we feel intensely angry toward a highly skilled counterpart because we perceive their fee as excessive. It makes no logical sense, but emotionally it feels fair.
If you reflect on how we evolved into the SaaS model—for instance, charging per user on a monthly basis—when you offer it for free, the digital configuration costs in many cases approach zero. This doesn’t apply universally, but people just perceive it as fair. For example, if you have 500 accounts (seats), you naturally pay more than if you had only one account (seat), even though the underlying mechanism is largely the same.
Therefore, I believe SaaS companies can be roughly divided into three categories. The first category refers to situations where you previously needed seats to produce certain work elements, but no longer do. Zendesk is the 'patient zero' here. If Zendesk customers now use Sierra, Decagon, or choose to develop their own solutions, they might need zero seats. Thus, when we discuss Zendesk, we are talking about the present value of future cash flows. They are at risk because if they only charge for existing products on a per-seat basis without ever altering the code or pricing model, that revenue stream will inevitably drop to zero. On the other hand, if they transition to outcome-based pricing and abandon the old model, their revenue could triple or quadruple. This remains subject to the laws of fairness and predictable irrationality. A product like Zendesk may rise or fall, but unless changes occur, the default trajectory leads to zero.
The second category involves seat-based pricing, which feels fair, but the seats are not tied to any specific outcomes. For example, Workday has an excellent pricing model: since you have 340,000 employees, they charge you per employee per month. Why charge this way? I don't know; it just seems fair. However, GE's employees aren't using Workday to produce results. I think Workday is great, but this actually relates to what you can achieve with AI tools. For instance, when GE recruits employees, HR must review documents in Workday and call the candidate’s previous three employers to verify their credentials. But AI tools could fully automate these calls, provided you integrate them into core business systems. Currently, IT spending has dropped by 45%, yet no one would abandon QuickBooks. These two pillars represent charging based on seats linked to some form of workload—seats are simply a clever pricing strategy.
The third category consists of products in an intermediate state, such as Adobe. You might need more or fewer seats, but the situation isn’t as extreme as Zendesk nor as detached as Workday.
Beyond these scenarios lies a subtle undercurrent suggesting that AI could write all code. As a seasoned software developer, I find this notion absurd. I’d like to reference the theory of comparative advantage proposed by economist David Ricardo in 1817. For instance, you could grow your own food or weld aluminum yourself, but even these simple examples are inappropriate. It’s akin to my having a comparative advantage in recording this podcast with you—I earn more doing this, even though I might be more productive as a plumber, I should still focus on podcasting.
More importantly, there are edge cases hidden beneath the surface. In theory, I could automate some Workday processes through AI programming, but what if the employee in Indiana who left was on maternity leave? Unless you’ve personally encountered such edge cases, you wouldn’t even know they exist.
Much software represents decades of accumulated deterministic rules that are neither disclosed nor easily replicated—you cannot directly copy them; they must be reproduced through experience. If a subtask is very simple and free of edge cases, AI can indeed handle it.
However, I believe that true core business systems—software that is sticky, relied upon, and incorporates all edge cases—will play a significant role. These systems will begin incorporating AI-driven functionalities, such as asking whether you want to conduct background checks or follow up on overdue accounts receivable. You won’t need to hire humans; your software will perform these tasks. When this becomes a reality, future cash flows will surge dramatically, which astonishes me.
Many public market investors fail to distinguish between these categories. They are excited about AI but don’t realize that AI must be deployed through core business systems. I think this is a fascinating moment for everyone to return to the first principles of business fundamentals.
Mike: Personally, I dislike the term 'core business system' because it sounds like a static database where you store and retrieve items. Viewing business as a filing cabinet system reflects an industrial-era mindset, starkly different from pre-industrial business models.
I understand why the term exists, but it feels outdated—like how we still use floppy disk icons for save buttons, even though kids today have never seen a physical floppy disk. I question this perspective because, to me, business is a process-based system rather than merely a record-keeping system.
Everything Alex just said is absolutely correct. In a business, there are processes such as background checks or similar procedures. The ability to coordinate a series of processes in the most cost-effective, efficient, and rapid way possible is actually at the core of knowledge-based businesses. In the era of the knowledge economy, I have tens of thousands of employees walking into the building every day with their brains to work and leaving with them at the end of the day. I don't own any physical assets like drills, steel, or even filing cabinets. Everything I do revolves around coordinating these sets of processes, and I believe that’s true for most modern enterprises.
How does this relate to Alex's comments? I think it's absolutely correct. We have different types of processes in our business, and I like to refer to them as input-constrained and output-constrained processes. Take Zendesk’s customer service as an example—it’s input-constrained. Your customers will submit a certain number of questions, and your efficiency, cost, speed, and quality depend on how quickly you handle those queries. If you handle them ten times faster, you won’t get ten times the number of questions because the number of customers is fixed. The challenge lies in figuring out how to reduce the number of questions they ask or process them more quickly. In reality, many processes within a business fall under the category of input-constrained.
I often use our legal team as an example. Their job isn’t to proactively create legal work but to respond to and handle it. For instance, how many lease agreements do we have? How many NDAs? How many standard contracts? It’s like a fixed total volume. To complete that work, I’m trying to do it as efficiently as possible, which falls under the category of input-constrained tasks with a well-defined execution process. But then there are also output-constrained tasks, such as creativity, marketing, and even software development and technology, where theoretically I could accomplish an infinite number of tasks.
My bottleneck is my creativity—or rather, how much I can think of to do and how much value I can deliver to my clients. These are the areas where I achieve efficiency gains and produce more, rather than simply restricting inputs to make the company profitable.
The point about Indiana is entirely correct because some processes are necessarily constrained by external rules, such as laws, governance, and compliance requirements. In Indiana, I must follow specific procedures for my employees—these processes define both how I want the business to operate and how it must operate. Essentially, a business is a collection of all these processes. From one perspective, we have systems of record and systems of execution. My view is that while this may not reflect how most businesses actually operate, it’s often how we conceptualize them.
Alex: I completely agree. I think this is an excellent framework. I love the analogy of Intuit being like TurboTax. Since tax laws are publicly published, you can download all the rules—they’re highly deterministic. You can handle tax filings and those messy downloads simultaneously. In this case, all the rules are transparent, but I think the publication of edge cases is actually quite rare.
Businesses hold value. In theory, many enterprises leaning toward the knowledge economy see all their assets walk out the door every night via the elevator, yet these businesses still possess core value. For instance, does McKinsey retain value after all its employees leave? It’s a knowledge-driven operation deeply tied to labor rather than physical products. Even so, they likely have a confidential internal manual detailing how to operate, how to hire and fire employees, and how to deliver results for clients. I’ve never seen such a manual, and because I haven’t, I can’t replicate it. It may have been developed and refined over a century.
What is the product of non-digital, non-software companies? Their product might be centuries or decades of accumulated knowledge. I enjoy visiting Japan, where you’ll find noodle shops that have been operating since around 1587. Such longevity surely involves something special—a long-term accumulation of culture, knowledge, and technical expertise, along with a recipe list for making noodles. Making noodles might seem relatively straightforward without too many edge cases, but extreme situations can arise. For example, what would you do if you ran out of flour? How did the noodle shop survive the great flour famine of 1623? They must have taken certain measures, and those experiences accumulated in a secretive book of know-how rather than replicating what was already publicly available.
Mike: This is what fascinates me—it forces us to rethink our business. Is Intuit really filling out tax codes for you, or has Intuit reached a level of understanding of tax codes that no one else can match? The core value they provide is helping you process life data and clarify your understanding by asking the right questions. In that sense, Intuit now resembles McKinsey more than ever. Their unique skill is knowing how to ask you the right questions to fill out tax forms, rather than merely completing them.
Now all businesses are forced to reevaluate themselves. Perhaps I once thought I had 50 internal processes that were unique and core secrets, but in reality, only 20 are truly essential. I now need to seriously consider which of these processes are genuinely unique and which aren’t, because we’ve never had to think this way before.
Alex: I believe this is, to some extent, a question of how to strike a balance. Regarding whether it is worth doing it yourself, if you choose to use a third-party tool, it is not an untouchable red line but rather an independent variable. Should I write my own code using Claude Code now? If a company charges too much for software to the point that it could lead to the failure of my business, and I can already meet 99% of the requirements and cover costs by developing it myself, then writing the code myself makes sense. However, if the software only costs one dollar per year, then self-development would not be worthwhile.
Moreover, not all record systems hold equal value. I tend to view record systems as the atomic units of a business. For example, a calendar is a system for recording time, while an ERP is a system for tracking inventory. You have all these different dimensions of record systems. I once gave an example: I have an office in Miami that I don't visit often, and there's a meeting room reservation system similar to Google Calendar. Would I be willing to invest effort into changing that system? Clearly, yes, because I only go to that office once a year—who cares if it's stable or not?
By contrast, some systems directly impact my revenue, and they are not expensive. Do I really need to grow my own food just to eat? Using an agricultural metaphor, dining at a restaurant is actually cheaper. If I just want a hamburger, there’s no need to buy a cow and raise it myself. Due to comparative advantage and economies of scale, consuming large amounts of food at a restaurant is actually less costly.
Therefore, some record systems are more prone to being affected simply because their pricing is too high or, in terms of the data they store and manage, their value isn't particularly significant. Carta helps many companies track and manage cap tables. How often do you check your cap table? While not frequently, it is extremely important and cannot afford errors. So, I would likely continue using Carta since their fees aren’t high, and it’s not a product used daily or with high frequency, so it doesn’t even enter the consideration for replacement.
Mike: I find the concept of vibe coding incredibly fascinating. As someone in the software industry, it feels like people might soon replace traditional tools entirely by coding based on 'vibes.' But then again, if I relied solely on vibe coding to complete a full day’s work and then ran it directly, that would be terrifying. There still needs to be some truly intelligent engineers backing it up. First, I have more important tasks for them to handle, and second, I think fully relying on this method is currently more harmful than beneficial for me. Yet, this is what we call the trend of substitution.
Undeniably, we’ve seen tremendous improvements in the scalability of internal software through methods like AI coding. Most such applications are highly configurable and customizable, achieving true scalability in our case. You can write software application snippets that run on top of the platform across various domains. Many customers are indeed doing this, but previously they would need to deploy a massive technical team to accomplish the same task.
Now, leveraging the capabilities of vibe coding, they can extend and highly customize applications for specific use cases. For instance, I may want to build a meeting room booking app for the Miami team, which has some unusual HR policies. Therefore, the app designed for 20 users needs to constantly interact with Workday and other systems. In the past, I certainly couldn’t afford the cost of having an internal IT team develop it due to prohibitively high expenses. But now, I might be able to build it easily. This app uses Workday’s global data and rules under the hood but provides me with a highly customized interface tailored to address very specific needs of the Miami front desk. It’s powerful but does not entirely replace human labor.
Speaking of poor Workday, I feel Aneel often becomes the subject of jokes in these conceptual examples. But in reality, it’s quite powerful. It actually makes Workday stickier and more valuable in the enterprise market because you can build all these customized applications on top of it. This is the power of AI, Vibe Coding, and creativity, making the underlying system better suited to my specific needs.
However, we must handle the balance between stability, rule-based processes, and high customization very carefully. You could even argue that examples like Openclaw aim to create highly personalized apps for individuals. Most people building these apps are not software developers; they’re just creating tools for personal use built on platforms like Gmail. Nonetheless, they still rely on Gmail to read and process emails—they’re simply solving problems unique to themselves. A few of these projects might evolve into full-fledged companies, but most are just addressing issues they personally encounter. This is truly powerful.
Alex: This is why I’m curious about the fairness of pricing caused by inconsistencies between front-end and back-end systems. Take Salesforce, for example—they charge by license. I believe our company has around 600 employees, so we probably purchased 600 Salesforce licenses. I’ve never logged into Salesforce, but I’d bet the company paid for me anyway. However, I sometimes do use its outputs because it essentially serves as our record system. I hesitate to overuse this term, but it indeed stores all our business relationships, and I am like part of a relational database table—for instance, I’m user ID 422.
Every time I interface with a company, it feels like matching another database, but in reality, we only want to pay for a single underlying database. It's as if we are now living in a world where the front-end and back-end are gradually separating — that’s just the reality. I believe Workday has devised an extremely clever pricing strategy, one that is powerful and feels equitable. The more employees you have, the more you pay. Why is this fair? Because GE obviously generates more profits than a 10-person company, so GE should logically pay more, yet this amount remains negligible for them. Their pricing sits in the most ideal sweet spot, and I think no one would object to it. They will generate substantial AI revenue in the future, but most importantly, their foundational pricing feels fair.
However, for products where the front-end and back-end have, to some extent, already separated, I don't know what constitutes a fair pricing model, nor am I sure how software pricing will evolve in the future. Clearly, if no one is willing to pay, and everyone starts coding their own solutions while competition ceases to exist, then the current pricing logic will remain unchanged. But you can imagine a future where people build on customized front-ends and directly pull data from the underlying database. Since all record systems have a database representing all layers of abstraction, could any of these categories face pricing pressure?
For me, if the front-end no longer equates to the back-end, it becomes more susceptible and vulnerable compared to when they were tightly intertwined. For example, QuickBooks is used by small businesses; there is no concept of 'seats,' as business owners log in directly. Thus, its front-end is, in some ways, also the back-end. Conversely, take Salesforce: while no one would completely abandon it, one could imagine a significant reduction in the number of 'seats' because the underlying back-end remains indispensable, but the demand for expensive front-ends diminishes. They won’t eliminate or modify the back-end but will optimize the cost of the front-end.
Mike: I’ve always believed that the fairness of pricing and customer perception are crucial. People need to understand why they are paying and feel that what they pay is somehow related to their actual usage. A company with 10,000 employees purchasing Workday may end up paying more than double, plus some volume discounts, because they are buying in bulk and their operations are twice as complex. They themselves consider this fair. The principle here seems reasonable: I’m willing to pay based on the number of employees for my HR system.
I believe the core issue with such matters is that it’s not just a database; it’s a database combined with a set of complex processes, which in my era was referred to as business logic. This business logic is far from trivial. Why do enterprises have this logic? Because companies operate as a collection of processes, and managers strive for standardization to achieve procedural efficiency. This ensures different teams work in the same way, allowing someone to manage, understand, and accurately track outputs.
For instance, if I own multiple car factories, I want to continuously track the total number of cars entering and exiting across them. The embedding of business logic in these scenarios essentially represents the moat and value proposition. Traditionally, the sales generated there are immense. The processes you create for your sales team hold significant value for you, and you see this as a fair way to charge. But the question arises: to what extent do your sales collaborators — those peripheral users rather than core users — truly need these processes, and to what extent do they not?
Let’s assume Salesforce Sales Cloud has an MCP server, and this MCP server does not directly access the database; it primarily handles your business processes and execution rules. The point of contention now is whether certain sales-related personnel in marketing or customer success roles really need those heavy processes, governance, controls, and rules. For example, if the system mandates that in Japan we only offer X service to clients and Y service to customers in this region, even their MCP server requires a dedicated 'seat.' Whether customers perceive this bundled pricing as fair remains an open question.
Exactly, the challenge lies in how this should be priced. Let me tell you, when discussing consumption-based pricing or pay-as-you-go models, outcome-based pricing makes sense in many areas, but I absolutely do not believe it will become the mainstream approach for software pricing, or apply universally to all SaaS software.
Because when you talk to customers, you’ll find they strongly dislike this approach; they truly resent asterisk-laden terms. It’s unrelated to the value they perceive in their input. For instance, my Splunk billing is volume-based, meaning if I double the volume of logs I send them, I pay more. I understand the logic, but logging is within my control. I can log more or less. I can ask my team: Why are you logging so much? It’s expensive, and are you really using these logs? I have control over the volume of data I submit. It’s similar to storage services like S3 or other typical models. Storing 1GB or 2GB isn’t an issue. The key point is that, as a customer, these aspects are relatively transferable and controllable.
But many examples of outcome-based or consumption-based pricing give customers little to no control, and they are non-refundable. Hence, the world of AI tokens and AI credits poses real challenges for customers. They will struggle to understand what these tokens or chips actually represent.
I can obtain 1GB of storage from AWS and deploy it to Azure, and I know how much they will charge me because the cost per GB is essentially fixed. But when I have these AI credits, I don't know if your credits are the same as someone else's. Vendors keep adding new features, and my users are utilizing those features, which consumes my credits. But I have no idea what they are using those credits for.
It's not that companies are actively choosing to use them; rather, vendors are adding features that make the software better, and these improvements seem to happen naturally. I could make my client's credit consumption increase tenfold overnight just by adding a bunch of features like generating great summaries for you. Clients would feel that they didn't ask for that.
So I think when discussing outcome-based usage billing, when you communicate with customers, they still prefer seat-based billing. This may be because they now understand this model better, and they have been burned by many pay-per-use models, which can cause bills to skyrocket unexpectedly, leaving them unsure how to control costs.
Yes, it takes some time to adapt. It will certainly appear in many categories. Our business at Atlassian covers a wide range of areas, which you could call usage-based pricing or literally pay-as-you-go. However, we try to focus on areas where, if a customer's business volume doubles, they receive twice the value while also paying twice the fee, and everything remains under their control. Many other pricing models are not within the customer’s control.
A final example of outcome-based pricing is that these outcomes are also dynamic. For instance, in customer service, I save you costs. You used to spend $20 on customer service, but with our tool, you only need to spend $10. In the first year, this is a great sales pitch. But by the second year, customers will say, 'I'm only spending $10 now, and I want to spend $5, otherwise you're not providing any value.' And the vendor responds, 'If you kick me out, you'll have to spend $20.' The customer then feels, 'But I’m only spending $10 now.' So the ability to save customers money every year is hard to measure in terms of outcomes, even though I am eliminating some tedious tasks.
Alex: I think this is true from a sales perspective as well. I founded two payment companies. I envy Workday a lot, and I often talk about Workday with my sales team because they have an excellent understanding of external situations. They know how much money they can make from GE. They would say GE has 330,000 employees, and maybe we charge them $5 per employee per month, and that's how much we can earn from that account.
If you are selling a software product, it is much easier to scale up a sales team this way because you know that company will pay us $3 million. In contrast, when we first started our company, we signed up 1,800 companies, and we had no idea how much money we could make from them. Ultimately, what really got the business going was Casper, the mattress company. You couldn’t predict it. You thought you landed a major client like Walmart, but things didn’t go smoothly at first. Instead, signing Casper resulted in astonishing performance.
Workday offers this two-way predictability, which is predictable for funding clients and also for the management team. You clearly know you should spend your time pursuing a client like GE instead of a company with 10 employees because GE is larger. But in the internet world, things are very chaotic. Stripe might earn more from a 10-person company than from GE. In that model, you can achieve a higher level of predictability.
But adopting outcome-based pricing or consumption-based pricing—while consumption-based pricing itself is not bad—if you cannot externally determine how much revenue an account (seats) can generate, scaling the sales and marketing teams becomes exponentially difficult.
Eric: As an entrepreneur, I’d like to revisit one point. In this era, could you share what this primarily means for you? And how has it changed your business?
Mike: Our perspective is that we are selling collaboration tools designed to solve human coordination problems. In many different fields, including service teams, broad business teams, human resources, finance, software teams, and more, various types of teams purchase different application suites and combinations through us. Fundamentally, these are all collaboration issues involving large amounts of text, which is highly advantageous for us. The most crucial part is what those people are doing.
The technological world tends to reinvent everything and believes this is the direction of the future. From a medium- to long-term perspective, this is usually correct. However, the challenge we continually face is that we have a large number of customers who operate in traditional ways. Currently, workflows within various apps are not particularly intelligent. They want to move toward the future but must also bring along a significant user base. Therefore, when we build AI functionalities, our first consideration is understanding what this technology is and how it can assist us. Second, we need to determine what foundational platform components to build to adapt to future changes because these technologies evolve at an incredibly rapid pace.
This is why we developed the AI Gateway, team collaboration graphs, and enterprise-level compliance and control functions. You must distinguish these from the features you build for customers within specific apps. So where do you place these functions? What exactly are they? A significant portion exists within existing workflows, aiming to help customers complete their current workflows faster, better, with higher quality, and more efficiently. These functions are often very mundane, akin to a 30-second animated GIF going viral on Platform X. But for customers, this is highly exciting because they can use it now, making their existing work methods better, and they think it's fantastic. In the AI world, I find it relatively simple, and it genuinely provides them with tremendous assistance today.
I often tell internal staff that providing just one example from the services domain is insufficient. You need to leverage their existing workflows, combine them with new applications, or examine new workflows to address issues. Thus, we must accomplish all of this. If you look at Jira as a typical example, within our HR and IT service management product suite, ticket summarization is underway. This is something we can do much better than ever before.
Internally, about four or five people might be handling the same ticket, attempting to resolve an issue. By the time the fourth person gets involved, there are already numerous attachments and conversation logs. Typically, they may need to spend 30 minutes reading everything to understand what happened so they can apply their expertise to solve the problem. Summarization isn’t merely feeding content into an LLM and extracting a summary. Context is powerful for the model, but the customer’s workflow hasn’t changed even slightly. It remains Alex asking Eric, 'Can you help me with this ticket?' When Eric steps in, he must load all the relevant information into his mind. This is like an existing workflow where we can enhance the customer experience using LLMs, and they love it, praising such features highly. However, these features often lack agent-like characteristics.
So we can say that for that service workflow, we need to incorporate agents at every step. Most people are handling a workflow and discover that a particular step frequently becomes a stumbling block, consuming a lot of time. Can we make this step faster? This is absolutely a function we must provide directly for the agent framework.
We have an excellent agent framework available for the entire team, integrating graphs and all the context you already possess. It’s straightforward and very affordable. Alternatively, you can bring your own agent framework. I believe most enterprises will operate three to five major agent platforms internally. They might say, 'I’ll use Agentforce for this' or 'I’ll use Gemini for that.' Bring that agent over, and we will integrate it into the workflow to run. We must be able to achieve this.
But you’re still entirely within the realm of existing workflows, performing a new, efficient task within them. Then you encounter individuals who ask what would happen if service tickets didn’t exist at all. So you are reimagining entire categories of software into new workflows. We must help customers bridge this gap because they typically don’t just have one service team; they have hundreds. If they operate hundreds of different service desks, they might say that 20 of them will work in a new way, but they must manage all of them. Therefore, we are trying to combine data from team collaboration graphs with this effort, driven by customer needs. This aspect is often overlooked. We are attempting to guide them toward a future five years from now, but our responsibility is to concretely lead them to futures one year, two years, and five years ahead.
Finally, I’d like to emphasize that we invest significant effort in design. This point is always overlooked in any discussion because there’s a lot of foundational design work in its operational mechanism. If we reflect on the mobile internet era, the first wave of applications essentially moved desktop or web content directly onto phones, and only later did we evolve new interaction patterns and experiences.
It’s not just about visual evolution but also about how we use these tools. What was push notification originally used for? Pull-to-refresh is a very obvious and straightforward example, representing a classic design pattern. The entire process involves figuring out how to make mobile and desktop work together and transition seamlessly between them. We face so many design challenges. The goal is to help ordinary users understand the content without needing to delve deeply. If AI doesn’t exist for them conceptually, it doesn’t matter—they want the results AI brings without understanding all the technical details. Our job is to hide these details and deliver the results directly to them, or make tasks more effective and efficient. In the tech field, sometimes we become overly obsessed with things like model quality.
It has almost become a cliche to say that the model is far ahead of the actual value delivered. The underutilized potential is enormous. Part of this actually lies in design and experience. How do I obtain this? Give people a chat box with unlimited capabilities, and all they will do is ask for a cold joke. It is like having infinite power but struggling to help them harness it. This is where we face significant challenges: how to integrate agents and their full capabilities into workflows and collaborative loops, enabling humans and agents to work together.
Alex: I love skeuomorphic design. The early web was shaped like having a few physical sheets of paper, which is why it was called a web page, akin to an 8.5x11-inch sheet. Later, when mobile came along, the initial idea was simply to create a miniature version of the web page. But it turned out that if you didn't limit yourself to skeuomorphic thinking but instead thought from first principles and fully utilized the device’s capabilities, you could create entirely new interaction methods. For instance, pull-to-refresh—a concept born with mobile. I was reflecting on this the other day. Have you tried Nano Banana 2?
Mike: Yes, I have.
Alex: Exactly. One of my colleagues just told me he used it to create an infographic for American tourists traveling to Japan, outlining key precautions. The one-shot generation effect was astonishing. But this raises a question: how do you edit these outputs? The current editing methods feel very skeuomorphic—still adhering to classic GUI logic, like clicking here and modifying something there. So I want to ask you, what do you think is the current industry's highest standard for editing AI-generated content? Or what should the ideal state be? Since you mentioned design, do you have any deep thoughts on this recently?
Mike: That is an excellent question. Let me take two steps back to answer it. First, building customer trust in the AI field is extremely difficult. During our user research, we found that people are not afraid of AI because of its capabilities but because it operates like a black box. For example, if your AI assistant instantly clears your inbox and sends out a dozen emails, the user’s first reaction is often, 'How do I know it did the right thing?' To build trust, AI must provide timely feedback on its intentions and request confirmation, but without being so frequent that it becomes annoying—otherwise, users may feel it’s easier to do it themselves. Therefore, the frequency of interactions and the trust mechanism itself represent a complete system design challenge.
Second, AI training and applications rely heavily on vast amounts of data and continuous iteration. Social media today is filled with hype about 'god-tier prompts,' as if uttering a Harry Potter spell would make AI automatically run a billion-dollar company for you—this is absurd. While one-click solutions are useful, in real-world business scenarios, you often need to repeatedly modify inputs and outputs. For example, if you ask a large language model (LLM) to write a paper and find the direction is wrong after generation, you’ll need to iterate by changing the input. But if you’ve ever tried iterating edits on images purely through chat, you’ll find the experience incredibly frustrating because it’s hard to precisely control the AI without it inadvertently altering other parts. This is fundamentally an input experience design issue.
Take our company’s product as an example. Our team collaboration graph contains massive organizational knowledge and high accuracy, even remembering code I wrote over a decade ago. But if the AI, knowing my computer science background, responds to all my questions using extremely technical jargon, it’s useless. If we clutter the interface with checkboxes, letting users decide things like 'whether to search the web' or 'whether to search organizational data,' it completely goes against the original design intent.
AI should possess proactive predictive capabilities. You can see some attempts at this in tools like Deep Research, but sometimes it’s frustrating. It’s like having 50 interns who can do a lot of work but ask you 50 questions every minute, leaving you answering questions all day and accomplishing nothing else.
Moreover, implementing workflow iterations in enterprise environments is much more challenging. Brainstorming, for example, usually requires team collaboration. In our Whiteboard and Confluence tools, you can introduce agents to assist. They excel at extracting knowledge from within the organization and generating excellent solutions. But if you let AI handle everything without human intervention, it will lose the team’s trust. The proper process should involve holding meetings to collect ideas, incorporating human intuition to filter useful components, and then feeding those insights into another intelligent loop. Because AI output quality is highly non-deterministic, the system must include a human intervention loop. Indeed, determining the appropriate level of human involvement is a major design challenge. Too many confirmation steps frustrate users, while too few erode trust.
We recently launched the Agent feature in Jira. When you assign tasks to an Agent, it executes them. But users often ask, 'What exactly is it doing right now?' If you show them thousands of underlying execution steps, they’ll feel overwhelmed with unnecessary details. So merely integrating AI into workflows presents countless design challenges.
Returning to the actual business approval process, for instance, when a transaction requires review by multiple departments such as security, accounting, finance, and sales, how can AI optimize this workflow? When assigning tasks to an Agent, it is crucial to carefully design the user experience: When should it return results? In what format should it deliver them? Can users inquire about progress while it is working?
We believe that allowing users to check progress at any time helps build trust in the short term. However, in the long run, if the Agent consistently performs well over twenty consecutive tasks, users will eventually choose to fully delegate authority. These are all fundamental foundational design and experience issues, rather than purely technical problems. The core challenge lies in enabling millions of daily App users to trust the product and eliminating the sense of it being a black box. Blindly promising 'I can do anything for you' will only leave users confused.
Alex: This indeed remains an unresolved question. Because the ideal interaction method of the future will clearly not be as simple as clicking a mouse like in the past, nor will it simply involve continuously re-entering prompts like now; instead, it will be more like a combination of both.
As long as tools serve humans, human involvement will always be indispensable. You need to allow users to intuitively understand the internal operational logic of the model, whether for the purpose of building trust or facilitating subsequent modifications and iterations. This is fundamentally a design issue, and I believe no one in the industry has yet perfectly solved it. We are still in the earliest stages of this exploration, with everyone searching for the optimal design solution to better adjust and edit one-click generated content.
Mike: Let me give an example of document creation. Knowledge workers have been accustomed to writing documents in a fixed pattern for decades: opening a blank page, typing a title, entering text, listing symbols, or inserting tables. Now, with our Create with Rovo feature, you can start with a prompt and let the AI generate content based on templates, or even conduct research across various dimensions and integrate the findings back into the document.
However, changing deeply ingrained user habits is extremely difficult. The interface now splits into two parts: the document entity on the left and the chat window on the right. Imagine a Word-like application without any toolbars, where formatting can only be done through dialogue. We need to encourage users: 'You can directly modify any text on the left, or enter commands on the right, such as adding a new section, researching additional materials, and appending them to the summary.'
When observing advanced users, we find they thoroughly enjoy this mode, skillfully switching between the two operations and grasping this entirely new paradigm. They can issue global commands spanning the entire document, such as 'Change all headings to blue,' which would be difficult to achieve with a single click in traditional editors. They can even request the AI to reassess and streamline the document from the perspective of a board member.
However, for ordinary business users, their first reaction is often confusion: 'So, I just type on the left?' This represents a profound paradigm shift. I suspect that, with the widespread adoption of AI tools, much like during the early days of mobile internet, this new interaction method will become very common within two to five years. It is similar to when people first encountered Excel, asking 'Where do I input paragraphs?' Now, everyone understands how Excel works.
The biggest challenge we face is how to naturally integrate all these powerful AI capabilities into an extremely minimalistic interface to assist people in truly leveraging the organization's knowledge to generate documents. I know this is entirely feasible in terms of underlying algorithms and mathematical logic, but guiding users to accept and master it through excellent experience design remains challenging and incredibly exciting. We need to spend significant time refining these experiences.
Eric: This is a very fitting topic to conclude with. Mike, thank you very much for joining our podcast; this was a fantastic discussion.
Mike: Alright, no problem, everyone. I hope these insights will be helpful to you all.
Editor/Stephen
