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.
Every feature should trace to a specific customer name. Not a persona. Not a segment. Not "enterprise users" or "power users" or "our ICP." A name: Acme Corp. TechCo. Sarah at BigBrand.
That sounds like a small bureaucratic rule. It isn't. It's the difference between building for people and building for a slide.
The question your sprints never ask
Agile got a lot right. Iterate instead of big-bang releases. Ship working software. Respond to change. Keep a sprint rhythm that forces you to actually finish things. If you lived through what came before it, you know it was a real improvement.
But Agile is a method for how to build. It's nearly silent on who you're building for, and it stops paying attention the moment code hits production.
You can run perfect sprints, hit every velocity target, close every story, and still build things nobody uses. This isn't hypothetical. Pendo's The 2019 Feature Adoption Report found that 80% of features are rarely or never used. Across the industry, that adds up to billions of dollars of engineering time poured into software that just sits there.
Here are the four questions Agile never required you to answer:
| Question | Typical Agile answer | Customer-led answer |
|---|---|---|
| Who are we building for? | "The customer" | Named customers on every story |
| Why did we build it? | It was next in the backlog | A specific request or promise, in their words |
| Did they know we built it? | Not our job. Done at deploy. | The requester hears about it directly |
| Did it work for them? | Velocity looked good | The people who asked use it and confirm it solved the problem |
What a name changes
A persona can't disagree with you. It can't tell you that you misunderstood the workflow, that the button is in the wrong place, or that they already switched to a competitor. Personas are endlessly agreeable, which is exactly why they're dangerous.
A name has a phone number. When you ship, you can call. When you're unsure, you can ask. When it flops, someone specific will tell you why.
Watch what happens in a planning meeting when the first question about any proposed feature becomes: "Which customers?" If the answer is a segment, you've learned something important. You're looking at internal opinion dressed up as customer insight. Often it's the highest-paid person's opinion, wearing a persona as a costume.
Rule of thumb: If you can't name the customers who need it, you're not ready to build it. Send it back to validation.
The tea carts
The clearest example of this I know comes from Amazon, a company big enough to hide behind segments if it wanted to.
In his 2015 Letter to Amazon Shareholders, Jeff Bezos wrote that 90% to 95% of what AWS builds comes from what customers tell Amazon they want. Customers were frustrated with the cost and licensing of commercial databases and couldn't get the performance they needed from open-source ones. They asked AWS to remove the trade-off. The result was Aurora, which became the fastest-growing service in AWS history.
But the part that sticks with me is smaller. A team in India took tea carts through 31 cities over four months. They served 37,200 cups of tea and talked with more than 10,000 small sellers. The sellers kept saying the same thing: getting online was slow and complicated. So Amazon built a mobile studio that could get a seller online in under an hour.
Notice what they didn't do. They didn't commission a segmentation study of "SMB merchants in emerging markets." They went to where the sellers were, poured tea, listened to the same complaint thousands of times, and fixed it. The feature traces to real people because the team physically stood in front of them.
Customer-Led Development, in one breath
Customer-Led Development (CLD) isn't a replacement for Agile. It's Agile with the missing piece. Keep your standups, your sprints, your retros. CLD adds a customer layer that makes them mean something:
- Capture: every customer signal, including sales promises, support tickets, and usage, gets into a system product can see.
- Connect: those signals get synthesized into patterns, with every promise tracked from "we can do that" to "it's live."
- Close: the customer who asked hears "You asked for X. We built it. Here it is." Then you check whether it actually worked.
That last pillar is the one most teams skip, and it's the most important. Shipping isn't the finish line. The loop closes with validation, not deployment. A feature the requester never hears about is, from their side, a feature that doesn't exist.
Which leads to the chapter's bluntest claim:
Every churned customer is a failure to listen. Churn is optional.
You can argue with "optional." Some customers leave for reasons you'll never control. But treat churn as inevitable and you stop looking for the request you ignored, the promise sales made that quietly died on a spreadsheet, the fix you shipped that nobody told them about.
A one-hour gut check
Before adopting any of this, try one thing. Pull up the last ten customers who left. Find what they asked for before they went. Did you build it? If you did, did they know?
Most teams find the answer uncomfortable. That discomfort is the gap Customer-Led Development exists to close.
The full system, including the manifesto, the three roles, the metrics that replace velocity, and what a customer-led sprint looks like day by day, is in Customer-Led Development.
If you want more essays on building for named people instead of imaginary personas, subscribe to the Context Limit newsletter.