Fifteen Years After Eric Ries Named the Apporach, Most Generative AI Programs Are Repeating the Exact Mistakes the Book Was Written to Prevent. Here’s How To Shift.
Enterprises have poured billions into generative AI, and most of it has produced nothing you can measure. A 2025 study from MIT’s NANDA initiative found that roughly ninety-five percent of enterprise generative AI pilots delivered no measurable impact.
The models work. The programs do not.
The failure is old: most enterprises never learned to build software iteratively. They fund one big bet, specify it up front, and ship a year later, hoping the guess held.
Eric Ries published The Lean Startup in 2011, after the dot-com bust buried a generation of companies that built things nobody wanted. Speed of learning, not speed of shipping, separates the survivors from the casualties. He could not have imagined generative AI; experiments then were expensive so it was about making smaller ones.
The tools have since collapsed the cost of execution, which makes the discipline more appropriate today, not less.
The design world has its own version of the big up-front bet, and it is due for the same reckoning. Long-form design thinking — the months-long IDEO-style engagement that empathizes, defines, ideates, prototypes and costs $300 an hour — was built for a slower world.
I lived through that era, and we shipped fast when we could — really fast. Two week sprints, continuous learning and measurement, analysis of data anyway we could. It was Lean Startup before the book was out, in spades, and I learned so much that I apply today.
And today, it’s back.
When a working prototype now takes an afternoon and the ground shifts every month, spending a quarter on empathy maps before you build anything is not rigor. Most of the design process is theater now that you can ship by lunch.
Understanding the user still matters; the front-loaded ritual around it does not when you can learn in small increments.
For years I have modeled my work as small startups: fast experiments, quick shutdowns when they stopped paying off. The ground under AI shifts so fast that learning is the only durable skill. What does not shift is the foundation: this comes back to first principles of design, and the laws of UX did not change with the tooling.
Here are four things the book still teaches us.
Understanding the Problem in the Real World Still Comes First
The comfortable read is that the models are not good enough yet, and the next release will rescue these pilots. It will not. Look at why companies die, and the same cause sits at the top of the list. CB Insights, reviewing hundreds of startup post-mortems, found that poor product-market fit remains the leading root cause of failure — founders built something the market did not need badly enough to pay for. Running out of money is how the story ends, but a problem nobody had is how it starts.
Generative AI pilots are dying the same death. The MIT researchers were clear that the failures were not caused by weak models. They were caused by tools built to signal innovation rather than solve a job someone really has.
A demo that impresses a boardroom and a tool that survives a Tuesday are two different products. One is built to be watched. The other is built to be used.
Toyota had a word for the fix long before software borrowed it. Genchi genbutsu — go and see. Do not manage the problem from a conference room; walk to the place where the work happens and watch it fail.
Teresa Torres makes the same case for modern product teams in her work on continuous discovery: you find real opportunities by staying close to real customers, not by admiring your roadmap. The teams crossing the AI divide are the ones amplifying work people already do. The teams stuck on the wrong side are the ones who never left the room.
Action items
- Go and see the real work. Sit with the people who will use the thing, in the place they use it, before you scope a single feature.
- Name the job before you build. Write down the specific task a real person is trying to get done; if you cannot, you do not have a product yet.
- Kill demo-driven roadmaps. Stop funding what impresses a boardroom and start funding what survives a Tuesday.
Resources
- CB Insights, the top reasons startups fail — poor product-market fit as the leading root cause.
- Teresa Torres, opportunity solution trees — staying close to real customers through continuous discovery.
Learning Fast Beats Shipping Big
The core loop of The Lean Startup is three words: build, measure, learn. Not build, ship, celebrate. The measure-and-learn half is where the value hides, and it is the half teams keep cutting when the schedule tightens.
If The Lean Startup names the loop, the design sprint shows you how to run it. The five-day method the Google Ventures team laid out in Sprint takes a real problem to a tested prototype in a week — map the problem on Monday, build a realistic prototype by Thursday, put it in front of five customers on Friday. You learn whether an idea holds up before you spend a quarter building it. Same instinct as lean, compressed into a calendar you can clear.
None of this is new. Mary and Tom Poppendieck carried Toyota’s lean manufacturing into software two decades ago in Lean Software Development: An Agile Toolkit, built on the same structure — amplify learning, decide as late as the evidence allows, and treat a big up-front specification as the waste it usually is.
Ries generalized the idea to startups; the Google Ventures team compressed it into a week.
Waterfall, the plan-it-all-then-build-it-all model these books were written to bury, is dead. Most enterprises just have not held the funeral.
Generative AI is the best thing to happen to that loop in years. It collapses the cost and the calendar of an experiment — a prototype that used to fill a sprint week takes an afternoon, a research synthesis that took days takes an hour. Lean always wanted cheap, fast experiments; the tools finally deliver them. Used well, AI does not tempt you to skip the learning. It buys you more of it, because you can run the next test today instead of next quarter.
A faster loop is only an advantage if you aim it at an outcome and put a guardrail on what it ships.
Put the guardrails in first. A loop that runs faster also fails faster, so evaluation goes in front of the ship button — automated checks, a human reviewing whatever reaches a customer, a clear definition of good before you generate anything. Done right, guardrails are not brakes on speed. They are what lets you keep your foot down without driving into a wall.
Then aim it at an outcome. Ten features shipped is a vanity number; the only question a fast experiment has to answer is whether a real metric moved — activation, retention, hours saved, revenue — for a real person doing a real job. Tie the loop to that, and generative AI becomes the fastest learning engine you have ever had. Tie it to volume, and you have automated the busywork of shipping things nobody measured.
Action items
- Run the smallest experiment that teaches you something. Break the idea into its riskiest assumption and test that first, this week.
- Put evaluation in front of the ship button. Automated checks plus a human on anything customer-facing, with a definition of good set before you generate.
- Measure the outcome, not the output. Ask whether a real metric moved for a real person, not how many features you shipped.
Resources
- Sprint, Jake Knapp, John Zeratsky, and Braden Kowitz (Google Ventures) — the five-day design sprint for testing an idea before building it.
- Lean Software Development: An Agile Toolkit, Mary and Tom Poppendieck — Toyota’s lean principles adapted to software.
Speed Comes From Approach, Not Ambition
Execution really is faster now. That part of the hype is true. But the speed that matters comes from how you approach the work, not from how much you attempt at once.
The MIT data makes the point in numbers.
Buying from specialized vendors and building partnerships reached deployment far more often than internal builds, which succeeded roughly a third as often. And the fastest movers were not the large enterprises running the most pilots and staffing the most people. They were mid-market companies that scoped the work tightly and shipped.
Ambition, measured in pilot count and headcount, correlated with getting stuck.
The output is a starting point you edit, not an answer you ship.
I have watched the same pattern up close. When I wrote a book with generative AI in the loop, the tool accelerated the parts I disliked and sped up the exploration, but the first draft was never the deliverable, and every chapter still needed a human to make it hold together.
Approach the work that way and you move fast as a vending machine for finished work and you join the ninety-five percent.
Speed is a by product of narrow scope and a real problem. It is not something you buy by attempting more.
Action items
- Buy or partner before you build. Reach for a specialized vendor first; reserve custom builds for the few places they truly set you apart.
- Scope narrow, ship, then expand. Pick a piece small enough to put in front of users this week, not a platform you unveil next year.
- Treat AI output as a draft, not a deliverable. Keep a human deciding what holds together and what reaches a customer.
Resources
- Fortune on the MIT NANDA report — vendor partnerships reach deployment far more often than internal builds.
- Patrick Neeman, writing an e-book with generative AI — AI accelerates creation while the first draft still needs a human in the loop.
Documentation for Its Own Sake Is Waste
Toyota’s production system has a word for effort that consumes resources without creating value: muda, waste. The whole method is built around removing it. Decades later, seventeen engineers met at a ski lodge in Utah and wrote the same instinct into the Agile Manifesto, which values working software over comprehensive documentation.
Not no documentation. Working software more.
Generative AI is a waste machine pointed straight at this failure mode.
It can generate a fifty-page strategy deck, a governance framework, and a model card before lunch, and none of it moves a product one inch closer to a user.
Programs stuck on the wrong side of the divide often have beautiful documentation and nothing in production. The documents became the deliverable, which is how you feel productive while shipping nothing.
The test has not changed since the assembly line. Does this document help someone or some system make a decision or do the work? If yes, write it. If it exists to prove you were busy, to survive a review, or because the model made it easy, it is waste wearing a nice cover.
AI lowered the cost of producing documents to near zero, which means the only thing keeping your shelf clear now is judgment.
Action items
- Apply one test to every document. Does it help someone or some system make a decision or do the work? If not, it is waste.
- Delete documentation that substitutes for shipping. A beautiful deck with nothing in production is the failure, not the achievement.
- Write only what the work needs. Now that AI makes documents free to produce, judgment is the only thing keeping the shelf clear.
Resources
- The Agile Manifesto — working software over comprehensive documentation.
The Job Did Not Change
Strip away the framework names and The Lean Startup was never really about startups. It was about how to act when you cannot know the answer in advance, which is the condition every team building with AI is living in right now. The uncertainty is not a flaw in your process. It is the terrain.
So the moves are the ones Ries described, and the ones Toyota’s line workers practiced decades before him. Go see the real problem before you build for it. Make the smallest bet that teaches you something, then make the next one. Let your approach, not your ambition, set your speed. Write only the documents that help someone decide or do the work, and skip the rest.
None of this requires a better model. The models are already better than the programs pointed at them. What the ninety-five percent are missing is not capability. It is the discipline to learn faster than they spend.
That discipline is fifteen years old and older. It was true when the money was chasing pets and groceries, and it is true now that it is chasing agents. The tools have changed. The job has not changed. Learn first. Build second.
What the Lean Startup still teaches us about generative AI was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.
