Why voice-of-the-customer programs stall at the routing step, the agent-driven flow I'd pilot instead, and 4 books on making discovery stick.
Nothing that arrives through a voice-of-the-customer program is news to the team that owns the feature. I’ve now watched that be true at 4 companies, and recently one of our design leads put it more precisely than I have: almost nothing that comes through the door is something we don’t already know. The question is what makes us act on it, and the answer is volume. A request moves onto a roadmap when enough people say it loudly enough, in a public enough place, that someone senior notices. Everything below that threshold sits in a spreadsheet.
The spreadsheet in this case is a good one. A design leader on my team just finished a consolidated list of customer requests across the whole product, sourced from support, sales, our customer advisory board, and the community. The next question was the one that kills these programs: how do we operationalize it? We talked through the standard answers, and both of us had seen each of them fail. Protected capacity, where every squad reserves a slice of engineering time for customer-sourced fixes, holds for a quarter and then gets eaten by the big priority. Quotas, where every squad commits to closing a few items per quarter, invite the smallest possible items. And in the meantime the intake fragments, everywhere I’ve seen it: support teams log requests in 3 separate lists, and an onboarding specialist who never heard about the other 2 starts a fourth.
Almost nothing that comes through the door is news. The question is what makes us act, and today the honest answer is volume.
Here’s the reframing that this leader helped me land on this week: These programs don’t fail at listening, and they don’t really fail at prioritization either, because the priorities are both data and customer backed. They fail at routing. A request comes in with no data attached, no owner attached, and no starting point, so acting on it costs a squad a full discovery cycle they didn’t budget. The threshold for action is high because the cost of action is high.
So the pilot I’d run lowers the cost of action, and it’s built out of pieces that exist now. An agent that reads every intake source, deduplicates, and tags by product area. A second step that routes each item into the tracker for the squad whose engineering lead signed off on the last related fix, because the codebase already knows who owns what even when the org chart is fuzzy. A third step where a coding agent takes a first crack, a V1 patch or a prototype, before a human has spent a minute. Then a review, by the squad, sized and stack-ranked against the roadmap like anything else. That’s where the 10 to 15 percent of capacity actually goes: reviewing drafted fixes rather than discovering them from scratch. And because the same agent reads the public communities, it can flag when a theme is building before it reaches the escalation stage, which is the moment these programs should have been catching all along.
The shelf
He broke the work into the right 4 problems, and I’ll leave them here for anyone building a version of this. Consolidate the data into one place. Assess it so a human, or an agent, can make a decision on it. Get the work picked up, by a team or a tool. Verify it was done right and tell the customers who asked. Most programs I’ve seen solve the first and stall on the second, and never get near the third.
I build and maintain clinical software, so the requests in that spreadsheet are usually 3 sentences from a therapist about a step that costs them time with a client. Knowing about it for 2 years is worse than not knowing. This is the work I’d rather be doing with agents than any demo.