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
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.
Get Patrick Neeman’s stories in your inbox
Join Medium for free to get updates from this writer.
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.