Author｜Lin Yi

Editor｜Key Points Team

The SaaS industry is undergoing an unprecedented crisis of trust amid AI disruption. Panic over SaaS's demise has spread through the market in recent times, with share prices of many established software companies taking a severe hit. Investors are collectively anxious: If AI can automate all enterprise tasks, will SaaS companies—which rely on hefty subscription fees—fade into oblivion?

On March 6, renowned investment firm a16z engaged in an in-depth discussion with Mike, CEO of software company Atlassian. Their core viewpoint: SaaS firms that fail to adapt to new pricing models and human-machine interaction paradigms will indeed be eliminated; however, systems that grasp enterprises' core business logic will leverage AI to build deeper competitive moats.

We've distilled key insights from this interview:

1.Software's essence is undergoing its biggest transformation in a decade: From static file cabinets to proactive executors

Reviewing software development from 1960 to 2022, from early IBM Saber airline reservation systems to later CRM and ERP solutions, the essence has remained unchanged: digitizing physical file cabinets into databases. Past software was passive, requiring human employees to retrieve files, read information, and execute operations—no matter how polished the interface.

But in the AI era, these file cabinets now possess autonomous thinking and task execution capabilities for the first time. Future software will no longer merely serve as data containers. For example, while QuickBooks previously required accountants to extract receipts for bookkeeping, AI-powered QuickBooks can now autonomously complete reconciliation and payment reminders. This shift from passive storage to proactive execution lies at the heart of this software revolution.

2.The SaaS industry hasn't reached its end—survival hinges on pricing models and business logic depth

The market's indiscriminate sell-off of SaaS stocks stems from investors failing to grasp underlying differences among SaaS companies. Alex points out that AI will trigger severe polarization among SaaS firms:

Many SaaS solutions charge per user seat tied directly to work output. For instance, once enterprises deploy AI-powered customer service, most end-user issues can be resolved directly, reducing demand for human agent accounts to nearly zero. These SaaS providers face extreme danger—without commercial model changes, their existing subscription revenues will face catastrophic declines.

In contrast, core HR and financial systems like Workday operate in safer territory. While they also charge per employee, their fees aren't directly tied to specific work outputs. More importantly, they represent decades of accumulated complex business processes, compliance requirements, and implicit rules—far beyond mere databases. AI won't destroy them; instead, it will enhance their value. For example, when onboarding a new employee in Workday, AI can directly leverage its data to automate background checks and previous employer verifications. AI acts as an amplifier for these core systems.

3.Vibe Coding will complement—not replace—core systems

Some argue that since ordinary users can now write code via natural language instructions to AI, enterprises should abandon expensive SaaS subscriptions and build their own management systems.

Mike believes this mindset completely ignores commercial realities. The business world teems with infinitely complex edge cases and special regulations. While you could easily use AI to build an employee leave application, how would it handle unique local laws, tax regulations, and compliance requirements when a branch employee in Indiana takes maternity leave? Such implicit knowledge is deeply embedded in large SaaS platforms' underlying code—far beyond what a few prompts can replicate.

Thus, Vibe Coding's true value lies not in disrupting core SaaS software but in lowering development thresholds for niche demands. For example, administrators could use Vibe Coding to build a low-cost conference room booking tool for small teams based on Workday's underlying data and rules. This strengthens—rather than replaces—core SaaS solutions by enhancing their internal stickiness.

4.The biggest bottleneck for AI adoption now isn't model intelligence but product design and human-machine trust

The tech community obsesses over large models' parameters and benchmark scores, but Mike argues: Current AI capabilities far exceed their actual utilization by users.

Developers who only provide users with an omnipotent blank chat interface will induce choice paralysis. To truly integrate AI into workflows requires revolutionary UI/UX design akin to the PC-to-mobile transition.

The greatest barrier to enterprise AI adoption is employee distrust. When AI agents automatically process 15 emails and approvals in one second, users' instinctive reaction isn't joy but panic: "What did it send? Were there errors?" Therefore, excellent AI products must incorporate logical breakpoints and feedback loops, allowing users to ask "What are you doing?" in real-time during workflows and pausing for human input before critical decisions. Only by establishing transparent trust mechanisms without disrupting users can AI become a true productivity tool.

Facing this technological shift, we needn't overly pessimistic about SaaS industry growing pains. AI's ultimate role in commercial software isn't to build an omnipotent system that eliminates humans and existing infrastructure, but to integrate deeply into current workflows and core businesses like infrastructure. Software companies that leverage AI to refactor (reconstruct) interactions and deepen business logic barriers will usher in an even more prosperous golden era than the past decade.

