Product Stickiness in the Age of Agents

Every founder pitching a replacement for an incumbent has some version of the same slide. Their interface is dated, ours is better, and agents make the interface irrelevant anyway. The slide is usually right about the interface and wrong about everything after it. Product stickiness never lived in the interface: it lives in how deeply the software is wired into the way the customer operates, which is why the interface was never the part that made the incumbent hard to remove.

Product stickiness is the set of reasons a customer keeps paying you when a better-looking option is sitting right there. On a16z's The New Rules of Enterprise Software, Seema Amble, an a16z partner who invests in early-stage B2B software and fintech, and Steven Sinofsky, the former president of Microsoft's Windows division and now an a16z board partner, spend an hour taking that question apart with host Elena Burger. Their answer is uncomfortable if you are building a replacement and genuinely useful if you are building something new.

What product stickiness actually is

Start with the thing agents are supposed to have killed. Amble's framing of headless software is that the screen was only ever the top layer: "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." When an agent does the work, "the agent isn't accessing the software via the UI" at all.

So if stickiness lived in the UI, agents would dissolve it. Amble's list of what actually held customers in place says otherwise. A CRM is sticky because a sales rep is in and out of it constantly, because a new VP of sales mandates the tool their team already knows, because finance bills off its output, because marketing reads from it upstream. Then there is the part nobody writes down: the standard operating procedures that grew up around the software and got absorbed into how people work. As she puts it, "you need one single set of truth," and once an ERP or a payroll system holds that truth, compliance and audit requirements bolt it down further.

Sinofsky's version is blunter and worth memorizing before your next pricing meeting: "the most sticky thing you could do is actually collect money from a customer." Once money moves on a schedule, stopping it is a project with an owner, a deadline, and a risk register. Everything else is a preference.

He goes one level flatter still. "The stickiest software is software that's getting used somewhere." Not used well, not loved, just used. That sounds like a tautology until you notice how many roadmaps are built on the opposite assumption, that a product becomes sticky because of a feature someone designed to make it sticky.

This is where product stickiness and a competitive moat stop being the same conversation. A moat is why your category position holds against a rival. Stickiness is why this specific customer does not leave this specific product this quarter. The strategy-level version of the first question is in competitive moats in the AI era. This piece is about the second, which is more mechanical and more actionable.

Nobody designs the sticky part

Sinofsky's Outlook story is the one to keep. Anyone who has tried to displace Outlook as corporate email runs into delegate access, shared calendars owned by multiple people, and recurring meeting exception handling. And then the honest admission from inside Microsoft. There was, in Sinofsky's words, "there was no meeting where we said" the calendar should be the sticky part and that recurring meeting exception handling had to be got right. They found that out later, when a large manufacturer would not displace hundreds of thousands of seats because of the calendar.

His conclusion generalizes past email: "It doesn't matter what the PMs or what anybody else thought of." Stickiness is discovered, not specified. It usually turns out to be some arcane capability that no one on the product team considered strategic.

Amble names the force underneath it. "Inertia is a really powerful force." Software extends tentacles across an organization, people pay for it for years, and it seeps into how the work gets done. That is hard to rip out, and none of it appears on a feature comparison grid.

There is a practical method hiding in Sinofsky's account, and it is the most useful thing in the episode for a founder with paying customers. When an account threatens to replace you, listen instead of pitching, and in his words "you're going to find what's sticky." Run that three or four times across different accounts and you have the real answer. Not the answer from a positioning workshop. The answer from customers explaining, under pressure, what they cannot easily give up.

Almost everything interesting is an exception

The single most transferable line in the hour is Sinofsky's: "almost everything interesting in an enterprise is an exception." And its companion: "everything about automation in enterprise is handling exceptions."

Watch someone at a self-service kiosk, he suggests. They start, they hit the thing they actually wanted that the flow does not support, and they give up and find a human. The exception is the product.

