The New Rules of Enterprise Software with Steven Sinofsky

There are many things that made software sticky, but a lot of it had to do with the fact that the way a human interacts. In an agentic world, do you actually need that? The data, the logic, everything stored below it is really where the value is.

There's this wild underestimation about like you could vibe code your way into enterprise software. Larry Ellison at Oracle, he went on a rant about how enterprise software was so stupid because everybody customized it. The minute you automate the most mundane thing and think you have it all squared away, whole new things appear.

Misconception right now is that you can just have, you know, Postgres database and APIs and then bam, like you can replace SAP. That's like absolutely not true. That piece around the logic and everything else that is encaptured in SAP is way, way more important than the fact that like, oh, this data just happens to be in this database. One of the things that happens in technology shifts is nobody understands exponential when it's happening. The biggest opportunity right now is...

Yeah. So headless software has really—it's not a new term, but I think has really risen in like the, you know, public domain of interest in a topic that people are talking about. One of the interesting news points has been Salesforce making this announcement. They were launching Headless 360, which was really in classic Salesforce motion, you know, history—a marketing announcement more than anything else. But it does capture—it sort of—it's an acknowledgement of what's happening, which is, you know, traditional software had been built around humans accessing it, and it was workflow to capture data. And we could talk more about what that meant in an agentic world. Do you actually need that? The UI doesn't matter because the agent isn't accessing the software via the UI. We could unpack whether the UI matters or not. But in the idea of being headless is the data, the logic, everything stored below it is really where the value is, not just the workflow software that's being tracked at the top.

So I'll separate it out into the Salesforce context and then like the broader context, which I think the broader context is more interesting. In the Salesforce context, probably not that interesting. I think Salesforce, I think rightfully again, it was acknowledging a shift that's happening in the market. I don't—from what I could tell, nothing actually changed. Their 360 product was the same APIs that had always been exposed, now rebranded as their 360 product. And APIs have always existed. So, you know, many—or I shouldn't say always, but for a long time—have existed. But I think the broader trend here is that, you know, Salesforce among others are thinking about how they build themselves for the agentic world. And so if an agent needs to access the data in a CRM like Salesforce, what are they doing it? Are they doing it via the UI or are they using the API? And that's the, you know, Salesforce is saying like, okay, hey, we know what is changing—that there are agents who are needing to access the data. Let's look at the, you know, let's offer a headless version for them to interact with the data versus going via the UI. That said, again, I don't think anything actually changed in the Salesforce context, but Salesforce is in the old one. Another example is Notion has a headless product, and actually I think that makes even more sense because it's much harder—like I think many users of Salesforce are probably less technically adept, less likely to be building their own agents, although there are many, many more people who are doing that with Salesforce. Notion users tend, you know, all things being equal, are more, I'd say, tech-savvy and more agentic as builders. And I think Notion is one of many other companies that is also trying to figure out, okay, what is it that I offer for, and you know, how do I make—what APIs do I expose? I think Steven will talk more about MCP. And again, I think a lot of this is also getting caught up a little bit in nomenclature and like, okay, what are we calling things?

And I think that's one thing, but I think the broader trend around how agents access systems of record, I think, is the bigger point.

Totally. And I think I read somewhere that there's been like a 300% increase in Slackbot—Slack agent usage. Yeah. Which is essentially saying that you don't need to log into the Salesforce UI interface to get the data or whatever data it is. So yeah, it's essentially again all these are agentic ways of accessing it versus the human needing to go in, log the data, or from a read perspective go back and see, okay, here were the—like here's this opportunity, here's what happened, and look at them themselves. And so that interface is less relevant.