Below is the a16z interview transcript:

1.SaaS risk levels have risen

Alex: From 1960 to 2022, software's entire history involved transforming file cabinets into databases. The first example was IBM's 1960 SABRE system developed with American Airlines. It replaced paper-based reservation systems managed by secretaries and stored in safes, digitizing this data into early databases. Back then, a 10MB hard drive might cost hundreds of millions of dollars. The same applies to electronic health records—Mass General Hospital developed the earliest system, MUMPS. Salesforce and the first CRM company (founded 1987) followed suit, essentially turning file cabinets into databases.

This approach offered benefits but didn't dramatically improve global efficiency. Previously, to find Eric's records, you'd send someone to HR's file cabinet. Now data resides in Workday, but you need a Chief Information Security Officer to prevent hacks and IT staff to configure accounts in single sign-on systems. Efficiency gains emerge primarily during cross-regional collaboration, where people can now work together and perform complex database joins—far harder with paper documents. But essentially, software from 1960 to 2022 remained static because file cabinets couldn't think.

The coolest development in AI today is that file cabinets can now work autonomously. For example, QuickBooks can now independently complete tasks rather than merely relying on humans to retrieve files. It's like bidding farewell to 16th-century accounting departments rummaging through archives—fascinating.

Erik: That's an excellent entry point. Everyone discusses the "SaaS Apocalypse" or even "SaaS Armageddon," referring to public market developments. Many have strong opinions about its significance. I'd like to hear your interpretations. What's happening? More importantly, how should we understand this? Why does it inspire such fear?

Mike: I believe the world is currently trying to figure out how to rate or value software businesses during this highly disruptive phase. Everyone has sharp insights about potential futures. Two extreme scenarios emerge: Either fantastic or terrible for the entire software industry, specific companies, or categories. Undoubtedly, risk levels have risen.

From investors' perspectives, SaaS used to be a stable category. Now, with heightened risk, they're stepping back to observe. As I often say, investors aren't necessarily calculating all historical profits via discounted cash flow models—they're guessing what other investors will do or betting on others' perceived futures.

The current panic seems detached from reality. People think: "If AI achieves X in 2-3 years, what does that mean?" This stems from a static mindset, as if humans won't adapt and the world won't change—as if only AI evolves while everything else remains frozen. The situation is interesting: Our company still performs exceptionally well, with three consecutive quarters of outstanding results. While we're not defending the entire software industry, our business data and results prove our optimism about current opportunities.

This doesn't mean we don't need adaptation. We're transforming our work methods thoroughly and rapidly, just as in past years. Many assume we can't change or adapt—that's clearly wrong, though strategic uncertainties exist. Realistically, not every SaaS company will thrive in the next decade. Just as many companies failed to transition to the cloud during the Windows-to-Internet era, 100 SaaS firms won't all survive and grow. Some believe software will somehow vanish or become mere cash flows. But I can speak for our company: This is the best thing that's ever happened to our business. We operate in a knowledge world, possessing tools to explore and act using knowledge to accomplish client tasks. Logically, it's perfect—but we must prove this through practical transformation amid market impatience.

2.Three types of SaaS companies

Erik: Alex, what's your reaction to recent events? How do you interpret what's happening?

Alex: I hope my long-term judgment proves correct because current events are wild. I tweeted about this weeks ago: The market currently can't distinguish among roughly three SaaS company types. One type ties seat permissions to output, with accounts occupied by actual system users—reverting to the file cabinet metaphor.

Before diving deeper, let me step back to answer your question. Dan Ariely wrote an excellent book, Predictably Irrational. I used to send it to all our product managers to understand user pricing strategies. A classic example: Imagine being locked out of your apartment at midnight and calling a locksmith. He arrives in 1 minute, opens your door in 30 seconds, then charges $500. You'd think: "90 seconds of work for $500? What the hell!" You'd leave a 1-star Yelp review, withhold tip, and maybe dispute the charge with your credit card company.

Now imagine a parallel universe: The locksmith arrives, spends 9 hours trying to open your door. He returns to his office for more tools, finally lets you in at 9:30 AM. You'd be so grateful for his 9.5-hour effort that you'd give a $200 tip and leave a 5-star Yelp review.

This illustrates how humans can—and will—pay for "incompetence." Many pricing strategies relate to psychological fairness. We deem it fair to overpay the incompetent overnight locksmith while feeling enraged at the highly competent peer's perceived overcharging. Logically nonsensical, but emotionally fair.