Amble maps that onto agents precisely. An agent can pull a contact out of a CRM and send an outbound email using the fields it finds. What it cannot pull is the rule that a prospect in Asia gets a different opening than one in the US. "It's the edge cases and the permissioning and all that stuff" that matter, and "that's not captured in Salesforce". It lives in somebody's head.

That is why enterprise pricing is quote-based, why compliance calls have scripts and exceptions to the scripts, and why the last ten percent of any workflow automation is most of the work. Sinofsky puts the same problem from the engineer's side: "if you're not an engineer, you can't even explain the process that you use to resolve a customer issue." The people who own the exceptions cannot specify them, and the people who can write specifications do not own the exceptions.

For a founder, this cuts two ways at once. It is the reason incumbents survive a technology shift, and it is the reason a new product can become sticky faster than it has any right to. If you capture exceptions nobody has ever written down, you now hold something no competitor can copy from your marketing site. Capturing them systematically is a context problem, and the mechanics are in context engineering for AI agents.

Why you cannot rebuild your way past the business logic

The misconception the episode goes after directly is that a modern stack plus API access equals a replacement for a system of record. Amble is unambiguous: the belief that you can stand up a Postgres database and some APIs and displace SAP is not true, because the logic encoded in SAP matters far more than where the rows happen to sit.

Sinofsky's example is the reason. Take the top car companies. They all make cars, from broadly similar technology, with assembly lines and workers. What separates them is how they decide which car to make, how much material to buy, what currencies to hedge, when to hire, when to launch a line. All of that is enterprise resource planning, and all of it is in SAP. So the executives running those companies are, functionally, people in conference rooms looking at SAP screens, and the difference between them is which screens they chose and which customizations they made. Which is why "if you take SAP out of a large automobile manufacturer there's no automobile manufacturer left". The company is defined not by buying the software or even by using it, but by having "codified the business rules into that product."

The episode's answer to why an implementation takes years is not that the integrators are slow. It is that the system gets "customized to the way that business actually operates."

Sinofsky traces the mistake to scale. A startup looks at something mundane like expense reporting at forty people, where one person with a bucket of receipts solves it, and concludes the category is trivial. Then picture a hundred thousand people across twenty countries, each with its own national law on business expense, with corporate policy layered on top. The problem was never the receipts.

He also revives the counterargument and demolishes it. In the late 1990s, Larry Ellison at Oracle went on a long public rant that enterprise software was stupid because everyone customized it, and that businesses should just take the eighty percent solution. Customers had two objections. One, he was talking his book. Two, and more importantly, that is not how any of this works, because the customization is the company.

The Excel story is the sharpest form of it. Selling Excel against Lotus 1-2-3, Sinofsky's team sat in front of a banker at Goldman Sachs who told them: "I don't think you understand. We make more money from Excel than you do." It made no sense to them at the time. What the banker meant was that Goldman's application of Excel, the add-ins they built and the code they wrote on top, was differentiated from every other bank buying the identical product.

There is a wild underestimation, running through the whole episode, of what it takes to rebuild enterprise software from a clean slate. The episode tells it as a dinner conversation with a head of revenue operations at a company of a thousand-plus people, tasked with rebuilding their Salesforce instance internally. He knew all the fields and could import the data. The reply: "that's not really the part that's tough". The hard parts are deciding what gets captured, drawing the organizational lines around it, and maintaining it as the business changes. You can vibe code a CRM. Most of us also have vibe coded projects we never touched again, because keeping them current is painful and slow.

If you want the version of this argument aimed at one specific category, AI ERP covers what it actually takes to go after the general ledger, and vertical SaaS covers why owning one industry's workflow is the more defensible way in.

The counterargument worth taking seriously

An honest post does not stop at one podcast. There is a real counterargument, and it comes from someone with a good view of where models are going.

At a Sequoia Capital event, Boris Cherny, the creator and head of Claude Code at Anthropic, was asked whether we have a SaaS apocalypse coming. Working through Hamilton Helmer's 7 Powers, the standard list of structural advantages a business can hold, he argues some get more important with AI and some get less. Switching costs are on his list of the ones that get less important, because you can point a model at the problem and port from one thing to another. Process power lands there too: for companies whose advantage is workflow and process, he argues models are getting good at figuring out process, and that a recent one will hill climb toward a target you define until it is done. In his read, network effects, scale economies, and cornered resources still hold.