Well, sir, I mean, like we're in definitional hell right now, where is, you know, part of a new wave of technology is you make up a lot of new words for things that you kind of did before. And that's just a natural part of technology evolution. But I actually think it's super important. Like first you have this—you have an agent, which as far as I can tell right now is also a new word for program that takes a very long time to run and might not finish. And so yet that's just like a branding—that's the best branding ever is to call a program that takes a really long time, which we used to call a bug, is now like the coolest new feature ever and it's just now an agent. But in seriousness, the most interesting way I think to think about what you're really talking about doing differently between an agent and an API is really what are you actually doing? What is the agent itself doing? Is it looking something up? Because that's actually a pretty lightweight thing that all systems are pretty good at. And in fact, many, many of the newly announced, you know, headless agent APIs are just lookup, and they're just—you basically have a new interface to the old way to look something up, which is a lot more forgiving, a lot less UI goo and stuff like that. Then there's like I want to do something, and that's where you get into very interesting issues over like, well, if you do something, you have to be impersonating a specific person, you have to have their credentials—like it's a very—is it another paid seat? Is it the same paid seat? You have all these interesting enterprise software issues that come up if you actually want to cause a change to a system of record. And then there's the third thing, which is analyze. And so analyze is more than look something up. It's actually look up a bunch of stuff. It often involves multiple systems. And that seems very, very tuned to an agent because you're not time bounded. You can spend energy, iterate. You can route it to different models and get different answers back and compare them. But it's also where hallucination really is a huge issue because if you're going to go and analyze something, you actually need a way to verify that everything, every step of that analysis was correct. And so I think it's super interesting and important when you look at headless and agent, which are conflated, and you sort of have to figure out what you're talking about because we're on different places in the evolution, the learning curve, and the deployment of agents relative to sort of that three-way matrix.

Yeah, I'd say there are many things that made software sticky, but a lot of it had to do with the fact that it was built around like the way a human interacts, right? So the UI was sticky because, you know, the number of times you had to read and write, the frequency of access, the downstream workflows, all of the like undocumented—like, you know, what we call SOPs or standard operating procedures—all the stuff that happened around the software that got ingrained in muscle memory and process and then external parties, etc. So like a CRM may be sticky because a sales rep needs to go in and out of it all the time. They're used to interacting with Salesforce. A lot of times when like new VPs of sales come into our companies, they're like—they mandate that Salesforce is there because they're used to using it. Their teams are used to using it. And then there's, you know, finance may rely on the Salesforce output for billing and upstream marketing is going to rely on it as well. And so there's these dependencies. And these all are driving stickiness. But I think the other piece too is that you need one single set of truth, right? You need to know like an account is closed and who is working on it and all of that needs to be logged in one place. And I think if you go from CRM to say an ERP or payroll, like that absolutely has even like legal reasons and compliance reasons why you can't have numbers that are not being, you know, tracked as cleanly and correctly as, you know, an auditor might like, for example. So anyways, this all drove stickiness there and durability because, you know, you were used to using Salesforce, the whole ecosystem was using Salesforce, and it was the default option and maybe, you know, there's one or two others in the market. And so I think historically those were some of the things that were driving stickiness.

Yeah. I mean, those are all exactly right. I think it's important to also consider that the most sticky thing you could do is actually collect money from a customer. And if you're collecting money, it turns out it's really, really hard for them to stop sending you money. And it's really hard for them to figure out what to do if they stop sending you money. And it sounds really trite, but the stickiest software is software that's getting used somewhere. Then when you dig in and try to come up with reasons, well, it just depends on who you talk to in a company. You know, you talk to the HIPAA compliance people in some company and they're going to tell you this is the software you have to use because it's like the most bestest HIPAA compliant software. If you talk to the administrators, you're going to hear about onboarding new users. If you talk to the users, you're going to hear about muscle memory and keystrokes or labor unions or whatever. And so you have to be—yet you really want to get the software sold, and that's your fastest path to sticky. And after that, it's sort of, you know, a winner's tale over what caused it to be sticky. And in fact, the best thing about sticky is if you're the rep for a company that you've sold something to and the company is threatening you like, hey, we're going to replace you, we're just going to listen to them and you're going to find what's sticky. And if that works like three or four times across different accounts, then you've just told the tale as to what made the product sticky. It doesn't matter what the PMs or what anybody else thought of. It could be some crazy arcane thing, you know, like I have stories of lots of sticky software and lots of arcane things, but like anyone who's ever tried to displace Microsoft Outlook as email very quickly learned about delegate access and having calendars owned by multiple people and all of this crazy stuff. And like I can tell you there was no meeting where we said, 'Okay, let's figure out how to make the calendar the sticky part of Outlook and make sure we handle recurring meeting exception handling well.' And then you go and you find out, you know, General Motors isn't going to displace like 600,000 seats because of the calendar or some crazy thing like that. And so you can—it's really amazing in enterprise software what causes sticky and how you can actually capitalize on it when somebody threatens to take you out of the enterprise.