Now recall how we evolved into SaaS models like per-user monthly fees. When provisioning costs nearly zero digitally, many situations apply. It just feels fair—if you have 500 seats, you pay more than for one seat, even if backend mechanisms are similar.

Thus, I categorize SaaS companies into three types. The first requires seats to produce work elements but no longer needs them. Zendesk exemplifies this "Patient Zero." If Zendesk clients adopt Sierra, Decagon, or in-house solutions, their seat requirements might drop to zero. For Zendesk, we're discussing future cash flow present value. They're in danger because monthly per-seat pricing without code or model changes guarantees that revenue stream will hit zero. Conversely, shifting to outcome-based pricing could triple or quadruple revenues—still constrained by fairness and predictable irrationality. Zendesk-like products may rise or fall, but without change, the default path leads to zero.

The second type is pricing based on the number of accounts (seats) paid for. This feels fair, but accounts (seats) are not tied to a specific outcome. For example, Workday has a great pricing model where, since you have 340,000 employees, I charge you per person per month. Why? I don't know; it just feels fair. But those GE employees aren't using Workday to produce outcomes. I think Workday is good, and this actually relates to what you can do with AI tools. For instance, when GE hires an employee, HR must check files in Workday and call the three previous employers for background checks to ensure the candidate's resume is authentic. But an AI tool could Absolutely (could fully) make those calls, provided it's the core business system. Currently, the IT sector is down 45%, but no one is ditching QuickBooks. These two pillars are per-seat pricing tied to some workload; seats are just a clever pricing strategy.

The third type is products in the middle, like Adobe. You might need more or fewer seats, but the situation is neither as extreme as Zendesk nor as disconnected as Workday.

Beyond these cases, there's an undercurrent that AI can write all code. As a senior software developer, I find this absurd. I want to quote the theory of comparative advantage proposed by economist David Ricardo in 1817. For example, you could grow your own food or weld aluminum, but even these simple examples are inappropriate. It's like how I have a comparative advantage in recording podcasts with you—I earn more doing this. Even if I'm more productive than a plumber, I should still focus on podcasts.

More importantly, there are edge cases hidden at the bottom. Theoretically, I could automate some Workday processes via AI, but what if that employee in Indiana quit while on maternity leave? You'd never know these edge cases unless you've encountered them yourself.

Much software is a set of deterministic rules learned over decades. These rules aren't public and are embedded; you can't copy them directly but must reproduce them through experience. If it's a very simple subtask with no edge cases, AI can indeed handle it.

But I believe the real core business systems—sticky, relied upon, and with all edge cases built-in—will thrive. They'll start adding AI-powered work functions, like asking if you need a background check or collecting overdue accounts receivable. You don't need to hire people; hire your software to do these tasks. When this truly happens, future cash flows will surge dramatically, which astonishes me.

Many public market investors can't distinguish these different categories. They're excited about AI but don't realize it must be deployed through software as the core business system. I think this is a fascinating moment for everyone to return to the first principles of business.

Mike: I personally hate 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 from a very industrialized era, starkly different from pre-industrial business models.

I understand why the term exists, but it feels like we're still using a physical floppy disk icon as the save button. Kids have never seen a physical floppy disk but keep using the icon. I question this because, to me, business is a process-based system, not a recording system.

Everything Alex just said is entirely correct. There are processes like background checks or others in enterprises. Coordinating a series of processes as cheaply, efficiently, and quickly as possible is actually the core of knowledge-based businesses. In knowledge-era businesses, I have tens of thousands of employees walking into the building daily with their brains and leaving with them. I have no atomic assets, drills, or steel—not even filing cabinets. Everything I do is about coordinating those processes, and I think most modern businesses are probably the same.

How does this relate to Alex's comments? I think it's entirely correct. We have different types of processes in business; I like to call them input-constrained and output-constrained processes. Take Zendesk's customer service as an example—that's input-constrained. Your customers ask a certain number of questions, and how quickly you handle them relates to the efficiency, cost, speed, and quality of running that queue. If you handle them 10x faster, you don't get 10x more questions because the customer base is fixed. Your problem is how to get them to ask fewer questions or handle them faster. Actually, many processes in enterprises are input-constrained.

I always use our legal team as an example. Their job isn't to create legal work proactively but to respond to and handle it. How many leases do we have? How many NDAs? How many regular contracts? It's like a fixed total. To get that work done, I'm trying to be as efficient as possible, which is part of input-constrained work with a complete execution process. But then I also face output-constrained work, like creativity, marketing, or even software development and technology, where theoretically I could complete infinite tasks.

