Video · 2026-07-07 · 1h 1m · 30 moments

Software in the Age of Agents | The a16z Show

✦ AI generated

GUEST Steven Sinofsky GUEST Sema Amble GUEST Stephen Sinofsky

timeline · colored by role

Definition◆

Headless software strips away the human-facing UI and exposes the underlying data and business logic directly to agents, and that data and logic layer is where the real value sits, not the workflow interface on top.

Sema Amble explains that 'headless' software (like Salesforce's headless 360 announcement) reflects a shift where agents access data and logic directly, revealing that the UI was never the real source of value.

transcript

Sema Amble: 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.

explains mechanism · 1extends · 2supports · 1

Definition

In an agentic world, software's real value lies in the data and business logic stored beneath the interface, not in the UI itself, because agents don't need to access software the way humans do.

Sema explains that 'headless' software reflects a shift where the UI becomes optional for agents, and the real value moves to the data and logic layers beneath it.

transcript

Sema Amble: 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 the being headless is the 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.

extends · 2gives example · 1rebuts · 2

Definition◆

In an agentic world, software's value lives in the underlying data and business logic, not in the UI workflow layer that humans used to interact with.

Sema Amble explains that 'headless software' reflects a shift where agents access data and logic directly, making the traditional human-facing UI less central to where value resides.

transcript

Sema Amble: The UI doesn't matter because the agent isn't accessing the software via the UI. 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.

gives example · 1

Definition

In an agentic world the UI stops mattering because the agent isn't accessing software through it — the data, the logic, everything stored beneath the workflow layer is where the real value is.

Sema explains that 'headless' software reflects a shift where agents bypass human-facing UIs entirely, revealing that the true value of software was always the data and logic beneath the interface, not the workflow screens themselves.

transcript

Sema Amble: 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... 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.

gives example · 1rebuts · 1supports · 1

Mechanism

Agent behavior in enterprise software breaks down into three fundamentally different categories—looking something up, doing something (which raises identity/permission issues), and analyzing (which risks hallucination)—and each requires different technical handling.

Steven Sinofsky argues the useful way to think about agents vs. APIs is by what the agent is actually doing: simple lookups, taking action (which raises identity/permissioning issues), or analysis (which raises hallucination/verification issues).

transcript

Steven Sinofsky: Is it looking something up? Because that's actually a pretty lightweight thing that all systems are pretty good at... Then there's like I want to do something and that's where you get into very interesting issues... And then there's the third thing which is analyze.

extends · 1

Mechanism

Agent behavior splits into three distinct modes — looking something up, doing something (which raises credential/impersonation issues), and analyzing (which is powerful but where hallucination becomes a serious risk requiring step-by-step verification).

Stephen Sinofsky argues that the useful way to think about agents versus APIs is by what the agent is actually doing: lookup, action, or analysis — with analysis being the most agent-suited but most hallucination-prone.

transcript

Stephen Sinofsky: 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... Then there's like I want to do something and that's where you get into very interesting issues... is it another paid seat, is it the same paid seat... and then there's the third thing which is analyze... it's also where hallucination really is a huge issue because you actually need a way to verify that every step of that analysis was correct.

Mechanism◆

What matters in distinguishing agents from APIs is the actual task type: lightweight lookups, action-taking that raises identity/permission issues, or open-ended analysis across multiple systems where hallucination risk is high.

Steven Sinofsky proposes a three-way framework—lookup, do, and analyze—for understanding what agents are actually doing, noting that 'analyze' is well-suited to agents but most prone to hallucination.

transcript

Steven Sinofsky: 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 headless agent APIs are just lookup and they're just you basically have a new interface to the old way to look something up.

extends · 2gives example · 1

Claim

Software stickiness ultimately comes down to whether it's collecting money and being actively used somewhere; every other explanation (compliance, muscle memory, onboarding) is a post-hoc rationalization.

Steven Sinofsky argues that the truest driver of enterprise software stickiness is simply that it's collecting revenue and in active use, and that reps discover the 'real' sticky reasons only when a customer threatens to leave.

transcript

Steven Sinofsky: 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.

Claim

The single stickiest thing software can do is collect money from a customer, because once payment flows are embedded, customers find it extremely hard to stop paying or to figure out an alternative.

Steven Sinofsky argues that beyond features or workflows, the deepest source of software stickiness is simply being the system that collects a customer's money, which creates powerful organizational inertia.

transcript

Claim

The stickiest thing software can do is collect money from a customer; beyond that, stickiness is a grab-bag of arcane, undesigned reasons (compliance, onboarding, muscle memory) that only reveal themselves when a customer threatens to leave.

Sinofsky argues true enterprise stickiness isn't engineered — it comes from collecting customer money and from arbitrary, discovered-after-the-fact dependencies like Outlook's delegate access, not from any deliberate stickiness strategy.

transcript

Stephen Sinofsky: 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... 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.

Claim◆

SAP cannot simply be replaced by exposing its underlying data through a Postgres database and APIs, because the business logic encapsulated inside SAP is far more valuable than the fact that the data happens to live in a database.

Sema pushes back on a common misconception that enterprise systems like SAP are just databases with APIs — the years of embedded business logic and customization are what actually make them irreplaceable.

transcript

Sema Amble: a misconception right now is that okay well you can just have you know Postgress database and APIs and then bam like you can replace SAP and that's like absolutely not true. I think it's that piece around the logic and everything else that is encaptured in SAP that is way way more important than the fact that like oh this data just happens to be in this database.

supports · 1

Claim◆

The business logic and rules encoded inside enterprise systems like SAP are far more valuable and harder to replicate than the raw data itself, so simply exposing a database and APIs cannot replace SAP.

Sema argues that the common belief that SAP could be replaced with a Postgres database plus APIs is false, because the encapsulated business logic is what actually carries the value.

transcript

Sema Amble: A misconception right now is that SAP okay well you can just have you know Postgress database and APIs and then bam like you can replace SAP and that's like absolutely not true... 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.

explains mechanism · 1supports · 1

Claim◆

You cannot replace SAP by just putting the data in a Postgres database with APIs, because SAP's value lies in the business logic and customization encoded in it, not merely in data storage.

Sema Amble pushes back on the common assumption that enterprise systems like SAP can be trivially replaced with a database plus APIs, since the encoded business logic and customization is what actually matters.

transcript

Sema Amble: I think a misconception right now is that SAP okay well you can just have you know Postgress database and APIs and then bam like you can replace SAP and 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.

supports · 1

Claim

You cannot replace SAP with just a Postgres database and APIs — the business logic encapsulated in SAP is far more important than the fact that the data merely happens to live in a database.

Sema pushes back on the common misconception that enterprise systems like SAP can be swapped out for a simple database-and-API stack, stressing that embedded business logic is the real asset.

transcript

Sema Amble: I think a misconception right now is that SAP okay well you can just have you know Postgress database and APIs and then bam like you can replace API replace SAP and that's like absolutely not true.

Claim

It is a misconception that you can replace a system like SAP just by exposing its data via a Postgres database and APIs, because the business logic embedded in SAP is far more important than where the raw data happens to be stored.

Sema Amble pushes back on a common startup misconception that enterprise systems of record can be trivially replaced with a database and APIs, noting that the embedded business logic is the hard, valuable part.

transcript

Sema Amble: A misconception right now is that you can just have you know Postgress 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.

supports · 2

Anecdote

Enterprise software becomes durably sticky because it gets customized to encode a specific business's unique operating logic, not despite customization as Larry Ellison argued when he railed for years that companies should just accept an 80% standard solution.

Stephen recalls Larry Ellison's multi-year rant that enterprise software was 'stupid because everybody customized it' and urging an 80% solution — a view Stephen says misunderstands that customization is exactly how companies differentiate and codify how they operate.

transcript

Stephen Sinofsky: Larry Ellison at Oracle... 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. Most enterprise people were like, well, you're just talking your book.

supports · 2

Anecdote

Larry Ellison's rant that enterprise software was ruined because everyone customized it, and that companies should settle for an '80% solution,' missed the point: companies like Ford, Toyota, and GM are effectively defined and run by their unique SAP customizations, not by the generic software itself.

Sinofsky recounts Larry Ellison's famous complaint that enterprise customers over-customize software, arguing instead that this customization is precisely what differentiates competitors like Ford, Toyota, and GM from one another.

transcript

Stephen Sinofsky: Larry Ellison at Oracle... went on a 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... 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.

gives example · 2

Anecdote◆

Larry Ellison's famous argument that businesses should just accept an 80% generic software solution was wrong, because what actually differentiates competing companies (like Ford vs. Toyota vs. GM) is precisely how they customize systems like SAP to encode their own operating processes.

Sinofsky recounts Larry Ellison's rant that customization made enterprise software 'stupid,' then argues the opposite: the customization itself is what encodes a company's operating processes and separates competitors from each other.

transcript

Steven Sinofsky: He went on 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.

rebuts · 1

Anecdote◆

Larry Ellison's push for enterprises to accept an '80% solution' underestimated just how much sophisticated, deeply embedded customization actually differentiates and defines large enterprise businesses.

Stephen recalls Larry Ellison's rant that enterprise software customization was wasteful, then argues customization is actually what differentiates companies like Ford, Toyota, and GM from each other.

transcript

Stephen Sinofsky: he went on a 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.

Anecdote◆

People wildly underestimate how hard it is to rebuild enterprise software like a CRM; importing fields and data is easy, but capturing the organizational logic and maintaining it over time is what makes 'vibe coding' enterprise replacements fail.

Sema recounts a dinner conversation with a revops lead tasked with rebuilding a thousand-person company's Salesforce instance, showing that importing data fields is trivial compared to capturing organizational logic and maintaining it over time.

transcript

Sema Amble: 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 the head of revops at... a thousand plus person company, and his task was to rebuild their Salesforce instance internally... you can vibe code a CRM. We've all vibecoded projects that have already gone stale because it's painful and it takes time and needs to adapt the business.

Anecdote◆

People wildly underestimate how hard it is to 'vibe code' your way into real enterprise software, because the hard part is the organizational logic, ownership, and maintenance — not just importing fields and data.

Sema recounts a dinner conversation with a revops lead tasked with rebuilding a company's Salesforce instance, arguing the real difficulty is organizational logic and long-term maintenance, not data import.

transcript

Sema Amble: 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... 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.

gives example · 1rebuts · 1

Claim

Exception handling is the fundamental challenge for agents in the enterprise, because almost everything interesting that happens in a business is an exception to the default case.

Steven Sinofsky argues that since no salesperson believes a default action is ever the right answer for their account, handling exceptions—not the default case—is the true crux of enterprise agent design.

transcript

Steven Sinofsky: 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. 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.

supports · 1

Claim◆

Exception handling — not the standard, routine cases — is the fundamental challenge of building enterprise AI agents, because almost everything genuinely interesting in an enterprise is an exception.

Stephen argues that reps and businesses always want deviations from default behavior handled their own way, making exception handling the true crux of enterprise agent design.

transcript

Stephen Sinofsky: even if they get the Japanese language right, you know, oh, it's spring and the birds are chirping and but you're 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 in their specific way. And I think that this notion of exception handling is just the root of the challenge with with agents, which is almost everything interesting in an enterprise is an exception.

extends · 1supports · 2

Mechanism◆

Just as people fail to grasp exponential change during a technology shift, they also wrongly assume that making existing work easier through automation shrinks the total amount of work, when productivity gains actually create entirely new scenarios and expand the pie.

Stephen argues that automation doesn't eliminate work as feared; instead, like exponential change itself, productivity gains are underestimated because they spawn new scenarios rather than simply finishing the old ones.

transcript

Stephen Sinofsky: One of the things that happens in technology shifts is nobody understands exponential when it's happening, so you have to be very careful... The same thing happens with productivity: people look at the existing body of work and say how do we make that easier, and then there's this fear we're going to automate everything away... but they forget that productivity drives new scenarios.

extends · 1rebuts · 1supports · 1

Example

Automating the most mundane part of a business process doesn't finish the job — it opens room for a whole new, more sophisticated layer of work on top, as happened when expense reporting evolved from spreadsheets into full business travel optimization.

Using expense reporting as an example, Stephen shows how each round of automation revealed new problems and richer analysis opportunities, like business travel optimization, rather than shrinking the task to nothing.

transcript

Stephen Sinofsky: The minute you automate the most mundane thing and think you have it all squared away, whole new things appear. Like expense reporting is a really good example: first there's nothing, then people figure out how to do spreadsheets, then people figure out, oh, now we have a whole system, we can analyze it, and now all of a sudden business travel, you get ahead of the curve.

gives example · 1

Prediction◆

The biggest startup opportunity during a technology shift is not to attack an incumbent head-on, but to position between two established players, since incumbents will always protect their existing product line by bolting AI onto it rather than replacing it.

Sinofsky argues the smartest startup strategy is to avoid direct competition with entrenched enterprise incumbents and instead occupy the space between two established players, since incumbents will defend their existing products rather than replace them — much like HTTP/HTML displaced client-server not by replicating it but by reinventing it.

transcript

Stephen Sinofsky: The biggest opportunity right now is always always to look at the existing sort of mental map of enterprise categories and be in between two established players because the thing that you know right now during a massive technology shift is the one thing that established players won't do is disturb their existing product line and go to market... your opportunity in a startup is to just look at two big players who are bolting AI onto the side... and aim for the middle and do things in the new way.

extends · 3gives example · 1rebuts · 1

Claim◆

The biggest startup opportunity during a technology shift is not to attack an established enterprise category head-on, but to position between two entrenched incumbents who won't disrupt their own product lines — the same way HTTP/HTML displaced client-server computing by reimplementing its function in a new way rather than replicating it.

Stephen argues the biggest startup opportunity is to sit between two established players who are only bolting AI onto existing products, citing HTTP/HTML's displacement of client-server architecture as the model for succeeding through reinvention rather than direct competition.

transcript

Stephen Sinofsky: The biggest opportunity right now is always to look at the existing mental map of enterprise categories and be in between two established players, because the one thing established players won't do during a massive technology shift is disturb their existing product line and go to market. They're just going to try to weather this technology storm by powering through it.

extends · 1gives example · 1supports · 1

Prediction

The biggest startup opportunity during a technology shift is to position between two established players rather than attacking an existing category head-on, since incumbents will only bolt AI onto their existing products rather than disrupt their own product lines.

Stephen argues incumbents will defend their existing product lines by bolting AI on top rather than reinventing them, so the real startup opportunity lies in the gap between established categories, as HTTP/HTML did to client-server software.

transcript

Stephen Sinofsky: The biggest opportunity right now is always always to look at the existing uh sort of mental map of enterprise categories and be in between two established players because the thing that you know right now during a massive technology shift is the one thing that established players won't do is disturb their existing product line and go to market.

extends · 1gives example · 1supports · 1

Prediction

The biggest startup opportunity during this technology shift is to position between two established incumbents rather than attack either head-on, because incumbents will defend their existing product lines by bolting AI on top rather than disrupting themselves.

Sinofsky argues the winning startup strategy is to avoid direct head-on competition with an incumbent and instead find the gap between two established players, since incumbents will just bolt AI onto existing products rather than cannibalize themselves.

transcript

Steven Sinofsky: The biggest opportunity right now is always always to look at the existing sort of mental map of enterprise categories and be in between two established players because the thing that you know right now during a massive technology shift is the one thing that established players won't do is disturb their existing product line and go to market.

Prediction◆

The biggest startup opportunity is not competing head-on with an incumbent's existing category, but positioning between two established players, since incumbents will bolt AI onto their existing products rather than disrupt their own product line.

Steven Sinofsky argues the winning startup strategy during a technology shift is to occupy the space between two entrenched incumbents rather than attack either directly, since incumbents will defend their product lines by bolting AI on rather than reinventing them.

transcript

supports · 1

Highlight slides

Headless Software Exposes Data Directly to Agents✦ from: Headless software strips away the human-facing UI and exposes the underlying data and business logic directly to agents, and that data and logic layer is where the real value sits, not the workflow interface on top.Real Value Was Never the Workflow UI✦ from: Headless software strips away the human-facing UI and exposes the underlying data and business logic directly to agents, and that data and logic layer is where the real value sits, not the workflow interface on top.Headless Software: Value Moves Below the UI✦ from: In an agentic world, software's value lives in the underlying data and business logic, not in the UI workflow layer that humans used to interact with.Where Value No Longer Resides✦ from: In an agentic world, software's value lives in the underlying data and business logic, not in the UI workflow layer that humans used to interact with.Agents vs. APIs: It's About Task Type✦ from: What matters in distinguishing agents from APIs is the actual task type: lightweight lookups, action-taking that raises identity/permission issues, or open-ended analysis across multiple systems where hallucination risk is high.Three Task Types✦ from: What matters in distinguishing agents from APIs is the actual task type: lightweight lookups, action-taking that raises identity/permission issues, or open-ended analysis across multiple systems where hallucination risk is high.Where Hallucination Risk Lives✦ from: What matters in distinguishing agents from APIs is the actual task type: lightweight lookups, action-taking that raises identity/permission issues, or open-ended analysis across multiple systems where hallucination risk is high.The SAP Misconception✦ from: SAP cannot simply be replaced by exposing its underlying data through a Postgres database and APIs, because the business logic encapsulated inside SAP is far more valuable than the fact that the data happens to live in a database.The SAP Misconception✦ from: You cannot replace SAP by just putting the data in a Postgres database with APIs, because SAP's value lies in the business logic and customization encoded in it, not merely in data storage.The SAP Misconception✦ from: The business logic and rules encoded inside enterprise systems like SAP are far more valuable and harder to replicate than the raw data itself, so simply exposing a database and APIs cannot replace SAP.Where the Real Value Lives✦ from: The business logic and rules encoded inside enterprise systems like SAP are far more valuable and harder to replicate than the raw data itself, so simply exposing a database and APIs cannot replace SAP.Logic Beats Storage✦ from: SAP cannot simply be replaced by exposing its underlying data through a Postgres database and APIs, because the business logic encapsulated inside SAP is far more valuable than the fact that the data happens to live in a database.What Actually Matters✦ from: You cannot replace SAP by just putting the data in a Postgres database with APIs, because SAP's value lies in the business logic and customization encoded in it, not merely in data storage.Ellison's 80% Rule✦ from: Larry Ellison's famous argument that businesses should just accept an 80% generic software solution was wrong, because what actually differentiates competing companies (like Ford vs. Toyota vs. GM) is precisely how they customize systems like SAP to encode their own operating processes.Ellison's Rant: The '80% Solution'✦ from: Larry Ellison's push for enterprises to accept an '80% solution' underestimated just how much sophisticated, deeply embedded customization actually differentiates and defines large enterprise businesses.Sinofsky's Rebuttal✦ from: Larry Ellison's famous argument that businesses should just accept an 80% generic software solution was wrong, because what actually differentiates competing companies (like Ford vs. Toyota vs. GM) is precisely how they customize systems like SAP to encode their own operating processes.Customization Is the Differentiator✦ from: Larry Ellison's push for enterprises to accept an '80% solution' underestimated just how much sophisticated, deeply embedded customization actually differentiates and defines large enterprise businesses.Vibe Coding Can't Rebuild Enterprise Software✦ from: People wildly underestimate how hard it is to rebuild enterprise software like a CRM; importing fields and data is easy, but capturing the organizational logic and maintaining it over time is what makes 'vibe coding' enterprise replacements fail.Why 'Vibe Coded' Tools Go Stale✦ from: People wildly underestimate how hard it is to rebuild enterprise software like a CRM; importing fields and data is easy, but capturing the organizational logic and maintaining it over time is what makes 'vibe coding' enterprise replacements fail.The Vibe-Coding Illusion✦ from: People wildly underestimate how hard it is to 'vibe code' your way into real enterprise software, because the hard part is the organizational logic, ownership, and maintenance — not just importing fields and data.What's Actually Hard✦ from: People wildly underestimate how hard it is to 'vibe code' your way into real enterprise software, because the hard part is the organizational logic, ownership, and maintenance — not just importing fields and data.Exceptions Are the Real Challenge✦ from: Exception handling — not the standard, routine cases — is the fundamental challenge of building enterprise AI agents, because almost everything genuinely interesting in an enterprise is an exception.Why 'Correct' Isn't Enough✦ from: Exception handling — not the standard, routine cases — is the fundamental challenge of building enterprise AI agents, because almost everything genuinely interesting in an enterprise is an exception.Exponential Change Is Hard to Grasp✦ from: Just as people fail to grasp exponential change during a technology shift, they also wrongly assume that making existing work easier through automation shrinks the total amount of work, when productivity gains actually create entirely new scenarios and expand the pie.Automation Fear: Work Won't Disappear✦ from: Just as people fail to grasp exponential change during a technology shift, they also wrongly assume that making existing work easier through automation shrinks the total amount of work, when productivity gains actually create entirely new scenarios and expand the pie.Productivity Expands the Pie✦ from: Just as people fail to grasp exponential change during a technology shift, they also wrongly assume that making existing work easier through automation shrinks the total amount of work, when productivity gains actually create entirely new scenarios and expand the pie.The Real Opportunity: Between Incumbents✦ from: The biggest startup opportunity during a technology shift is not to attack an established enterprise category head-on, but to position between two entrenched incumbents who won't disrupt their own product lines — the same way HTTP/HTML displaced client-server computing by reimplementing its function in a new way rather than replicating it.Don't Attack Incumbents Head-On✦ from: The biggest startup opportunity during a technology shift is not to attack an incumbent head-on, but to position between two established players, since incumbents will always protect their existing product line by bolting AI onto it rather than replacing it.Reinvent, Don't Replicate✦ from: The biggest startup opportunity during a technology shift is not to attack an established enterprise category head-on, but to position between two entrenched incumbents who won't disrupt their own product lines — the same way HTTP/HTML displaced client-server computing by reimplementing its function in a new way rather than replicating it.Aim for the Middle, Build the New Way✦ from: The biggest startup opportunity during a technology shift is not to attack an incumbent head-on, but to position between two established players, since incumbents will always protect their existing product line by bolting AI onto it rather than replacing it.The Real Opportunity: Between Incumbents✦ from: The biggest startup opportunity is not competing head-on with an incumbent's existing category, but positioning between two established players, since incumbents will bolt AI onto their existing products rather than disrupt their own product line.Why Incumbents Won't Move First✦ from: The biggest startup opportunity is not competing head-on with an incumbent's existing category, but positioning between two established players, since incumbents will bolt AI onto their existing products rather than disrupt their own product line.

Related episodes

Audio · All-In Podcast

SpaceX-Cursor Deal, SaaS Debt Bomb, New Apple CEO, SPLC Indictment, Colon Cancer Spike

→

Video · Lenny's Podcast

The rise of taste, human authenticity and judgment in an AI world | Adam Mosseri (Head of IG)

→

Video · Syntax

Do You Read The Code? ⟡ HTTP Gets a NEW Method ⟡ Codex Gets Sol Ultra ⌁ Syntax Weekly ⌁

→