Both things can be true, and the reconciliation is the useful part. Cherny is describing the falling cost of rebuilding the software. Amble and Sinofsky are describing the cost of the customer changing how they operate. If your product's only stickiness is that reproducing your features is expensive, take Cherny's warning seriously, because that cost is dropping fast. If your stickiness is that a hundred thousand people, twenty regulators, and three adjacent systems have organized themselves around your data model, a cheaper rebuild does not help the challenger much.

A security angle sits right here, and founders underweight it. When switching costs fall on the engineering side, the remaining friction concentrates in permissioning, audit trails, and data residency. Amble raises exactly this: as you open API and agent access, someone has to decide who can read, who can write, and in which cases, and multiple agents writing to one system of record turns into a real access-control problem. That work is unglamorous and it is now load-bearing.

Agents change where the stickiness sits, not whether it exists

Y Combinator's Software for Agents request for startups makes the case that agents are working on top of software designed for humans clicking buttons, which is "slow, inconsistent, and brittle", and that categories need rebuilding for agents as first-class users. That is real, and it is where the design work goes: what an agent needs from your product is the subject of agent experience, and the question of when a chat surface is the wrong answer for a human is in conversational UI, which draws on the same a16z conversation.

But the a16z view of what happens next is more specific than a claim that the UI dies. Sinofsky's observation is that "the two most frequently used features exist in no enterprise software natively", which is export to Excel and export to CSV or PDF. Every enterprise buyer asks for them in the first demo, because they are the escape valve for the analysis the product cannot do. Language models make that escape valve dramatically more powerful, and the ad hoc business processes people run in that escape valve, a framing he credits to Amble's writing, are where the next products come from. CRM itself started as a spreadsheet a person kept of their accounts.

He is also skeptical that anyone gets to sit above the incumbents comfortably: "no software wants to be disintermediated by some other layer above it." No vendor accepts being reduced to a storage format for someone else's analysis layer, because that is a decaying business. And customers do not want to assemble their workflow from four providers either, since "your system will only be as stable as the most unstable part of that." A middleware layer looks clean in an architecture diagram and is historically unstable in the market.

Then the productivity trap, which is the part most founders get backwards. People assume automation shrinks the work: "they forget that productivity drives new scenarios." Automate expense reports and you do not finish the category, you invent business travel analysis, routing rules, card strategy, and performance optimization on top. "The long tail got no shorter. It just got longer in a different way."

Where a new product's stickiness comes from now

Amble lays out three paths a buyer has, and each implies a different product.

1. Build agents on top of the incumbent. Some of this works. Some of it does not, because the incumbent does not want to be the anonymous back end and controls how much of its API and documentation you actually get. She is not bullish on incumbents building great agents themselves.
2. Do it yourself. Maximum control, and very hard. Rebuilding a CRM for a startup is one thing. Rebuilding one for a Fortune 500 is a great deal of business logic to capture, done while the business keeps running on the thing you are replacing.
3. Work alongside the system of record. Sit next to SAP or on top of it, enhance the experience, let business users run agents against data they already have, and do not throw out the logic underneath. Then, over time, become a new system of record for data that was never captured before: voice agent recordings, transcripts, ingested documents, observed interactions.

Path three is where she puts a16z's money, and the reason is worth stating plainly. New stickiness comes from new data, collected systematically by watching how the business actually operates. Not from a better view of data the incumbent already owns.

Sinofsky's version of the opportunity is positional. The dumbest hard thing you can do is compete head-on with an existing category, meaning the same category done the same way. During a technology shift, "the one thing that established players won't do is disturb their existing product line and go to market." They bolt AI onto the side and power through. So the move is to "be in between two established players" and do things a new way. You still have a hard question to answer, but it is your own question, why you exist at all, rather than a twenty-year-old checklist of eight thousand requirements written for a different era.