My bottleneck is my creativity or how many things I can think of to do and how much value I can deliver to customers. These are where I gain efficiency improvements and produce more content, not just by limiting inputs to make the company profitable.

The point about Indiana is entirely correct because some processes are necessarily constrained by external rules, like legal, governance, and compliance requirements. In Indiana, I must follow certain procedures for employees, and these processes are both how I want the business to run and how it must run. Business is actually a collection of all these processes combined. From one perspective, we have recording systems and execution systems. My thought is that most businesses don't actually operate this way, but we usually understand it that way.

Alex: I completely agree; I think this is a fantastic framework. I love how Intuit, like TurboTax, since tax laws are publicly published and you could download all the rules, is highly deterministic. You could have tax filing and those messy download folders handled simultaneously. In this case, all rules are transparent, but I think edge cases being publicly released is actually quite rare.

Businesses have value. Theoretically, there are many knowledge-economy businesses where all their assets walk down the elevator and go home every night, but these businesses do have core value. For example, is McKinsey still valuable without all its employees? Because that's a business producing outcomes through a knowledge economy, deeply tied to labor unlike physical products. Still, they might have a top-secret internal manual dictating how to operate, hire, fire, and deliver outcomes for clients. I haven't seen this manual, so I can't replicate it, and it's probably been built and sustained for over a hundred years.

What's the product of non-digital, non-software companies? Their product might be centuries or decades of accumulated knowledge. I love going to Japan, where you'll see noodle shops open since around 1587. There's a reason they've lasted so long. It's a long-accumulated culture, knowledge, and skill know-how, along with a recipe list for making noodles. Making noodles might be slightly simpler with fewer edge cases, but extreme cases could arise. For example, what do you do if you run out of flour? How did the noodle shop survive the great flour famine of 1623? They must have taken certain measures, and this experience accumulates in that secret book of know-how rather than replicating what's already public.

Mike: This is why I find it so fascinating—it forces us to rethink our businesses. Is Intuit really filling out tax laws for you, or does Intuit know tax laws better than anyone else? The core value they provide is helping you process life data and comb, sort out, organize, arrange, streamline (organize) 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, not just to fill them out.

Now all businesses have to re-examine themselves. Maybe I had 50 processes internally that I thought were uniquely core secrets, but actually only 20 are truly core. I must now seriously consider which of these processes are truly unique and which are not, because we've never needed to think this way before.

Alex: I think this is somewhat about balance. Whether it's worth doing in-house—if you adopt a third-party tool, it's not an untouchable red line but more like an independent variable. Should I write code myself using Claude Code now? If a company overcharges for software to the point where it could cause my business to fail, and developing in-house can meet 99% of demand and cover costs, then writing code myself makes sense. But if that software only costs a dollar a year, developing in-house doesn't make sense.

And not all recording systems are of equal value. I tend to view recording systems as atomic units of a business. For example, a calendar is a recording system for time, and an ERP is a recording system for inventory. You have all these different dimensions of recording systems. I gave someone an example: I have an office in Miami that I don't visit often, with a conference room booking system like Google Calendar. Am I willing to put effort into changing that system? Obviously, because I only visit that office once a year—who cares about its stability?

In contrast, some systems directly affect my income and aren't expensive. 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's certainly no need to buy a cow and feed it myself. Due to comparative advantage and economies of scale, consuming large amounts of food at restaurants is actually lower cost.

So some recording systems are more susceptible simply because they're overpriced, or their value isn't that high in terms of what they store and record. Carta tracks and manages cap tables for many companies. How often do you check the cap table? Not very frequently, but it's crucial and can't be messed up. So I'm likely willing to continue using Carta because they don't charge much, and it's not a daily, high-frequency product, so it's not even in the consideration dimension for replacement.

3. The Difficulty of Replacing with Vibe Coding

Mike: I find vibe coding fascinating. As someone in the software circle, it feels like people could one day write code purely based on vibe and replace all those traditional tools. But then I think—if I rely on vibe coding to get through a whole day's work and just run it, that's terrifying. There still needs to be some truly smart engineers backing it up. First, I have other more important things for them to do. Second, I think relying entirely on this method is currently more detrimental than beneficial to me. Yet this is the so-called replacement trend.

Undeniably, we've seen huge internal gains in software scalability through AI coding and other methods. Most such applications are highly configurable and customizable, and in our case, even truly scalable. You can write software application snippets running on the platform covering various different domains, and many clients do just that. But previously, they needed to invest a large technical team to accomplish this.

