Lenny's Podcast · May 31, 2026
Benedict Evans argues AI is as transformative as the internet or mobile — but we're only in a "1997 moment," where most applications haven't been built yet and adoption is still wildly uneven. The bigger structural questions are whether foundation model labs will ever have real pricing power, and whether the value will accrue to applications and distribution rather than the underlying models.
AI today is at the same maturity stage as the early internet: proven and exciting, but with most of its real-world impact still ahead.
As a PM, this framing resets your horizon: you're not optimizing for today's tools, you're positioning for a wave that is still building. Decisions made now — on platform bets, build-vs-buy, and team skills — have long lead times before they pay off, exactly like 1997 web strategy calls.
It's like evaluating the internet in 1997 and confidently betting on Excite — you'd miss Google, Amazon, and smartphones entirely.
AI performance has a jagged, non-obvious edge — excellent at some things, useless at others, and the pattern is hard to predict in advance.
For product decisions, this means you cannot rely on category-level analysis ("AI will disrupt legal") — you need task-level specificity. Discovery work on *which exact tasks* AI handles well in your domain is the prerequisite to any meaningful roadmap bet.
It's like a map where some roads are highways and some are dirt tracks — and the map itself doesn't tell you which is which until you drive them.
AI replaces tasks, not necessarily jobs — and the difference between the two determines whether a profession shrinks or transforms.
This is the single most useful analytical frame for assessing AI's impact on your product or team. Before cutting headcount or scope, map which tasks AI can absorb and whether those tasks *are* the value, or just the packaging around the value.
Amazon gets you the SKU if you know what you want — but knowing what SKU to order is a completely different job.
Making a task cheaper typically increases how much of it gets done, not how few people are needed to do it.
For roadmap and org planning, resist the reflex that "AI does X% of the work → we need X% fewer people." The more likely outcome is that your team does dramatically more, faster — which changes what you should be building toward, not how many seats you cut.
Building a faster highway doesn't reduce traffic — it creates more of it, because more trips now make sense.
Foundation model companies probably won't capture most of AI's value because the models look increasingly like undifferentiated commodity infrastructure.
If you're choosing a model vendor, long-term lock-in risk is lower than it feels. The application and distribution layers are where durable value is more likely to accumulate — which reinforces the case for investing in your own product differentiation rather than betting on one model partner.
Noble-prize-winning flat panel screen technology is still a low-margin commodity — scientific complexity doesn't create pricing power.
In a world of commoditized models, whoever has the most distribution wins — not whoever has the best model.
For enterprise product strategy, your AI feature doesn't need to be the best model — it needs to be the default in the workflow your users are already in. Embedding AI inside existing high-frequency surfaces beats launching a standalone AI product almost every time.
Microsoft won the browser war not by building a better browser, but by making IE the default on a billion Windows machines.
Even if AI is ready, large organizations aren't — their adoption clock runs on 3-10 year cycles, not the 2-week Twitter doomer timeline.
If you're in enterprise product, your competitive threat from AI-native startups is real but slower than it looks. Your window to embed AI into existing workflows before a replacement product captures your users is measured in years — but that window is finite.
No one tears out SAP on a Tuesday — enterprise transformation happens on the timescale of construction projects, not app updates.
History shows that automation destroys specific jobs and creates entirely different new ones — the net is more jobs and more prosperity, though the transition is painful.
For org planning and hiring strategy, the question is not "how many roles does AI eliminate" but "what new capability and role shapes does AI make possible that we should be building toward." Headcount reduction is the short-term frame; capability expansion is the durable one.
You can always see the job that's about to disappear, but the job that replaces it doesn't exist yet — so it always looks like there won't be one.
The money in tech platform shifts almost never sits at the infrastructure layer — it accumulates in the applications and experiences built on top.
This tells you where to build: application differentiation, workflow integration, and proprietary data are more defensible than model selection. If you're debating whether to deep-integrate with one model provider, the AWS analogy suggests the risk of lock-in is lower than it feels — but the opportunity from building great apps is real.
The telecom built the pipes, Apple built the App Store, and developers built the apps — the pipes are a utility, the apps are the business.
The first wave of any new platform is faster/cheaper versions of old things; the real value comes from new things that only that platform makes possible.
Most AI product roadmaps right now are phase-one work — automating existing workflows. That's valuable but defensible only temporarily. The durable competitive question is: what does AI make *possible* that couldn't exist before? Discovery work should be hunting for those phase-two opportunities.
Printing emails out was phase one of the internet; Gmail, Twitter, and Slack were phase two.
Breaking a profession into sub-tasks and scoring each for AI-replaceability sounds rigorous but produces misleading numbers.
Don't use percentage-exposure frameworks to justify product or headcount decisions. The real signal is empirical: run small experiments where AI touches actual workflows, observe what happens, and iterate. Analytical decomposition is not a substitute for hands-on evaluation.
You can't predict which buildings will survive an earthquake by analyzing their blueprints — you need real-world stress tests.
AI transformation in enterprises requires human experts on-site to figure out and implement new workflows — exactly what consultancies have always sold.
For enterprise PMs, this signals that AI adoption is a change management and services problem as much as a technology problem. Products that bundle deployment support, workflow consulting, or "opinionated" implementation guides will have adoption advantages over raw API offerings.
A forward-deployed engineer is just an Accenture consultant with a GitHub account and a San Francisco ZIP code.
AGI is a moving target that gets redefined every time AI achieves something — which makes it nearly useless as a planning concept.
Don't build product strategy around AGI timelines or definitions — they're definitionally unstable. Focus instead on empirical capability assessments of specific tasks today and near-term. Scenario planning against AGI milestones is mostly a distraction from shipping.
AGI is like the horizon — you can walk toward it forever and it always stays the same distance away.
Your AI roadmap is probably too near-term.
We're in a 1997 moment — most of the applications that will define the AI era haven't been invented yet. Optimizing your current product for today's model capabilities is necessary but insufficient; the bigger strategic question is what you'll build when the platform matures.
Foundation model lock-in risk is lower than you think — but so is their long-term leverage.
The structural case for foundation models commoditizing over time (no network effects, converging quality, utility-style margin pressure) means you should invest in application-layer differentiation, not model-layer dependency. The value will be in your workflows, data, and distribution.
Enterprise AI adoption is a services and change management problem, not just a technology problem.
The reason AI labs are buying consultancies is the same reason your customers will need help: they don't have spare capacity to redesign their own workflows. Products that come with embedded deployment support, opinionated workflows, or strong professional services partnerships will win on adoption, not just features.
what Amazon does is get you the skew. If you know what the skew is, if you know what skew you want, you want that microphone stand. You know this part number, you can go to Amazon and get it. If you don't know what microphone to get, probably shouldn't start on Amazon.
Crisp illustration of the task-vs-job distinction applied to e-commerce — directly transferable to AI product scoping decisions.
you know this is a joke I made on Twitter back when it was Twitter was like young people won't believe this but before invest before Excel junior investment bankers worked really long hours and now thanks to Excel Goldman's associates all work at lunchtime on Fridays.
Sharpest delivery of the Jevons Paradox point — automation made the task cheaper and produced more demand, not fewer workers.
you would think AI is going like consultants were going to be gone. No, we don't need all these people anymore. AI is going to do their work. Instead, like the most cutting edge AI labs are the ones most investing in these folks.
The forward-deployed engineer paradox — useful as a signal for how enterprise AI adoption actually works vs. how it's narrativized.
clearly what's happening now is that Google is using distribution to drive um to drive Gemini and like what's the difference between Gemini and for and and and like if you're you know if you're using this stuff all day then you know but like normal person there's no difference
Direct evidence of the distribution-as-moat thesis playing out in market behavior right now.
the model is just like the dumb thing underneath the funny way of putting it the dumb thing underneath that powers the feature the model is the commodity that powers different decisions about what the feature should be and what different distribution
Most direct articulation of the value stack migration thesis — the model is infrastructure, the feature is the product.
you can't kind of look at a senior partner at a law firm and say, well, 17% of their work could be automated like this is horshit. You can't do that.
Cuts through the O*NET-style job exposure analysis that is widely used in enterprise AI business cases — important caveat for any PM using such frameworks to justify roadmap bets.