From Customer-Led Development: How to Build What Your Customers Want When AI Can Build Anything — the operating manual for building what customers want when AI can build anything. See every chapter.
For seventy years, software had one constraint that ruled all the others: engineering time.
Every methodology you've used was built to manage that scarcity. Story points rationed it. Sprint planning allocated it. Roadmaps promised it to the future. Prioritization frameworks refereed the fights over it. The whole discipline of product management grew up around a single question: what deserves our engineers?
Over the last few years, that constraint quietly collapsed. We went from story points to tokens. Most teams are still running the playbook built for the old constraint, and they're about to find out what that costs.
Everyone's a builder now
An engineer used to own a feature for a sprint. Now one engineer runs a fleet of coding agents and reviews thirty pull requests at once.
Product managers used to write specs that waited in a queue. Now they ship to production. Designers spend less time pushing pixels, because screens generate themselves from a description. Design becomes what it always should have been: taste, judgment, and knowing the user.
This isn't a forecast. Google said in April 2026 that 75% of its new code is AI-generated and approved by engineers, up from half the previous fall (Sundar Pichai Shares News from Google Cloud Next 2026). Bain's Technology Report 2026 found engineers spending 21% of their time writing code, down from 34% two years earlier, and 23% directing AI agents, up from 4%. Bain also saw product managers building prototypes and designers writing front-end code.
Building software used to be a priesthood. You needed the engineers, the engineers were scarce, and whoever controlled engineering time controlled the company. That hierarchy is dissolving in front of us. Your support rep can prototype the fix she's been requesting for a year. Your customer can build their own tool if you won't.
"We don't have the resources" used to be a fact. Now it's a confession.
"Data-driven" flipped
For twenty years, "data-driven" meant quantitative. Show me the analytics, the funnel, the A/B test.
We didn't prefer numbers because they were better. We preferred them because they were the only thing we could process at scale. What customers actually said, in calls, tickets, and frustrated emails, was richer and truer. It sat unread because no team could read a thousand conversations.
AI reads all of them. So a data-driven decision no longer sounds like "show me the dashboard." It sounds like:
- Show me the real customer insight
- Show me the sales call snippet
- Show me the support ticket
Same rigor, better evidence. The quantitative era was a compromise with our own limitations, and the limitation is gone. The richest data you own is finally usable.
The software factory
Put those pieces together and a new kind of company appears. Follow a single piece of feedback through it:
- Feedback in. Tickets, calls, usage data, churn signals.
- Triage. AI processes and clusters every signal.
- Decide. Ranked by severity, frequency, sentiment, and revenue at risk.
- Build. An agent reads the codebase, writes the spec, and opens the pull request.
- Ship. The PR goes to review or, for small and safe fixes, merges and goes live.
Then the loop runs again: shipped, watched, learned, captured.
Bugs get identified before customers report them. Fixes go out nearly immediately. The distance between "a customer struggled" and "the product got better" collapses from quarters to hours. Companies are assembling these factories right now. Every part exists. The only open question is who wires them together first in your market.
Now look at what the factory doesn't solve. Every step in that list is execution except one: Decide. Ranked by what? Decided by whom? For which customers?
The factory can build anything. It cannot tell you what deserves to be built.
The reasons customers left are gone
Think about why customers churned over the past decade. Then look at what's true of each reason today.
| Why they left | What was true then | What's true now |
|---|---|---|
| "Support was terrible." | Great support for everyone cost too many people. | Instant, informed help for every customer, with humans on the problems that deserve humans. |
| "They never built what we asked for." | Requests waited behind a scarce engineering queue. | You can build what customers want, the way they want it, in days. |
| "It didn't fit how we work." | "We don't do one-offs" was law because one-offs were expensive. | Hyper-personalized, even per-customer software is affordable. |
| "Bugs sat for months." | Fixes competed with the roadmap for engineers. | Bugs can be pre-identified and fixed nearly immediately. |
Every item in that table used to be a resource problem. None of them is anymore. From here on, each of those failures is a choice.
Churn is optional now in a way it never was before.
The new bottleneck
Free execution sets a trap. When you can build anything, you start building everything.
We already ran this experiment
We know how that story ends, because we ran it when building was expensive. Pendo's 2019 Feature Adoption Report found that 80% of features are rarely or never used, and estimated that public cloud companies collectively spent up to $29.5 billion on features that go unused. The detailed version of that report found only 12% of features generate 80% of product usage. And an IDC estimate (via LXA Hub) puts the cost of sales and marketing misalignment at 10% or more of revenue a year for B2B companies.
Those numbers come from the era of scarcity, when every feature cost weeks of engineering time and teams still wasted four-fifths of it. Now a feature costs a conversation. The waste doesn't shrink when execution gets cheap. It compounds at machine speed.
Add AI to a feature factory and you get a faster feature factory.
You can already see it happening. Technical workers surveyed in 2026 by METR, an AI research nonprofit, said AI made them about 3x faster but only 1.4x to 2x more valuable. METR traced the gap to people drifting toward tasks they took on only because AI made them cheap (METR's AI usage survey).
The speed is smaller than it feels
The most careful early study, METR's study of experienced open-source developers, found they were 19% slower with AI while believing they were 20% faster. In a February 2026 update, METR concluded the effect had likely flipped. Bain puts measured gains at the company level closer to 20% than 10x. And DORA's State of AI-Assisted Software Development ties AI adoption to more failed changes.
Code got cheaper. Deciding what to build did not.
Where the time actually goes
Bain's Technology Report 2025 estimates that writing and testing code is only 25% to 35% of the time from idea to launch. Its 2026 report found 70% of software companies still make decisions centrally, so faster code stalls before it ever reaches a customer.
So the constraint moves. Execution stopped being the moat, and judgment took its place. Deciding what to build, why to build it, and who to build it for is the new bottleneck. There is exactly one reliable source for those answers: your customers.
The DORA survey of nearly 5,000 technologists makes this concrete. AI helped teams that were focused on their users. Without that focus, in DORA's words:
"AI adoption has a negative impact on team performance."
Here's the uncomfortable part. Research summarized in John Goodman's "Basic Facts on Customer Complaint Behavior" found that only 1% to 5% of unhappy customers ever take a complaint to a manager or headquarters. The signal you need to aim the factory is the signal most companies capture worst.
Everyone builds fast now. The companies that win the next decade will be the ones that decide best.
Feature factory or product factory
"Feature factory" is one of the worst things you can call a product team. John Cutler popularized the term in 12 Signs You're Working in a Feature Factory, after a developer friend complained he was "just sitting in the factory, cranking out features." A few of his signs:
- Teams don't measure the impact of their work.
- They celebrate shipping and move straight to the next project.
- Nothing ever gets removed.
- Once something ships, the team has little contact with support, customer success, or sales.
Notice what isn't on the list: shipping a lot. Every sign describes a team that ships and never finds out what happened.
The problem was never the factory. A good factory is something to be proud of. It produces high-quality products, consistently, at the rate its customers want them. Toyota's assembly line gave every worker a cord to stop the line the moment something went wrong. Speed and quality weren't enemies; feedback connected them.
So the answer to the feature factory isn't to build less. It's a product factory: a software factory where every line ends at a named customer. Everything it ships gets measured against the people who asked for it, kept if they use it, and deleted if they don't.
Rule of thumb: if you can't name the customer a feature is for, you're running a feature factory, no matter how good your tooling is.
The feature factory earned its reputation when listening was expensive. Talking to customers, running research, following up, checking whether the last release worked: all of it took people and time, so teams skipped it and moved to the next ticket. AI made that work cheap too. Research and surveys run automatically. Every call gets transcribed and summarized. The note to every customer who asked can go out the day the feature ships. The loop the feature factory skipped can now run as fast as the build.
And your customers are asking for more, not less. Plenty of teams I talk to have a backlog seven years deep, full of things customers asked for and never got. When customers want more from you, want to buy more from you, and want to consolidate more of their work onto your product, they've given you permission to build. The question is whether you can deliver great product to them reliably, week after week.
Cutler's list still makes the best test. Two questions:
- Do you know whether your last release worked?
- Did you tell the customers who asked for it?
If either answer is no, faster code will only make the problem louder.
The choice
You can keep running the old playbook: ration engineering time that's no longer scarce, rank a backlog nobody validated, and ship features nobody asked for, faster than ever.
Or you can rebuild around the new constraint. Aim the factory with customer truth. Let the people who feel the problems drive what gets built. Close every loop.
Your runway is too short to build shit nobody wants. And for the first time in the history of software, "we couldn't build it" is not the reason it didn't get built.
Every methodology you inherited was built to manage the constraint that just died. None of them was built for the one that's left.
If you want the full system for aiming a software factory with customer truth, it's in my book Customer-Led Development.
And if this shift from story points to tokens is on your mind too, subscribe to the Context Limit newsletter for more essays on deciding well when building is cheap.