Now, leveraging vibe code capabilities, they can extend and highly customize applications for specific use cases. For example, I want a conference room booking app for the Miami team. Due to some strange HR policies in Miami, that app for 20 people needs to check Workday and various other systems at any time. In the past, I certainly couldn't afford to have an internal team invest IT resources to build it because 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 the bottom but gives me a highly customized interface to complete specific tasks very tailored to the needs of the Miami front desk. This is very powerful, but it doesn't completely replace human work.

Speaking of poor Workday, I think Aneel is often the butt of jokes in these conceptual examples. But this is actually really powerful. It actually makes Workday stickier and more valuable in the enterprise market because you can build all these custom applications on top of it. This is the power of AI, Vibe Coding, and creativity, making the underlying system more aligned with my specific needs.

But we must be very cautious in balancing stability, rule processes, and high customization. You could even argue that examples like openclaw are about tailoring very personal apps for individuals. Most people building these apps aren't software developers; they're just building apps or other gadgets for their own use on top of Gmail. But they still use Gmail as the orbit (track/platform); they still need to go to Gmail to read and process emails, but they've built specific things for themselves to solve problems only they encounter. A few projects might evolve into companies, but most are just solving things they need to handle themselves. This is indeed very powerful.

4. Pricing Fairness

Alex: This is why I'm curious about pricing fairness arising from inconsistencies between the front end and back end. Take Salesforce as an example—they charge per license. I think our company has around 600 people and probably bought 600 Salesforce licenses. I've actually never logged into Salesforce, but I bet the company paid for me. However, I sometimes do use its outputs because it's actually our recording system. I don't want to overuse this term, but it stores all our business relationships, and I'm like part of a relational database table, say userid 422.

Whenever I interface with a company, it's like matching in another database, but we only want to pay for one underlying database. Now, it's just a fact that in a world where the front end and back end are gradually separating. I think Workday came up with a very clever pricing strategy—a powerful and fair pricing paradigm. The more employees you have, the more you pay. Why is that fair? Because GE obviously makes more profit than a 10-person company and should pay more, and that money is still a drop in the bucket for them. Their pricing is in the absolute sweet spot, and I think no one would dispute it. They'll add a lot of AI revenue in the future, but most importantly, their base pricing feels fair.

However, for products where the front-end and back-end have been somewhat separated, I am unsure about what constitutes a fair pricing model or how software pricing will evolve in the future. Clearly, if no one is willing to pay and everyone writes their own code without any competition, the pricing logic will remain unchanged. However, you can imagine a future where people build on customized front-ends and directly read data from the underlying database. Since all systems of record have a database representing everything at the base level, 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 and micro businesses that do not have a concept of seats; business owners simply log in to QuickBooks, so its front-end is, in a way, the back-end. Conversely, with Salesforce, you can imagine that while no one will completely abandon it, they may significantly reduce the number of seats because the underlying back-end remains essential, but the need for an expensive front-end decreases. They will not eliminate or make any changes to the back-end but will optimize the cost of the front-end.

Mike: I have 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 are paying is somehow correlated with their actual usage. A company with 10,000 employees is likely to pay more than twice as much for Workday, plus some volume discounts, because they are purchasing a larger quantity and have twice the complexity in their operations, and they themselves consider this fair. The principle that seems reasonable here is: I am willing to pay for my HR system based on the number of employees.

I believe the core issue with these types of things is that it is not just a database; it is a database plus a set of complex processes. Back in the day when I was growing up, we called this business logic. These business logics are by no means irrelevant. Why do businesses have these logics? Because businesses operate as a collection of processes, and managers seek standardization to streamline these processes to some extent. This is to enable different teams to work in the same way so that someone can manage, understand them, and accurately track outputs.

It's like if I own a bunch of car factories, and I want to consistently track the total number of cars coming in and out across them. The place where business logic is embedded is, to some extent, the moat and the value. Traditionally, the sales figures there are actually enormous. The processes you establish for your sales team are extremely valuable to you, and you would consider it a fair way to pay. But the question is, to what extent do your sales collaboration teams—those collaborators rather than core users—need these processes, and to what extent do they not?

I assume that Salesforce Sales Cloud has an MCP server that does not directly access the database but is mainly involved in your business processes and the rules during execution. The controversy now is whether certain sales-related personnel, if they are in the marketing department or customer success function, 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 requires a dedicated seat. Whether customers consider this bundled charging fair is another open question.

Exactly, the challenge is how this should be priced. I want to tell you that when discussing consumption-based pricing or pay-as-you-go pricing, outcome-based pricing is reasonable in many areas, but I definitely do not think it will become the mainstream software pricing method or apply to all SaaS software.