I think there's a really good point there in two things. Inertia is a really powerful force. And then I think the other thing is, yeah, nobody when they're building the software, they're not like thinking about like this rubric we put together and like tick, tick, tick. We got all these features that are going to do all these things. But I think the practical reality is also as software extends its tentacles across an organization and it gets ingrained in people using it and they've been paying for it for a long time, it just seeps into how people are doing things and that's like hard to rip out.

Well, I mean, Sema co-wrote a post on SAP, which is sort of the ultimate example of sticky software. I mean, there is nothing—the only software that's stickier than SAP is behind the scenes, and it's the software that insurance companies wrote. And they wrote all this software like 50 years ago or 75 years ago, and if you ever—there's no replacing it. Like it just—it in fact, whenever jokes come up about like businesses that are looking for COBOL programmers, it's to go and work on the insurance software that exists in every state of the union. And in many ways, what you're seeing like with one of the biggest successes to date in Stripe has been somebody actually went in and for the first time in two generations coded up the software to collect money from people, which itself had previously been an unsolved problem on the scale of insurance because nobody put together the tax laws for every country, every jurisdiction, every locality, every border crossing, every currency exchange. Like it's mind-blowing that. And so now that is the most sticky. So like that is not going anywhere ever. Like it'll be like we'll be doing this podcast with like great-grandchildren 100 years from now talking about how sticky that experience was. Just like I told like, oh, you didn't know this, but the software that runs Allstate is older than me and it's not going anywhere. And that's because these examples are ones that codified an external force, and that external force was the regulatory body that they embraced. The seamless examples of SAP—like it just codified a company. And so like if you take SAP out of a large automobile manufacturer, there's no automobile manufacturer left, or Walmart—like the company just evaporates because the company is defined not just by purchasing the software, not even by just using it, but by how they codified the business rules into that product.

I think it's a good point to double-click on because I think a misconception right now is that SAP—okay, well, you can just have, you know, Postgres database and APIs and then bam, like you can replace SAP, and that's like absolutely not true. I think partly—I mean, Steven, I don't know if you want to elaborate on it or not, I'm happy to, but I think it's that piece around the logic and everything else that is encaptured in SAP is way, way more important than the fact that like, oh, this data just happens to be in this database. There's a reason why also SAP takes, you know, multiple years to implement and get—it's not because like, oh, you know, yes, the system integrators are slow and part of it, but it's customized to the way that business actually operates. And I think that's like an important part about why you can't just obscure away the software completely and turn it into a database plus APIs.