The same logic extends past vendor boundaries to organizational ones. Software has always sold to a single function, sales or finance, but the interesting context now lives in the handoffs between them, a point Elena Burger, the a16z editorial partner hosting the episode, puts to Sinofsky and he immediately endorses. And the network effect he actually believes in is internal: "the biggest network effect in enterprise software is inside of a company." His example is a friend at SAP working on a white paper: he asked what questions they were trying to answer, ran the prompt, and sent a draft back, and he is confident that started a loop inside their team once people saw it work. A product that lets two functions talk to each other in a way they could not before is, in his framing, a new category rather than a feature.

A stickiness checklist for something you are building now

Run these against your product, not against a competitor's.

• What breaks downstream if we disappear on Friday? If nothing, you have adoption and not stickiness. Name the systems, reports, and people who would notice by Monday.
• Do we move money, or only report on it? Payment flow is the strongest tie in the episode. If you cannot touch money, find the equivalent scheduled obligation you own.
• Which exceptions have we captured that nobody wrote down? List them. If the list is empty after six months with real customers, you are automating the eighty percent that everyone can automate.
• Are we the single source of truth for anything? Not a copy, not a cache. Something where being wrong here means the company is wrong.
• What data are we collecting that did not exist before us? Calls, field observations, agent outcomes, decisions and their reasons. This is the stickiness you can still build in 2026.
• Who else reads our output? Every additional function that depends on you multiplies the cost of removing you. One consumer is a tool. Four is infrastructure.
• What did the last account that threatened to leave say? If you do not know, that is the cheapest research available to you and you are not doing it.
• Would our stickiness survive the rebuild getting ten times cheaper? Cherny's test. If the honest answer is no, you are relying on the one advantage AI is actively eroding.

The uncomfortable pattern across that list is that almost nothing on it is a feature. It is placement in a business process, ownership of truth, capture of undocumented behavior, and financial entanglement. Those are things a roadmap can aim at, but only if someone decides to aim at them deliberately instead of assuming stickiness arrives as a side effect of people liking the product.

What to do this week

1. Pull the last three accounts that threatened to churn or actually churned, and write down the specific reason each gave for staying or leaving. Sinofsky's method, run once.
2. Draw the dependency map: every downstream system, report, and team that consumes your output. Count them. That number is closer to your real stickiness than your NPS.
3. Pick one workflow you claim to automate and list every exception a customer has hit in it. Decide which ones you will capture in the product rather than in a support macro.
4. Answer honestly whether your defensibility survives a ten times cheaper rebuild. If it does not, choose one item from the checklist above to make true within two quarters.
5. If you are selling into a system of record, stop pitching replacement and design the path-three version: sit alongside it, and start collecting the data it never captured.

The through line is that stickiness is built into how a customer operates, not into your interface, and it is discovered by asking rather than designed in a workshop. That is a product and operating decision more than a technology one, which is what the AI Operating System for Startups course is built to work through, and it sits alongside the rest of the map in our pillar on AI for startups.

Sources

• The New Rules of Enterprise Software with Steven Sinofsky, a16z, the conversation this article distills, with Seema Amble and Steven Sinofsky.
• Profiles: Seema Amble at a16z for her enterprise and fintech coverage, and Steven Sinofsky at a16z, plus Steven Sinofsky on Wikipedia for his Microsoft record.
• The Larry Ellison rant about the eighty percent solution at Oracle, and the Goldman Sachs exchange about Excel, are Sinofsky's own recollections from the episode above rather than independently documented events, and are presented as such.
• The a16z essays behind the episode: Is Software Losing Its Head? on headless software, and Sinofsky's Death of Software. Nah..
• Anthropic's Boris Cherny: Why Coding Is Solved, and What Comes Next at Sequoia Capital, the source of the counterargument that AI erodes switching costs and process power.
• Software for Agents, Y Combinator's request for startups on rebuilding software for agent users.
• Background on Boris Cherny as creator and head of Claude Code at Anthropic, and on the framework he works from, Hamilton Helmer's 7 Powers.