Because when you talk to customers, you find that they dislike this approach very much. They really dislike the asterisks and additional terms. This has nothing to do with the value they perceive they are getting. For example, I use Splunk on a pay-as-you-go basis. If the amount of logs I send them doubles, I have to pay more. I understand the logic, but log recording is up to me. I can record more or less. I can tell my team, why are you recording so many logs? It's too expensive, and are you really using these logs? I can control the amount of data I input. It's the same model as storage and S3 or other typical services. It's fine if I store 1GB or 2GB. The issue is that these are relatively transferable and controllable for me as a customer.

But many examples of outcome-based or consumption-based pricing that people give are things that, as a customer, I have no control over and are non-negotiable. So the world of AI tokens and AI credits is really difficult for customers. They feel like they don't understand what these tokens or chips you're giving me actually are.

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 credits, I don't know if your credits are the same as someone else's. The vendor is constantly adding new features, and my users are using them, so it consumes my credits. But I don't know what they are doing with those credits.

It's not that the company actively chooses to use them; rather, the vendor is adding features that make the software better, and these improvements seem to happen naturally. I can make my customers' credits consumption increase tenfold overnight just by adding a bunch of features like generating great summaries for you. Customers will feel like I didn't ask for that.

So I think when talking about outcome-based usage billing, when you communicate with customers, they still prefer seat-based billing. This may be because they understand this model better now, and they have been burned by many pay-as-you-go models that can cause bills to skyrocket, leaving them unsure how to control them.

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. But we try to focus on areas where when a customer's business volume doubles, they get twice the value and also pay twice the fee, and it's all under their control. Many other pricing models are not within the customer's control.

The last example of outcome-based pricing is that these outcomes are also dynamic. For example, in customer service, I save you costs. You used to spend $20 on customer service, and with our tool, you only spend $10. In the first year, this is a great sales pitch. But in the second year, the customer will say, I only spend $10 now, and I want to spend $5, or you haven't provided any value. And the vendor replies that if you kick me out, you'll have to spend $20. The customer will think, but I only spend $10 now. So the ability to save customers money each year is hard to measure from an outcome perspective, even though I am eliminating some tedious tasks.

Alex: I think it's the same from a sales perspective. I have founded two payment companies. I envy Workday very much, and I often talk to my sales team about Workday because they know exactly what's going on externally. They know how much money they can make from GE. They will say GE has 330,000 employees, and maybe we charge them $5 per employee per month, and that's the money we can make from that account.

If you are selling a software product, it is much easier to scale up your 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. It turned out that the real driver of the business was Casper, the mattress company. You just can't predict it. You think you've landed a big customer like Walmart, but it doesn't go well at first, and instead, signing up Casper is amazing.

Workday has this bidirectional predictability. It is predictable for the customer who is funding it, and it is also predictable for the management team. You know exactly where you should spend your time trying to sign up a customer like GE instead of a 10-person company because GE is bigger. But in the internet world, things are crazy. Stripe may make more money 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 can't know from the outside how much money you can make from a seat, scaling up your sales and marketing team becomes exponentially difficult.

5. Why is customer trust so difficult in the AI era

Eric: As an entrepreneur, I want to circle back to one point. In this era, can you share what the primary manifestation of this is for you? And how has it made you change your business?

Mike: Our view is that we sell collaboration 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 suites and combinations of apps through us. Fundamentally, these are all collaboration problems involving large amounts of text. This is very advantageous for us. What those people are doing is the most important part.

The tech world tends to want to reinvent everything and think that's the direction of the future. From a medium- to long-term perspective, this is usually correct. But our challenge has always been that we have a large number of customers who work in existing ways, and the workflows in various apps today are not really that intelligent. They want to move towards the future, but they also have to bring along a large number of users. So when we build AI features, the first thing we consider is that we need to understand what this technology is and how it can help us. Secondly, what foundational platform components do we need to build to cope with future changes, because these technologies are evolving at such a rapid pace.

That's why we developed the AI Gateway, the team collaboration graph, and enterprise-level compliance and control features. You have to distinguish these from the features you build for customers in specific apps. So where do you put these features? What exactly are these features? A large part of them exists within existing workflows, aiming to help customers complete their existing workflows faster, better, with higher quality, and more efficiently. These features are often very unexciting. It's like that 30-second animated GIF that went viral on X. But this is very exciting for customers because they can use it now, and their existing way of working becomes better. They think it's great. In the AI world, I actually think it's quite simple, and it does give them a huge boost today.

