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 product team knows the ritual. A customer asks for something. Someone opens a research project, interviews get scheduled, personas get updated, and six weeks later a deck argues about whether the thing is worth building. Six months later, maybe, the customer sees it.
That ritual made sense once. It doesn't anymore, and most teams haven't noticed.
Research was always insurance
Traditional user research exists for one reason: building used to be expensive. When a feature cost six months and five engineers, you validated first. Research was a premium you paid to avoid wasting execution.
But execution isn't expensive anymore. "Our teams can now dream up an idea one day and have a functional prototype the next," Reddit's chief product officer, Pali Bhat, said in a McKinsey & Company piece on AI-enabled product development.
When the build costs days, the insurance costs more than the thing it insures. So invert it.
The inversion: Ship Research
Ship Research means you stop studying whether customers want something and start putting a real, working version in front of the specific people who asked for it. Not a Figma file. Not a fake door. A real feature, in production, behind a flag, visible only to the requesters.
Then you watch. If they use it, you iterate and expand. If they don't, you delete it and move on.
On my own team, this is now the default. It's genuinely cheaper and faster to build something and validate it with the customers who asked than to set up research and run clickthrough prototypes that only simulate the real thing.
Three ideas make this work:
- The prototype is the survey. Interviews measure what people say. A shipped feature measures what they do. There's no persona standing between you and the truth.
- Silence is a finding. In traditional research, non-response is a gap you fill with more research. Here, non-usage is the most definitive answer you can get.
- Validation is delivery. The same McKinsey & Company article argues AI erases the strict line between discovering an opportunity and testing whether it's viable.
And there's a humbling reason not to trust the deck anyway. When Microsoft ran controlled experiments, only about a third of ideas improved the metric they were built to move; at Google and Bing, 10% to 20% did, according to Ron Kohavi and Stefan Thomke in The Surprising Power of Online Experiments. Even experts misjudge which ideas will pay off. If they can't call it, neither can your research.
The Etsy lesson: ship in pieces small enough to kill
Dan McKinley, who worked on Etsy's search team, tells a story that captures both the danger and the discipline.
The team decided to add infinite scroll to search results. More items, loaded faster: obviously better. So they designed and built the whole thing before testing anything.
It wasn't better. People who got infinite scroll clicked fewer items, saved fewer favorites, and bought fewer items from search. The team spent a month hunting for bugs that would explain it. Only then did they test the two assumptions underneath the project. Neither held up. Etsy removed the feature.
For the next redesign, the same team did something different. They shipped ten to fifteen small releases, dropped the pieces few people used, and kept the rest. Sales of vintage items rose almost 4%. (McKinsey's essay on it is Design for Continuous Experimentation.)
Notice: both projects shipped to real users. The difference wasn't shipping versus researching. It was shipping one big bet you'll defend versus shipping small pieces you're willing to kill.
Rule of thumb: never spend six weeks studying a question you could answer in six days by shipping.
Discipline, not recklessness
Cheap to build doesn't mean cheap to own. Google's DORA / Google Cloud State of AI-Assisted Software Development report ties AI adoption to more failed changes. That's exactly why Ship Research goes first to the few customers who asked, behind a flag, and not to everyone.
It also isn't for every request:
| Ship it to requesters when… | Slow down and validate first when… |
|---|---|
| The ask is concrete ("export reports to PDF") | The problem is fuzzy and the solution space is wide |
| The blast radius is small and easy to remove | It touches money, security, or data you can't un-ship |
| A working version costs days, not weeks | Being wrong in production would damage trust |
Most teams will find more of their backlog fits the left column than they'd like to admit. That discomfort is the point.
There's one more prerequisite, and it's the one that quietly breaks most attempts: you have to know exactly which customers asked for what. If customer conversations are scattered across sales calls, support tickets, and someone's memory, you can't ship to the requesters, because you don't know who they are. You can't close a loop in a week if you don't know whose loop you're closing.
The new question
The old question was: how much validation do we need before we build?
The new question is: how fast can we put a real answer in front of the customer who asked?
Waterfall made customers wait years. Agile got it down to quarters. Ship Research waits a week.
Stop researching whether customers want it. Ship it, and let them show you.
The full chapter goes further: the five-step loop, how it compresses a standard discovery sprint, the metrics that replace "interviews conducted" (like Ask-to-Ship Time and Kill Rate), and a day-by-day plan for running your first cycle.
If you want the whole system for building what customers actually use, including the complete Ship Research loop, it's in Customer-Led Development.
And if this idea of letting behavior outvote opinion stuck with you, subscribe to the Context Limit newsletter for more essays that fit in your head.