
a16z's latest interview: It's too early to say SaaS is dead; the biggest bottleneck for AI implementation is no longer model intelligence

a16z exclusive interview with Atlassian CEO: AI is not the end of SaaS, but a catalyst for industry differentiation. Software that handles complex real-world business processes will not disappear; instead, AI will empower them with significant growth. The biggest bottleneck for AI implementation currently is the trust issue humans have with AI. Future software competition will not only depend on model capabilities but also on the barriers of business logic and the game of pricing psychology

In the face of the public market's extreme panic over "AI destroying SaaS," a16z partner Alex Rampell believes that this concern stems from a detached static mindset. Core business processes that are truly embedded to handle real-world situations will not only survive but will instead experience a cash flow explosion.
On March 6, the well-known investment firm a16z held an in-depth discussion with Atlassian CEO Mike regarding the current public market's intense focus on the narrative of the "SaaS apocalypse."
Participants agreed that the current panic is somewhat detached from reality; AI is not the end of SaaS but rather a catalyst for accelerated industry differentiation. The future competition in software will not only depend on model capabilities but also on the barriers of business logic and the psychology of pricing.

SaaS Valuation Divergence: Who Will Go to Zero, and Who Will Experience Cash Flow Surges?
Current public market investors often lump all software companies together, but in reality, the impact of AI on different categories of SaaS is vastly different. Alex pointed out that current SaaS companies can be roughly divided into three categories, and the market does not differentiate their capabilities.
The first category is extremely dangerous "account and output-linked" enterprises, such as Zendesk. Alex said:
"Zendesk is the 'patient zero' here. If Zendesk customers now use Sierra, Decagon, or choose to develop their own solutions, the accounts they need might be zero."
For these types of companies, if they do not shift to outcome-based pricing and completely change their existing models, "that revenue stream will 100% go to zero."
The second category consists of core business systems with strong barriers, such as Workday. These systems also charge by account on the surface, but this is merely a "smart pricing strategy," with their true moat being decades of embedded implicit rules and "edge cases." Alex emphasized:
"Many software systems are actually a set of deterministic rules accumulated over decades of learning... What if that employee in Indiana leaves while on maternity leave? Unless you've personally encountered it, you wouldn't know these edge cases at all."
For these deeply embedded systems within enterprises, AI will not eliminate them; rather, it will provide significant incremental value.
"True core business systems, which are sticky, relied upon, and embedded with all edge cases, will thrive... When all of this truly happens, future cash flows will increase significantly, which shocks me." The third category consists of products in an intermediate state, such as Adobe. The AI era will reduce the demand for these products, but the situation is not as extreme as Zendesk, nor is it completely unaffected like Workday. The impact is somewhere in between.
Why do customers hate "result-based and token billing"?
With the popularity of AI, front-end applications and back-end databases are gradually separating, and software pricing models are facing severe challenges. There is a growing call in the market to shift to "consumption-based billing (Token/points)" or "result-based billing," but there are significant practical obstacles.
Mike pointed out the customers' resistance clearly:
"When you communicate with customers, you will find that they really hate this approach; they are very averse to the asterisk clauses."
He explained that traditional cloud storage billing is controllable, but the world of AI tokens is a black box for customers.
"Customers feel they don't understand what this token or chip you are giving me really is... I can make my customer's quota consume ten times overnight just by adding a bunch of features like generating great summaries for you. Customers feel that I didn't ask for that."
Moreover, billing based on results (such as cost savings) is a good sales pitch in the first year, but by the second year, customers will feel that the baseline has been lowered, making it difficult to continue measuring the incremental value provided by AI. Therefore, Mike concluded:
"When you communicate with customers, they still want to be billed per account. This may be because they now understand this model better, and they have been burned by many consumption-based billing models."
Vibe Coding cannot replace core processes
There is currently a prevailing "replacement theory" in the tech circle, suggesting that through AI programming (Vibe Coding), companies can write their own code to replace all traditional SaaS tools. But Mike bluntly stated that this idea is unrealistic.
Mike stated that the core of knowledge-based enterprises lies in coordinating thousands of input-restricted (such as legal and customer service approvals) and output-restricted (such as R&D and creative marketing) processes.
"I personally hate the term 'core business system' because it sounds like a static database... To me, business is a process-based system, not a record system."
The real change brought by AI programming is not to have companies rewrite a Workday from scratch, but to enable companies to build highly customized applications on top of these underlying giant systems at a very low cost. Mike mentioned:
"For example, I want an app for booking meeting rooms developed for the Miami team... In the past, I definitely couldn't afford it... but now I might be able to build it easily. This app uses the global data and rules from Workday at its core."
This actually makes the underlying SaaS giants "more sticky and valuable in the enterprise market."
The last ten kilometers of AI implementation: it's not about model IQ but trust design
When discussing the imaginative space for future products, the interview revealed the experiential gap that AI software must bridge before it can truly generate revenue. The capabilities of current models have far exceeded the actual delivered value, and the bottleneck lies in UI/UX design and human trust mechanisms.
Mike pointed out that introducing Agents into complex business approval flows presents the greatest challenge not in underlying computing power, but in how to eliminate the black box feeling. If AI instantly processes a dozen emails, the user's instinct is panic rather than gratitude.
“Blindly promising ‘I can do anything for you’ will only leave users feeling lost.”
The future of software interaction is undergoing an evolution from "skeuomorphic" to first principles. Taking document flow as an example, traditional typing and layout are being replaced by an AI collaboration model where "the document entity is on the left, and the chat window is on the right."
Although changing users' habits built over decades is highly challenging, this is 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 said:
“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 in our business.”
The original interview text is as follows:
Alex: From 1960 to 2022, the entire history of software has been about turning filing cabinets into databases. The first example is the SABRE system developed by IBM in collaboration with American Airlines in 1960. It replaced the previous paper reservation system managed by numerous secretaries and stored in safes, transferring this data into early databases. It’s worth noting that in those days, a 10MB hard drive could cost hundreds of millions of dollars. The development of electronic health records is similar; Massachusetts General Hospital developed one of the earliest systems, MUMPS. Likewise, Salesforce and the first CRM company established in 1987 are essentially about turning filing cabinets into databases.
This approach does have its benefits, but it hasn’t made the world significantly more efficient. Previously, if you wanted to find Eric's information, you would send someone to retrieve it from the HR department's filing cabinet. Now, although the data is all in Workday, you must appoint a Chief Information Security Officer to prevent system breaches, and IT personnel need to configure accounts (seats) for you in the single sign-on system. Efficiency is only evident when collaborating across regions; people can now work together and perform complex join queries on databases, which was much more difficult in the paper document era. But essentially, software from 1960 to 2022 remains static because filing cabinets themselves cannot think.
And now, the coolest thing happening in the AI field is that filing cabinets can work by themselves. For example, QuickBooks can now actually complete a task independently, no longer relying solely on humans to retrieve files from the system, marking a complete farewell to the era of 16th-century old-fashioned accounting departments rummaging through filing cabinets for information, which is very interesting
Erik: This is indeed a very good entry point. Everyone is now discussing the "SaaS apocalypse" or even the "SaaS disaster," which clearly refers to what is happening in the public market. Many people have different views on its significant implications. I would like to hear how you both interpret it. What exactly is happening? More importantly, how should we understand all of this? Why does everyone feel so fearful about it?
Mike: I believe the whole world is currently trying to figure out how to rate or value software businesses in this highly disruptive phase. Everyone has their sharp insights into what the future might look like. Different viewpoints depict two extreme futures: either very good or very bad for the entire software industry, certain specific companies, or categories. There is no doubt that the current level of risk has increased.
From an investor's perspective, SaaS used to be a very stable category, but now, due to increased risks, people are choosing to step back and observe. As I often say, investors are not necessarily trying to calculate all of a company's historical profits through discounted cash flow models; they are actually speculating on what other investors will do, or in other words, they are betting on the future trajectory as seen by others.
The current panic is somewhat detached from reality. People are always thinking, "If AI can achieve a certain function in two or three years, what does that mean?" I believe this concern stems from a very static way of thinking, as if people will not adapt, the world will not change, and only the technology of AI is evolving while everything else remains static. So the current situation is quite interesting: companies like ours are still performing excellently, having delivered outstanding results for three consecutive quarters. Although we are not here to defend the entire software industry, we feel very optimistic about the current opportunities in our own business, as evidenced by the data and results we continuously showcase.
Of course, this does not mean we do not need to adapt. We are changing our ways of working thoroughly and rapidly, just as we have in the past few years. Many people mistakenly believe that we cannot change or respond, which is clearly incorrect, although there are indeed many strategic variables ahead. The reality is that not every SaaS company will thrive in the next decade. Just like the transition from the Windows era to the internet era, a large number of companies failed to successfully transform to the cloud; it is impossible for all 100 SaaS companies to survive and continue to grow. Some also believe that software will, to some extent, become obsolete or ultimately reduce to just a cash income stream. But I can speak for our company: this is the best thing that has happened in our business. We are in a world of knowledge, equipped with tools to explore and act using that knowledge to accomplish the tasks for which clients hire us. This is logically very perfect, but we must prove it in practice during the transformation process, as keeping the market patient is quite difficult.
Erik: Alex, what about you? What is your reaction to what has happened recently, or how do you understand what is going on?
Alex: I hope my judgment is correct in the long run, because everything happening right now is just too crazy. A few weeks ago, I tweeted about this, and my preliminary observation is that there are roughly three different types of SaaS companies in the market, but the public market cannot distinguish between them. One type of company ties account (seats) permissions to output, and the accounts (seats) are occupied by actual users of the system, which is akin to the earlier metaphor of the filing cabinet.
Before diving deeper, I want to take a step back and answer your question. Dan Ariely wrote a fantastic book called "Predictably Irrational." I used to send this book to all the product managers in the company, encouraging them to learn from it to figure out how we should charge users. There’s a classic example in the book: imagine that at midnight, you are locked out of your apartment, and you call a locksmith. He arrives in one minute, spends 30 seconds helping you unlock the door, and then charges you $500. You would definitely think, “He only worked for 90 seconds and charged me $500? What the hell!” So you would leave him a one-star review on Yelp, not tip him, and might even dispute the charge with your credit card company.
Now imagine another parallel scenario: the locksmith arrives and spends 9 hours trying to unlock the door. He goes back to the office for more tools and struggles until 9:30 AM, finally getting you inside. At this point, you would be extremely grateful for the nine and a half hours he spent helping you unlock the door, tipping him $200 and leaving a five-star review on Yelp.
This example basically illustrates that humans, to some extent, are able and willing to pay for “incompetence.” Many pricing strategies actually revolve around psychological fairness. We feel it is fair to pay more to the person who struggled all night, even if he is completely incompetent; whereas we feel extremely angry at the highly capable peer who charges too much. Logically, this makes no sense, but emotionally, it feels very fair.
If you think back to how we evolved into the SaaS model, such as charging per user monthly, when you provide something for free, the digital configuration costs are often nearly zero. This is not true for everything; people just feel this is fair. For example, if you have 500 accounts (seats), the fee you pay is naturally more than if you only have one account (seat), even though the backend mechanisms are quite similar.
Therefore, I believe SaaS companies can be roughly divided into three categories. The first category is those where you originally needed accounts (seats) to produce certain work elements, but now you no longer do. Zendesk is the “patient zero” here. If Zendesk customers now use Sierra, Decagon, or choose to develop their own solutions, the number of accounts (seats) they need might be zero. Therefore, for Zendesk, we are talking about the present value of future cash flows. They are in danger because if they only charge per account (seat) for the existing product monthly and never make any changes to the code or pricing, that revenue stream will 100% go to zero On the other hand, if they switch to outcome-based pricing and abandon the original model, revenue could triple or quadruple. This is still constrained by the fairness principle and predictable irrationality. Products like Zendesk may go up or down, but unless something changes, the default path is towards zero.
The second category is pricing based on accounts (seats), which feels fair, but accounts (seats) are not tied to any specific outcome. For example, Workday has a great pricing model where I charge you per person per month because you have 340,000 employees. Why do I charge? I don’t know, it just feels fair. But those employees at GE are not using Workday to produce results. I think Workday is quite good, and this actually involves what you can do with AI tools. For instance, when GE is hiring employees, HR must check documents in Workday and call those three previous companies for background checks to ensure the candidate's resume is genuine. But AI tools can completely handle the calling part, provided you are in the core business system. Currently, the IT sector has dropped 45%, but no one is abandoning QuickBooks. These two pillars are account (seats) billing linked to some workload, and accounts (seats) are just a clever pricing strategy.
The third category is products that are in a middle state, like Adobe. You may need more or fewer accounts (seats), but the situation is neither as extreme as Zendesk nor as disconnected as Workday.
Beyond these situations, there is a current belief that AI can write all code, which I, as a senior software developer, find absurd. I want to quote the comparative advantage theory proposed by economist David Ricardo in 1817. For example, you can grow food or weld aluminum yourself, but even these simple examples are inappropriate. It’s like I have a comparative advantage in recording a podcast with you; I can earn more doing this, and even if I might be more productive than a plumber, I should focus on podcasting.
More importantly, there are those hidden edge cases underneath. In theory, I could automate some Workday processes through AI, but what if that employee in Indiana leaves while on maternity leave? Unless you have personally encountered it, you would have no way of knowing these edge cases.
Many software systems are actually a set of deterministic rules accumulated over decades of learning, which are not publicly available and are embedded within; you cannot directly replicate them and need to reproduce them through experience. If this is a very simple sub-task with no edge cases, AI can indeed handle it.
But I believe the truly core business systems, which are sticky, relied upon by people, and built with all edge cases, will thrive. They will start to add functionalities for AI to perform tasks, such as asking you if you need to conduct background checks or collect overdue receivables. You don’t need to hire humans; you can hire your software to complete these tasks When all of this truly happens, future cash flows will grow significantly, which shocks me.
Many public market investors cannot distinguish between these different categories; they are very excited about AI but do not realize that AI must be deployed through software as a core business system. I think now is a fascinating moment for everyone to return to the first principles of the essence of business.
Mike: Personally, I really dislike the term "core business system" because it sounds like a static database where you put things in and take them out. This view of business as a filing cabinet archiving system is rooted in a very industrialized era, which is completely different from the business models of the pre-industrial era.
I understand why this term exists, but it feels a bit like we are still using the physical floppy disk icon as the save button. Kids have never seen a physical floppy disk, yet they keep using this icon. I question this because, for me, business is a set of process-based systems, not a record-keeping system.
Everything Alex just said is completely correct; there are processes in businesses such as background checks or other similar processes. The core of knowledge-based business is how you can coordinate a series of processes to happen as cheaply, efficiently, and quickly as possible. In a knowledge economy business, I have thousands of employees who walk into the building every day with their brains and leave with their brains at the end of the day. I have no atomic assets, drill bits, or steel, not even a filing cabinet. Everything I do is about coordinating those sets of processes, and I think most modern businesses are likely the same.
What does this have to do with Alex's comments? I think it is completely correct. We have different types of processes in business, and I like to call them input-constrained and output-constrained processes. Take Zendesk's customer service as an example; that is input-constrained. Your customers will ask a certain number of questions, and the speed at which you handle those questions relates to the efficiency, cost, speed, and quality of running that queue. If you handle them 10 times faster, you will not get 10 times the number of questions because the number of customers is fixed. The challenge you face is how to reduce their questions or process them faster. In fact, many processes in businesses are input-constrained.
I always use our legal team as an example; their job is not to proactively create legal work but to respond to and handle that work. For instance, how many lease agreements do we have? How many NDA confidentiality agreements? How many standard contracts? It’s like a fixed total amount. To complete that work, I am trying to be as efficient as possible, which falls under input-constrained work with a complete execution process. But then I also face some output-constrained work, such as creativity, marketing, or even software development and technology, where theoretically I can complete an infinite number of tasks.
My bottleneck lies in my creativity, or rather, how many things I can think of to do and how much value I can deliver to customers. This is where I gain efficiency improvements and produce more content, rather than just limiting input within the scope to make the company profitable
The statement about Indiana is completely correct, as some processes are inevitably constrained by external rules, such as legal, governance, and compliance requirements. In Indiana, I must follow certain specific procedures for employees, which are both the way I want the business to operate and the way it must operate; a business is essentially a collection of all these processes combined. From a certain perspective, we have recording systems and execution systems. My thought is that the actual operation of most businesses is not like this, but this is how we generally understand it.
Alex: I completely agree, I think this is a fantastic framework. I really like Intuit, like TurboTax, since tax laws are publicly published, you can totally download all the rules; it has a high degree of certainty, and you can handle tax filing and those messy download folders at the same time. In this case, all the rules are transparent, but I think it’s actually quite rare for edge cases to be publicly released.
Businesses are valuable, and theoretically, there are many knowledge economy-oriented businesses whose assets go home in the elevator every night, but these businesses do have core value. For example, does McKinsey still have value after all its employees leave? Because it is a business that produces results based on the knowledge economy, it is deeply tied to the workforce rather than physical products. Nevertheless, they may have a top-secret internal manual that specifies how to operate, how to hire and fire employees, and how to deliver results for clients. I have never seen such a manual, and because I have never seen it, I cannot replicate it, and it may have been established and continued for over a hundred years.
What are the products of non-digital, non-software companies? Their products may be the accumulation of knowledge over centuries or decades. I love going to Japan, where you can see some noodle shops that have been open since around 1587; being able to last that long must have some merit. This is a culture, knowledge, and skill set that has been accumulated over a long time, and of course, there will be a recipe list for making noodles. Making noodles might be slightly simpler without so many edge cases, but there can still be extreme situations. For example, what would you do if you ran out of flour? How did the noodle shop survive the great flour famine in 1623? They must have taken certain measures, and these experiences are accumulated in that secret book of know-how, rather than replicating what has already been made public.
Mike: This is what I find so fascinating; it forces us to rethink our business. Is Intuit really filling out the tax laws for you? Or has Intuit reached a level of understanding of tax laws that no one else can match? The core value they provide is helping you process life data and clarify your understanding, asking you the right questions. From this perspective, Intuit is now more like a McKinsey. This is their special ability, how to ask you the right questions to fill out tax forms, rather than just filling out the forms
Now all companies have to reassess themselves. Perhaps I have 50 processes internally that I once thought were unique core secrets, but in reality, only 20 of them are truly core. I now have to seriously consider which of these processes are indeed unique and which are not, because we have never needed to think this way before.
Alex: I think this is somewhat about how to balance things. Whether it is worth doing it myself, if you use third-party tools, it is not an untouchable red line but more like an independent variable. Should I write code myself using Claude Code? If a company charges excessively for software that could even lead to the failure of my business, and developing it myself can meet 99% of the needs and cover costs, then writing code myself makes sense. But if that software only costs one dollar a year, then developing it myself doesn't make sense.
Moreover, not all record systems have equal value. I tend to view record systems as atomic units of a business. For example, a calendar is a record system for time, and ERP is a record system for inventory; you have all these different dimensions of record systems. I once gave an example to others: I have an office in Miami that I don't visit often, and it has a meeting room registration system like Google Calendar. Am I willing to spend effort changing that system? Obviously, yes, because I only go to that office once a year; who cares if it is stable?
In contrast, some systems can directly affect my income, and they are not expensive in themselves. Do I really need to grow my own food to eat? Using an agricultural metaphor, eating at a restaurant is actually much cheaper. If I just want a hamburger, there is no need to buy a cow, raise it, and wait. Due to comparative advantage and economies of scale, consuming a large amount of food at a restaurant is actually cheaper.
So there are some record systems that are more susceptible to being affected, simply because their pricing is too high, or the value of the content they store and record is not that high. Carta tracks and manages equity structures for many companies; how often do you check the equity structure? Although not very frequently, it is very important and absolutely cannot be messed up. So I am likely to continue using Carta because their fees are not high, and it is not a product used frequently in daily operations, so it is not even on the consideration dimension for replacement.
Mike: I find vibe coding fascinating. As someone in the software community, it feels like people will be able to replace all those traditional tools by coding based on vibes. But then I think, if I rely on vibes to code and get through a whole day's work and then run it, that would be terrifying. There still needs to be some really smart engineers backing it up. First, I have other more important things for them to do; second, I think relying entirely on this method currently does more harm than good for me. However, this is what is called the trend of substitution theory
It is undeniable that we have seen significant improvements in software scalability internally through methods such as AI coding. Most of these applications have high configurability and customizability, and in our case, they have even achieved true scalability. You can write software application snippets that run on the platform and cover various different fields, and many customers do just that, but previously they needed to invest in a large technical team to accomplish this.
Now, by leveraging the capabilities of vibe code, they can expand and highly customize applications for specific use cases. For example, I want a conference room booking app developed for the Miami team. Due to some strange HR policies in Miami, that app for 20 people needs to constantly check Workday and various other systems. In the past, I certainly couldn't afford the cost of having the internal team invest IT resources to build it, as the bill would be too high, but now I might be able to build it easily. This app uses Workday's global data and rules at its core, but it gives me a very customized interface to complete some specific tasks tailored to the needs of the Miami front desk. This is very powerful, but it cannot completely replace human work.
Poor Workday, I feel like Aneel is often the butt of jokes in these conceptual examples. But it is actually very powerful; it makes Workday stickier and more valuable in the enterprise market because you can build all these custom applications based on it. This is the power of AI, Vibe Coding, and creativity, making the underlying system more aligned with my specific needs.
However, we must be very cautious in balancing stability, rule processes, and high customization. You could even argue that examples like openclaw are designed to create very personalized apps for individuals. Most of the people building these applications are not software developers; they are just building apps or other small tools for their own use on top of Gmail. But they are still using Gmail as a track; they still need to go to Gmail to read and process emails, they just built some specific things for themselves to solve problems that only they would encounter. Some of these projects may evolve into companies, but most are just addressing things they need to handle themselves, which is indeed very powerful.
Alex: That’s why I’m curious about the pricing fairness brought by inconsistencies between the front end and back end. Take Salesforce as an example; they charge per license. I think our company has about 600 people, and we probably bought 600 Salesforce licenses. I actually have never logged into Salesforce, but I bet the company has paid for me, yet I do sometimes use its outputs because it is actually our record system. I don’t want to overuse the term, but it does store all our business relationships, and I am like a part of a relational database table, for example, I am user ID 422
Every time I connect with a company, it feels like matching in another database, but we actually just want to pay for one underlying database. Now it feels like we are in a world where the front end and back end are gradually separating, and that's the reality. I think Workday has come up with a very clever pricing strategy, which is a powerful and fair pricing paradigm. The more employees you have, the more you pay; why is that fair? Because GE's profits are obviously much higher than those of a company with 10 people, and GE should pay more for that, while that amount is still just a drop in the bucket for them. Its pricing is completely in the ideal golden range, and I believe no one would disagree with that. They will add a lot of AI revenue in the future, but most importantly, their base pricing feels very fair.
However, for these products where the front end and back end have somewhat separated, I don't know what a fair pricing model is and I'm not sure how software pricing will change in the future. It’s obvious that if no one is willing to buy in, and everyone starts writing their own code with no competition, then the pricing logic will remain unchanged, but you can imagine a future where people are building things on customized front ends and directly reading data from the underlying databases. Because all record systems have a database that represents all underlying abstraction layers, will any of these categories face price pressure?
For me, if the front end is no longer equivalent to the back end, it will face greater susceptibility and impact than when they are tightly intertwined. For example, QuickBooks is used by small businesses that do not have the concept of accounts (seats); business owners can log in directly to QuickBooks, so its front end is somewhat the same as the back end. In contrast, with Salesforce, you can imagine that while no one will completely abandon it, they may significantly reduce the number of accounts (seats) because the underlying back end is still essential, but the demand for the expensive front end has decreased. They will not eliminate or make any changes to the back end, but will only optimize the cost of the front end.
Mike: I have always believed that the fairness of pricing and customer perception are very important; people need to understand why they are paying and feel that the fees they pay are somewhat related to their actual usage. A company with 10,000 employees is likely to pay more than twice the amount when purchasing Workday, plus some bulk discounts, because they are buying in larger quantities and their business has twice the complexity, and they themselves think this is fair. The reasonable principle here seems to be: I am willing to pay for my HR system based on the number of employees.
I think the core issue here is that it is not just a database; it is a database plus a set of complex processes, which we used to call business logic in my growing-up years. These business logics are by no means trivial; why do companies have these logics? Because companies themselves operate as a collection of processes, and managers pursue standardization to achieve some degree of process flow. This is to allow different teams to work in the same way so that someone can manage, understand them, and accurately track outputs
Just like if I owned a bunch of car factories, I would want to continuously track the total number of cars coming in and out of them. The place where the business logic is embedded is, to some extent, the moat and the value. In traditional terms, the sales volume there is actually very large, and the processes you set for the sales team are extremely valuable to you, and you would think this is a fair way to charge. But the question is, to what extent do your sales collaboration team, those collaborators rather than core users, actually need these processes and to what extent do they not?
I assume that Salesforce Sales Cloud has an MCP server, which does not directly access the database; it mainly involves your business processes and the rules during execution. The current point of contention is whether certain sales-related personnel in the marketing department or customer success functions need those heavy processes, governance, controls, and rules. For example, the system stipulates that we only provide service X to customers in Japan and service Y to customers in that region, and even their MCP server needs a dedicated account (seats). As for whether customers think this bundled charging is fair, that is another unresolved question.
Indeed, the challenge lies in how to price this. I want to tell you, when discussing consumption-based pricing or pay-as-you-go pricing, outcome-based pricing is reasonable in many areas, but I absolutely do not think it will become the mainstream software pricing method, nor is it suitable for all SaaS software.
Because when you communicate with customers, you will find that they really dislike this method; they are very averse to asterisks and additional terms. This has nothing to do with the value they believe they are contributing. For example, I use a pay-per-use model with Splunk; if the amount of logs I send them doubles, I have to pay more. I understand this logic, but the logging is determined by me. I can log more or log less. I can tell my team, why are you logging so much? It's too expensive, and are you really using these logs? I can control the amount of data I contribute. This is similar to the model of storage and S3 or other typical services. It’s fine whether I store 1GB or 2GB. The problem is that these are relatively transferable and controllable for me as a customer.
However, many examples given about outcome-based or consumption-based pricing are things that I, as a customer, cannot control, and they are also non-redeemable. So the world of AI Tokens and the world of AI credits are really difficult for customers. They feel confused about what this token or chip you are giving me actually is.
I can get 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 basically fixed. But when I have these AI quotas, I don’t know if your quota is the same as someone else's. Vendors are constantly adding new features, and my users are using these features, thus consuming my quotas. But I don’t know what they are doing with these quotas
This is not a choice made by the company to use them actively, but rather the suppliers are adding features that make the software better, and these improvements seem to happen naturally. I can make my clients' usage limits increase tenfold overnight just by adding a bunch of features like generating great summaries for you. Clients would feel that I didn't ask them to do that.
So I think when talking about outcome-based billing, when you communicate with clients, they still want to be billed by account (seats). This may be because they now understand this model better, and they have been burned by many pay-as-you-go models that lead to significant spikes in billing amounts, and they wouldn't know how to control it.
Yes, it takes some time to adapt. It will definitely appear in many categories. Our business at Atlassian covers many areas, which you could call usage-based pricing, or literally pay-as-you-go billing. But we try to focus on areas where clients can get double the value while paying double the cost when their business volume doubles, and all of this is under their control. Many other pricing models are not within the client's control.
The last 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, and with our tool, you only need to spend $10. In the first year, this is a great sales pitch. But by the second year, the client will say I only spent $10, and now I want to spend $5, otherwise, you haven't provided any value. And the supplier responds that if you kick me out, you will have to spend $20. The client will feel that they are only spending $10 now. So the ability to save clients money from an outcome perspective is hard to measure, even if I am eliminating some tedious tasks.
Alex: I think this is also true from a sales perspective. I have founded two payment companies. I really envy Workday, and I often talk about Workday with my sales team because they are well aware of external situations. They know how much they can earn from GE. They would say GE has 330,000 employees, and maybe we charge them $5 per employee each month, which is how much we can earn from that account.
If you are selling a software product, scaling up the sales team this way is much easier. Because you know that company will pay us $3 million. In contrast, when we first started the company, we signed contracts with 1,800 companies, and we had no idea how much we could earn from them. The company that really got the business going was Casper, the mattress company. You can't predict it at all. You think you have landed a big client like Walmart, but the initial progress is not smooth, and instead, after signing Casper, the performance is amazing.
Workday has this two-way predictability, which is predictable for the clients who fund it and also predictable for the management team. You can clearly determine that you should spend time trying to sign clients like GE rather than signing a company with 10 employees because GE is larger. But in the internet world, things are very crazy; the money Stripe earns from a 10-person company might be more than what it earns from GE In that model, you can achieve a higher level of predictability.
However, adopting outcome-based pricing or consumption-based pricing, while consumption-based pricing itself is not bad, becomes exponentially difficult to scale the sales and marketing team if you cannot understand externally how much a single account (seats) can earn.
Eric: As an entrepreneur, one point I want to return to is, in this era, can you share what the main manifestation of this is for you? And how has it changed your business?
Mike: Our view is that we are selling collaborative tools that solve human collaboration problems. In many different areas, including service teams, broad business teams, human resources, finance, software teams, etc., many different types of teams purchase different application suites and combinations through us. Fundamentally, these are all collaboration problems involving a lot of text. This is very beneficial for us. What those people are doing is the most important part.
The tech world often tends to reshape everything and believes this is the direction of the future. From a medium to long-term perspective, this is often correct. But the challenge we always face is that we have a large number of customers working in existing ways, and the workflows in various apps today are not very intelligent. They want to move towards the future, but at the same time, they must engage a large number of users. So when we build AI capabilities, the first consideration is that we need to understand what this technology is and how it can help us. Secondly, we need to build what kind of foundational platform components to respond to future changes, as the pace of development of these technologies is indeed very fast.
This is the intention behind our development of AI Gateway, team collaboration maps, and enterprise-level compliance and control features. You must distinguish these from the features you build for customers in specific apps. So where do you place these features? What exactly are these features? A large part of them exists within the existing workflows, aimed at helping customers complete their current workflows faster, better, with higher quality, and more efficiently. These features are often very mundane, just like that 30-second animated GIF going viral on platform X. But this is very exciting for customers because they can use it now, and their existing ways of working become better; they feel it's fantastic. In the AI world, I actually find that quite simple, and it can indeed bring them tremendous help today.
I often tell internal staff that just giving a service example is not enough; you need to leverage their existing workflows, combine new applications, or look at new workflows to address issues. So we must accomplish all of this. If you look at Jira as a typical example, in our HR and IT service management product service collection, work order summaries are being conducted. This is something we can do much better than ever before.
Internally, there are probably four or five people handling the same work order, trying to resolve an issue. By the time the fourth person gets involved, there are already a lot of attachments and conversation records. Typically, they might need to spend 30 minutes reading through everything to understand what has happened in order to apply their expertise to solve the problem Summarizing is not just about simply inputting content into an LLM and getting a summary. Context is very powerful for the model, but the customer's workflow hasn't changed even a little bit. It’s still Alex asking Eric if he can help him with this work order. Eric comes over and must first load all the relevant information in his brain. It’s like an existing workflow where we can use LLM to enhance the customer experience, and they love it, praising such features. But these features often lack agent characteristics.
So we can say that for that service workflow, we need to incorporate agents at various stages. Most people are handling a workflow and find that this step often trips them up, consuming a lot of time. Can we make this step faster? This is definitely a function we must personally provide for the agent framework.
We have a fantastic agent framework available for the entire team, combining graphs and all the context you already have. It’s very simple and affordable. Or you can bring your own agent framework. I believe most enterprises run three to five large agent platforms internally. They might say I use Agentforce for this, or I use Gemini for that. Bring that agent over, and we will integrate it into the workflow to get it running. We must be able to do this.
But you are still completely within the existing workflow world, just executing a new efficient task within the current workflow. Then you will encounter people who ask what if the service work order didn’t exist at all? So you are rethinking an entire category of software into a new workflow. We must help customers bridge this gap because they often don’t just have one service team; they have hundreds. If they are running hundreds of different service desks, they might say these 20 will work in new ways, but they have to manage all of them. So we are trying to combine the data from the team collaboration graph with this, and it’s from a customer-driven perspective. This is often overlooked, and we are trying to lead them into the future five years from now, but our responsibility is to realistically guide them into the future one year, two years, and five years from now.
Finally, I want to say that we have invested a lot of effort in design. This aspect is always overlooked in any conversation because there is a lot of foundational design work to be done in its operational mechanism. Looking back at the mobile internet era, the first batch of applications basically just moved content from the desktop or web directly to mobile, and then we evolved new interaction modes and experiences.
It’s not just an evolution at the visual level, but also how we use these things. What were push notifications originally used for? Pull-to-refresh is a very obvious and simple example; it’s a classic design pattern. The whole process is about how to make mobile and desktop work together and how to switch back and forth. We have so many design challenges to solve. This is actually about helping ordinary users understand the content. They don’t want to delve into it; if AI doesn’t exist for them, it doesn’t matter. What they want is the results brought by AI without needing to understand all the technical details Our job is to hide these details, directly deliver the results to them, or make tasks more effective and efficient. In the tech field, sometimes we become too obsessed with things like model quality.
Now saying that models are far ahead of the actual delivered value has almost become a cliché. The untapped potential is so immense. Part of this actually lies in design and experience. How do I achieve this? Give people a chat box with infinite capabilities, and they will just ask for a cold joke. It's like having infinite power, but it's hard to help them leverage that power. This is also where we face a huge challenge: how to integrate agents and all their capabilities into workflows and collaborative cycles, and enable humans to work alongside agents.
Alex: I love skeuomorphic design. The early web forms were like having a few sheets of physical paper, which is why it was called a web page, just like an 8.5x11 inch sheet of paper. Later, when it came to mobile, the initial idea was just to create a miniature version of the web page. But it turns out that if you don't limit yourself to skeuomorphic thinking and instead think based on first principles and fully utilize the device's capabilities, you can create entirely new ways of interaction. For example, pull-to-refresh is a new concept that emerged with mobile. I was pondering this the other day. Have you tried Nano Banana 2?
Mike: I have.
Alex: Exactly. A colleague of mine just told me that he used it to create an infographic about tips for American tourists traveling to Japan. The one-shot generation effect is simply amazing. But this raises a question: how do you edit these outputs? The current editing method feels very skeuomorphic, still following that classic GUI operation logic, like clicking here and modifying there. So I want to ask you, what do you think the highest standard in the industry is for editing AI-generated content? Or what should the ideal state look like? Since you mentioned design, what deep thoughts have you had in this area recently?
Mike: That's a fantastic question, and I want to take a step back to answer it. First, building customer trust in the AI field is very difficult. In our user research, we found that people are afraid of AI not because of how powerful it is, but because it operates like a black box. For example, if your AI assistant instantly cleans up your inbox and sends out a dozen emails, the user's first reaction is often, "How do I know it did it right?" To gain trust, AI must provide timely feedback on its intentions and request confirmation from users, but it also can't be so frequent that it becomes annoying, or users will feel it's better to do it themselves. So the interaction frequency and trust mechanism itself is a complete system design problem.
Secondly, AI training and application rely on a large amount of data and continuous iteration. Right now, social media is flooded with hype about god-level prompts, as if reciting a Harry Potter spell can automatically help you run a billion-dollar company, which is absurd One-click solutions are certainly useful, but in real business scenarios, you often need to continuously modify inputs and outputs. For example, if you ask a large language model (LLM) to write a paper and then realize the direction is wrong, you need to iterate by changing the input. However, if you've ever tried to iteratively edit images purely through chat, you would find the experience very frustrating because it's hard to precisely control the AI from making unintended changes to other parts. This is essentially an experience design issue related to input.
Taking our company's product as an example, our team collaboration map has a vast amount of organizational knowledge and extremely high accuracy, even remembering code I wrote over a decade ago. But if the AI automatically responds to all my questions using extremely technical language just because it knows I have a computer science background, that is actually unhelpful. If we set up a bunch of checkboxes on the interface for users to decide "whether to search the web" or "whether to search organizational data," that would completely contradict the original design intent.
AI should have the ability to proactively anticipate. You can see some attempts at this in tools like Deep Research, but it can also be quite frustrating at times. It's like having 50 interns under you; while they can do a lot of work, they ask you 50 questions every minute, leaving you unable to accomplish anything all day, just answering questions.
Moreover, implementing workflow iterations in a corporate environment is much more challenging. For instance, brainstorming usually requires team collaboration. In our Whiteboard and Confluence, you can introduce agents to assist. They are very good at extracting knowledge from within the organization and generating excellent proposals. However, if you let the AI handle everything without any human intervention, you will lose the trust of the team. The normal process should be to first hold a meeting to gather ideas, incorporate human intuition to filter out useful parts, and then feed this feedback into another intelligent loop. Because the quality of AI's output has a strong degree of uncertainty, the system must include a human intervention loop. Indeed, how to grasp the degree of this human intervention is a significant design challenge. Too many steps for confirmation can be frustrating, while too few will lose user trust.
We just launched the Agent feature in Jira. When you assign a task to the Agent, it will execute it. But users often ask, "What is it doing right now?" If you show them thousands of underlying execution steps, they will feel you are just overwhelming them with useless information. Therefore, simply introducing AI into the workflow presents a massive design challenge.
Returning to the actual business approval process, for example, if a transaction needs to be reviewed by multiple departments such as security, accounting, finance, and sales, how would you optimize this workflow with AI? When you assign a task to the Agent, you need to be very careful in designing the user experience: when does it return results? In what manner does it return them? Can users proactively 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 this Agent successfully completes tasks twenty times in a row, users will ultimately choose to fully delegate authority These are all fundamental design and experience issues, rather than purely technical problems. The core challenge lies in how to instill trust in the product among millions of users who use the app daily and eliminate that sense of a black box. Blindly promising "I can do anything for you" will only leave users feeling lost.
Alex: This is indeed still an unresolved issue. Because the ideal interaction method in the future clearly won't be as simple as just clicking a mouse like in the past, nor will it be merely about continuously re-entering prompts as it is now; it will be more like a combination of both.
As long as tools serve humanity, human participation is indispensable. You need to enable users to intuitively and deeply understand the internal logic of the model's operations, whether for the purpose of building trust or for facilitating subsequent modifications and iterations. This is essentially a design problem, and I believe no one in the industry has perfectly solved it yet. We are still in the very early stages of this exploration process, and everyone is searching for the optimal design solutions for how to better adjust and edit the content generated with one click.
Mike: I want to give an example of document writing. Knowledge workers have been accustomed to writing documents in a fixed pattern for decades: opening a blank page, entering a title, typing, listing bullet points, or inserting tables. Now we have launched the Create with Rovo feature, where you can start from a prompt and let the AI generate content based on a template, even allowing it to research various dimensions of information and bring it back together.
But changing users' deeply ingrained habits is very difficult. Now the interface has become two parts: the left side is the document entity, and the right side is the chat window. Imagine this as a Word document without any toolbars, where you can only format through conversation. We need to encourage users: "You can directly modify any text on the left, or you can input commands on the right, such as asking it to add a new chapter or research other materials and supplement them to the summary."
When we observe those advanced users, we find that they really enjoy this mode; they can skillfully switch back and forth between the two operations and grasp this new paradigm. They can issue global commands that span the entire document, such as "turn all headings blue," which is difficult to achieve with one click in traditional editors. They can even ask the AI to reassess and streamline the document from the perspective of board members.
But for ordinary business users, their first reaction is often confusion: "So I just need to type on the left?" This is actually a profound paradigm shift. I suspect that with the popularization of AI tools, just like when the mobile internet era first arrived, in about two to five years, this new interaction method will become very common. It's like when people first saw Excel and would bewilderedly ask, "Where do I input paragraphs?" but now everyone knows how Excel works.
The biggest challenge we face is how to naturally integrate all these powerful AI capabilities into a minimalist interface to assist people in truly leveraging the knowledge of the entire organization to generate documents. I know this is entirely feasible at the underlying algorithm and mathematical logic level, but guiding users to accept and master it through excellent experience design remains challenging and incredibly exciting We need to spend a lot of time continuously improving these experiences.
Eric: This is a very suitable topic to conclude with. Mike, thank you very much for joining our podcast, it has been a very wonderful discussion.
Mike: Alright, no problem, guys. I hope these shares can be helpful to everyone