I often say to people internally that one example in the service area is not enough. You need to leverage their existing workflows and combine them with new apps or look at new workflows to handle problems. So we have to accomplish all of this. If you look at Jira as a typical example, in the service collection of our HR and IT service management products, ticket summarization is taking place.

There are probably four or five people internally working on the same ticket, trying to solve a problem. When the fourth person steps in, there are already a large number of attachments and conversation records. Normally, they might need to spend 30 minutes reading through everything and understanding what happened before they can apply their expertise to solve the problem. Summarization is not just about inputting content into an LLM and getting a summary. Context is very powerful for the model, but the customer's workflow doesn't change even a little bit. It's still Alex saying to Eric, can you come help me with this ticket? Eric comes over and has to load all the relevant information in his mind first. It's like an existing workflow where we can use an LLM to make the customer experience better, and they love it. They rave about these types of features. But these features usually don't have agent characteristics.

So we can say that for that service workflow, we need to add agents at various points. Most people are working on a workflow and then find that this step often trips them up and takes a lot of time. Can we make this step faster? This is definitely a feature that we have to provide ourselves for the agent framework.

We have a great agent framework for the entire team to use, combined with the graph and all the context you already have. It's very simple and also very affordable. Or you can bring your own agent framework. I think most enterprises will 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'll put it in the workflow and get it running. We have to be able to do that.

But you are still completely in the world of existing workflows, just performing a new and efficient task within the existing workflow. Then you encounter people who ask, what if the service ticket doesn't exist at all? So you are reimagining entire categories of software into new workflows. We have to help customers cross this chasm because they usually don't just have one service team; they have hundreds. If they are running hundreds of different service desks, they might say that these 20 will work in a new way, but they have to manage all of them. So we are trying to combine the data from the team collaboration graph with this, and we are doing it from a customer-driven perspective. This is often overlooked. We are trying to take them towards the future in five years, but our job is to actually take them towards the future in one year, two years, and five years.

The last thing I want to say is that we put a lot of effort into design. This point is always overlooked in any conversation because there is a lot of foundational design work to be done in how it works. If you look back at the mobile internet era, the first batch of apps basically just brought desktop or web content directly to the phone, and then we evolved into new interaction modes and experiences.

It's not just an evolution at the visual level but also includes how we should use these things. What was push notification originally used for? Pull-to-refresh is a very obvious and simple example; it's a classic design pattern. The whole process is like, how do I make the mobile and desktop work together, how do I switch back and forth? We have so many design challenges to solve. This is actually about helping ordinary users understand what's inside. They don't want to delve into it. If AI doesn't exist for them, it doesn't matter. They want the results that AI brings without needing to understand all the technical details. Our job is to hide these details and just give them the results or make the task more effective and efficient. In the tech world, sometimes we are too obsessed with things like model quality.

It's almost a cliché to say that models have far outpaced the value they actually deliver. There's so much underutilized potential. Part of this actually lies in design and experience. How do I access this? Give people a chat box with infinite capabilities, and they'll just say, 'Tell me a joke.' It's like having infinite power but struggling to help them harness it. This is where we face a huge challenge: how to integrate agents and all their capabilities into workflows and collaboration loops, enabling humans and agents to work together.

Alex: I love skeuomorphic design. Early web felt like you had a few physical sheets of paper—that's why it's called a web 'page,' like an 8.5x11-inch sheet. Then came mobile, where the initial idea was just to shrink web pages. But it turns out, if you break free from skeuomorphic thinking and think from first principles while leveraging device capabilities, you can create entirely new interactions. Like pull-to-refresh—that’s a mobile-born concept. I was just thinking about this the other day. Have you tried Nano Banana 2?

Mike: Yeah.

Alex: Right. A colleague just told me he used it to generate an infographic of dos and don'ts for American tourists visiting Japan. The one-shot effect is amazing. But it raises a question: How do you edit these outputs? Current editing feels very skeuomorphic—still classic GUI logic, like click here, modify there. So my question to you is: What’s the state-of-the-art in editing AI outputs? Or what should the ideal state be? Since you mentioned design, what’s your deep thinking on this lately?

Mike: That’s a great question. Let me take two steps back to answer it. First, building customer trust in AI is incredibly hard. In user research, we found people fear AI not because of its power but because it operates like a black box. Like, your AI assistant instantly cleans your inbox, sends a dozen emails—users’ first reaction is, ‘How do I know it did this right?’ To earn trust, AI must surface its intentions and request confirmation without being annoying. Otherwise, users think, ‘I might as well do this myself.’ So interaction frequency and trust mechanisms are a holistic systems design problem.