Yeah, this is just so important because this is one of the things where like startups look at enterprise software and they think about it in terms of startup scale. And so they take something like mundane like expense reporting and like, okay, well, we have 40 people and like, you know, one person could figure out expense reports for 40 people. Like you could hire a human and that and be done with it. That like literally you come back from a trip, you dump the receipts in a bucket and one human rifles through them and the expense reporting problem goes away. Or you say, 'Oh, forget the human. We'll just all take pictures of our receipts and OCR it and categorize it and the whole thing will go away.' And that's fine until you have 100,000 people in 20 countries with different national laws and policies about business expense and all of those, and then you overlay corporate policies and the whole thing just—and then your business is just codified that way and you can't replace it. You back in the late 1990s, who now is sort of the godfather of enterprise software, Larry Ellison at Oracle. Back then they were only a database company and entering the world of NetSuite and ERP and all this, but he went on a rant—a multi-year rant—about how enterprise software was so stupid because everybody customized it. And he had this saying that just said businesses should just stick with the 80% solution and they should just use whatever works like 80% of the time. And most enterprise people were like, well, A, you're just talking your book because your software only does 80% of what I need. But B, like that's just not how it works. Like if you take the auto industry and you just take the top 10 companies in autos, they all, you know, putting aside EV versus gas or whatever, they all just make cars, which is a lot of known technology with assembly lines and workers. Like what differentiates the companies and what differentiates them is how they operate and the internal processes to decide what car to make, how many more materials to buy, what currencies to hedge, how many people to hire, when to introduce a new product line. All of that is enterprise resource management and planning. And how is all of that done? It's all in SAP. So those companies are effectively run by people sitting in conference rooms looking at SAP screens. And the difference between Ford and Toyota and General Motors and Daimler are not just that they're looking at the same screen. It's that they chose which screens to look at, which customizations to make in those screens, and then they go and they buy steel and aluminum and wire and dashboards and radios from all the same places. And so it's—I just think that people wildly underestimate the level of sophistication that customers apply to this software. Like when back when we were first starting to get Excel used in companies, you'll laugh at this even—like we used to do these little visits and we go visit bankers. And so we're sitting in Goldman Sachs and we're telling him about Excel is better than Lotus 1-2-3, blah blah. That's super old. You don't even know what 1-2-3 is. I know. Trust me, it's old. And the guy at Goldman looked at us and said, 'I don't think you understand. We make more money from Excel than you do.' And we're just sitting there like, what is he talking about? Like it made no sense to us. And then we started to think about it and it's like, well, we sell Excel to Morgan Stanley and JP and Chase and everybody else. And what Goldman was saying is their application of Excel is so differentiated. And that wasn't just people typing. They built add-ins. They wrote all this code. They defined their WordPress.

You know, there's this wild underestimation about like you could vibe code your way into enterprise software. I was at a dinner last night and there was someone there who was like the head of RevOps at a—I don't know—maybe growth-stage startup, and his task—this is like a thousand-plus person company—was to rebuild their Salesforce instance internally. And you know, I think he's like, oh, well, you know, we know all the fields, we can import all the data. And I was like, that's not really the part that's tough, right? It's well, how are you deciding what gets captured, how the whole organizational lines around it. And then who's going to maintain this also over time. I think that's like a piece that just falls off. You know, you can vibe code a CRM. We've all vibe-coded projects that have like already gone stale and know we haven't touched again because it's painful and it takes time and needs to adapt to the business.

A lot of what we're seeing AI being used today for is how do you make it—like I think the word is often used like conversational or like how do you pull the information out and actually make it more usable? How do you retrieve the information from SAP without needing to go, you know, run a SQL query and get all the information or like look at a bunch of screens? It's like, okay, well, if I want to be able to connect to Steven's point around analyze, like, you know, three different sets of tables in different geographies, like can I quickly, you know, query that like a natural language way? Can I get reports automatically generated that are customized to me without needing to like go back through the SAP customization process? And I think that usability layer is indicative of what's happening now with software in general, which is accessing the UI is optional. And like going back to the Slackbots point, like you want the information delivered to you versus needing to go to the UI, but the data and the business logic inside either it's SAP or something else that's replacing it that's building it, but that all still needs to exist one way or another.

Mhm. That's an incredibly important point for folks to take away, which is that the biggest thing about enterprise software is it almost always does what somebody wants it to do. They just don't know how to make it do that. Like there's no report that SAP can't generate. No graph, no chart, no analysis or whatever. But you just can't figure it out. Or maybe it's configured so you don't have permissions or something. So the way to think of it is in enterprise software the two most frequently used features exist in no enterprise software natively: it's export to Excel and export as CSV or PDF, you pick. And so all enterprise software, the first thing they have to do that's missing when they show up and they do that first demo is the customer say, does it do export to Excel or does it do export to CSV or PDF? Because then you know you have an escape valve to do the thing that you couldn't do before on analysis. And so what's so cool about where we are today is that now with the language models you have this incredible way to actually consume those in much easier than you could before. If you think about PDF, like the old way used to be like, okay, I want to figure out like exception handling, some report that my system emits, you know, declined expense reports or whatever, but I want to do it over some weird time period or across different currencies that it doesn't handle or some weirdness that you can't figure out the UI. So now you can export them all and take these 20 PDFs and put them in a model and do a bunch of analysis that you couldn't do before or if you did it was all copy and paste and this mundane thing. And to something that Sema wrote about, these sort of—I don't remember the word you used—but these ad hoc business processes are the ones that really become the most interesting because they're interesting because that's how a business runs, but they're also interesting because those are the next products. Like those are the next companies that people start. You know, CRM used to just be a spreadsheet. Like if you were in a business and you were an account manager and you kept track of your accounts, you just kept track of it in Excel and then a company got started to do that. It wasn't Salesforce first. It was the predecessor called Siebel. And then like people like, oh, we should make a whole company that does this. And that's what some of these apps are that you're seeing using language models and interfaces that are chat to SAP or to Salesforce. They are just trying to take advantage of what the LLMs are really good at, which is synthesizing and orchestrating unstructured information.

