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.
Your sprint ends when the code merges.
That's the problem.
Merged code hasn't delivered anything to anyone. The customer doesn't have the feature until they know it exists. They don't get value until they use it. And you don't learn whether you were right until you hear back. A sprint that stops at merge declares victory before the game has started.
Velocity measures the wrong finish line
Traditional sprints measure output. Did the code get written, reviewed, merged, deployed? Success is velocity, meaning story points completed and features shipped. It's a tidy number, and it says almost nothing about whether a single customer's life got better.
You've probably seen the result. A team announces "we shipped 47 features this quarter," and nobody can name a customer who uses them. The work was real. The output was real. The value was never confirmed, because no part of the process required anyone to check.
In Customer-Led Development, the sprint has a different ending. It's built around one declaration:
The sprint ends when the loop closes, not when code ships.
"The loop closes" has a specific meaning. The customer who asked for the feature has been told it exists, has tried it, and has told you whether you got it right. Until that happens, you're not done. You're waiting.
What changes when the finish line moves
Moving the finish line forces changes upstream. If the sprint can't end until a named customer confirms value, you can't start it with an anonymous backlog. You start with customer truth instead: who asked, what they said, what you promised them.
The CLD sprint runs as a two-week cycle that begins with customer signal and ends with customer confirmation. Between those two points you prototype, put prototypes in front of the people who asked, build only what survives, and ship to those requesters first. The book walks through each phase day by day. The shape is what matters here:
| Traditional sprint | CLD sprint | |
|---|---|---|
| Starts with | The roadmap | What customers are telling you |
| Ends when | Code merges | The requester confirms it works |
| Success metric | Story points completed | Loops closed |
| Ships to | Everyone at once | The requesting customers first |
| A ticket is ready when | It's estimated | It has customer names attached |
That last row sounds bureaucratic until you try it. It's one of the most useful constraints a team can adopt.
Rule of thumb: A story without customer names isn't ready for sprint planning. Send it back.
What happens when you ship to everyone at once
The step most teams skip is deploying to the requesting customers before general availability. It feels like extra ceremony. Sonos shows why it isn't.
In May 2024, Sonos replaced its app for every customer at the same moment. The new version was missing features people relied on. These were paying customers with speakers in their homes, and the thing they used to control those speakers had gotten worse overnight.
By August, the company had cut its fiscal 2024 guidance, and CEO Patrick Spence pointed to the problems customers and partners had with the new app. By October, Sonos had restored more than 80% of the missing features and published seven commitments from an internal review. Those commitments included longer beta tests with more kinds of customers, and releasing major changes gradually so customers could respond before a change became the default. In January 2025, Spence stepped down. (Source: Sonos: Q3 fiscal 2024 results, customer quality commitments, and CEO transition announcement.)
Look at what Sonos promised after the damage was done: test with real customers longer, release gradually, let people react before the change becomes permanent. That's not a crisis playbook. It's what a customer-led sprint does every two weeks, as a routine step instead of an apology.
Shipping to requesters first isn't caution for its own sake. The people who asked for something are the ones best placed to tell you if it works, and they're the most forgiving audience you'll ever have, because you built it for them.
Every sentence has a name
The finish line changes the daily texture of the work too. A traditional standup asks what you did yesterday, what you're doing today, and what's blocking you. Those questions are about work. None of them mention a customer.
A customer-led standup asks different things: what promises did we capture, what are we validating, who are we closing the loop with? The result sounds like this:
"We captured two requests from Acme about reporting. Today I'm validating the reporting prototype with Acme's admin. BigBrand hasn't logged in since we shipped their feature last week, so I'm calling them."
Every sentence has a customer name. It takes the same fifteen minutes. And it quietly rewires what the team believes its job is.
The message that changes how customers see you
Closing the loop doesn't mean release notes. Release notes go to a mailing list. Closing the loop goes to a person:
"Hi Sarah. You asked us in February for a way to export reports to PDF. We just shipped it. Here's how to use it. Let me know if this solves your problem or if we missed something."
That takes about five minutes to write. It tells Sarah she was heard, it gets the feature used, and it gives you the one piece of data a merged pull request never can: whether you got it right.
Teams that work this way tend to feel the difference fast. Traditional sprints can feel like an assembly line that never reaches the customer: tickets in, code out, success as a number on a dashboard. When the sprint ends with a real person saying "yes, that's exactly what I needed," the work stops being abstract. You weren't completing tickets. You were helping Sarah.
So try one change before anything else. Next sprint, don't call anything done until someone with a name tells you it is.
The full day-by-day sprint, the validation questions, the planning board, and how to run your first one without overreaching are all in Customer-Led Development.
If moving your finish line from "merged" to "the customer said yes" sounds worth thinking about, subscribe to the Context Limit newsletter for more ideas like it.