Second, training and applying AI requires massive data and constant iteration. Social media is full of hype about ‘god-tier prompts’—like reciting a Harry Potter spell to auto-run a billion-dollar company. That’s absurd. One-shot works, but in real business, you usually iterate inputs/outputs. Say you ask an LLM to write a paper, then realize the direction is wrong—you need to iterate by changing inputs. But if you’ve tried editing images via pure chat, it’s frustrating because you can’t precisely control what the AI doesn’t change. This is fundamentally an input experience design problem.

Take our company’s product: Our team collaboration graph has vast organizational knowledge and high accuracy—it even remembers code I wrote a decade ago. But if the AI assumes I want hardcore tech jargon in every answer just because I have a CS background, that’s useless. If we clutter the interface with checkboxes like ‘search web?’ or ‘search org data?,’ that defeats the design purpose.

AI should proactively anticipate needs. You see this in tools like Deep Research, but sometimes it’s frustrating. It’s like having 50 interns who can do a lot but ask you 50 questions per minute—you’d spend all day answering instead of working.

Moreover, iterating workflows in enterprise settings is much harder. Brainstorming, for example, requires teamwork. In our Whiteboard and Confluence, you can bring in agents to assist. They’re great at pulling organizational knowledge to generate ideas. But if AI does everything without human intervention, it loses trust. The proper flow is: we meet to collect ideas, add human intuition, filter useful parts, then feed those back to another intelligence loop. Because AI outputs are highly non-deterministic, the system must include a human-in-the-loop. Yes, designing the right level of human intervention is a huge design challenge. Too many confirmation steps frustrate; too few lose trust.

We just launched Agent functionality in Jira. When you assign a task to an Agent, it executes. But users ask, ‘What’s it doing right now?’ If you show them a thousand underlying steps, they’ll think you’re spamming them. So just introducing AI into workflows faces massive design challenges.

Take real business approval processes—a transaction needing security, accounting, finance, and sales reviews. How do you optimize this workflow with AI? When assigning tasks to Agents, you must carefully design the UX: When does it return results? How? Can users proactively ask for progress while it works?

We believe letting users check progress anytime builds short-term trust. But long-term, if the Agent nails tasks twenty times in a row, users will eventually delegate fully. These are all fundamental design/experience problems, not purely technical ones. The core challenge is making millions of daily app users trust the product and eliminate the black-box feeling. Blindly promising ‘I can do anything for you’ just confuses users.

Alex: This is still an open question. Because the ideal future interaction clearly isn’t just clicking like the past or constantly re-entering prompts like now—it’s a hybrid.

As long as tools serve humans, human involvement is inevitable. You need users to intuitively grasp the model’s inner logic, whether for trust-building or iterative refinement. This is fundamentally a design problem, and I think no one in the industry has perfectly solved it yet. We’re in the earliest stages of this exploration, all searching for optimal designs to adjust and edit one-shot content.

Mike: Let me take a document creation example. Knowledge workers have spent decades writing documents in fixed patterns: open a blank page, type a title, write, list bullets, or insert tables. Now with Create with Rovo, you can start from a prompt, let AI generate content from templates, or even have it research dimensions and bring back integrations.

But changing deeply ingrained habits is hard. The interface now has two panes: left is the document entity, right is a chat. Imagine a Word with no toolbars—just conversation-based formatting. We need to encourage users: ‘You can edit any text directly on the left or input commands on the right, like adding a new section, researching other materials, and appending them to the summary.’

When we observe power users, they thrive in this mode—switching fluently between both operations, grasping the new paradigm. They can issue global document-wide commands like ‘make all headings blue,’ which is hard to do in one click in traditional editors. They can even ask AI to re-evaluate and streamline the document from a board member’s perspective.

But for average business users, their first reaction is confusion: ‘So I just type on the left?’ This is actually a profound paradigm shift. I suspect as AI tools proliferate, much like the early mobile internet days, this new interaction will become commonplace in two to five years. It’s like when people first saw Excel and asked, ‘Where do I type paragraphs?’—but now everyone knows how Excel works.

Our biggest challenge is naturally integrating all these powerful AI capabilities into a minimalist interface to help people truly leverage organizational knowledge for document creation. I know this is algorithmically and mathematically feasible at the bottom layer, but guiding users to accept and master it through great experience design remains challenging—and thrilling. We need to spend massive time refining these experiences.

Eric: This is a perfect topic to wrap up on. Mike, thank you so much for joining our podcast—this was a fantastic discussion.

Mike: Yeah, no problem, folks. Hope this helps everyone.