Yeah. I think we also forget that like Salesforce is like really an enforcement mechanism for like the go-to-market team, which is like, okay, are you collecting all of the information that you need to? And of course we can talk about Salesforce hygiene etc. as a separate point, but like do you have all—you know—is the human doing the getting the data to then have like the to then, you know, capture the state of the business. Which okay, but I think if we like now switch to the agentic world, and I think again we can talk about what agent means, but imagine there's an agent that needs to do outbound calling or outbound messaging. They want to be able to retrieve that information. They don't really care about how the fields are organized or, you know, how many clicks it takes, but they do want to be—they still need to access that information. But then the second piece they need is this context thing. So we've talked a lot—I think I feel like the internet has talked a lot about context graphs over the last six months, but what is that? That's all like the exceptions. What do you do? How do you handle certain cases? It's the edge cases and the permissioning and all that stuff that needs to be—and all the policies that are not necessarily in the fields of Salesforce. And so for the agent to then go back to this 80/20 thing, the agent can, you know, extract all the information, send an outbound email based on the information that's in the CRM around the person and their persona and what they do and all that, but then like, okay, how do you deal with a case, one case versus another, and how they respond? And it's like, oh, well, normally if it's a person who's in Asia, we respond this way, but if it's a person in the US, we respond this other way. That's not captured in Salesforce, but that was in someone's head. And so that's the context that I think is really important now for agents to be able to act on behalf of this data.

Oh, that's super. I mean, for Salesforce in particular, that's incredibly important because I've never met a salesperson, an account manager, an account executive who thinks that the default is the right answer for anything with their account. And like no, even if they get the Japanese language right, you know, oh, it's spring and the birds are chirping and but you're overdue on your payment, your license count is wrong, that even if you do that correctly, the rep is going to want to handle it in their specific way. And I think that this notion of exception handling is just the root of the challenge with agents, which is...

Almost everything interesting in an enterprise is an exception.

Yes. Yep. Like that. Like all the people are about exception handling. It, you know, it's basically like spend 15 minutes at McDonald's and watch people start in the kiosk and give up and then go watch what they really want and they're like, 'Well, I wanted a McFlurry, but I wanted two flavors and mix them together and that's not in the...' And it's always the exceptions. And everything about automation in enterprise is handling exceptions. It just is. It's the strangest thing. Like, but you know, enterprise pricing is a great example. Like, how much is it per seat? Well, you have to call us. Well, you call, then you talk, and then it's still an exception.

Yeah. And that's exactly right. So these exceptions, they're not captured anywhere right now. Now, I think if you say if there's, you know, a voice agent that is doing, let's say, compliance check calls for freight, as one of our portfolio companies does, they're now collecting the exceptions through their voice agent and getting some of that context. Or if we're looking, we can talk about computer-using agents. If you're observing humans and how they are clicking through software, how they are responding to things, and now we have this ability now to, you know, not only record data or like record interactions but then process that with LLMs, then you're able to start collecting some of this context. But it's a lot there. I mean, as Steven was saying, all the interesting work is around the exceptions. So it's not like, okay, you know, three days later we've got it all, we've got all the context, because also like sales cycles take a long time. Each exception isn't like handled with the frequency that you get the data immediately, right? And so you have to feel comfortable, you have to get to that point where you're like, okay, we've observed enough interactions to actually capture, to understand the exceptions. And then on the sales side, the buyer trusts that, you know, this piece of software can actually, you know, has captured all the context to handle.