A user once told me, with real conviction, that our app needed a "duplicate" button on every screen. Not one button. Every screen. He'd worked out precisely where each one should go and sent a numbered list. It would have been a fortnight of work and it would have made the interface look like a photocopier.
I nearly built it, because he was articulate and specific and clearly frustrated, and specific frustration is persuasive. What stopped me was a dull follow-up question: what are you actually doing when you reach for that button? Turned out he was rebuilding the same weekly report from scratch every Monday because there was no way to save a template. He didn't need a duplicate button on every screen. He needed to stop starting from zero every week. One of those is a fortnight of work. The other is a "save as template" link in a single place.
That gap, between the solution a person hands you and the problem sitting underneath it, is the most useful and most ignored thing in customer feedback. People don't send you problems. They send you solutions, because a solution is easier to describe. "I want X" is a complete sentence. "Something about my Monday mornings feels heavier than it should" is not, so nobody writes it down, even though it's the more honest report.
There's an old line about customers asking for a faster horse when what they wanted was to get somewhere sooner. It usually gets quoted to justify ignoring users, which is the wrong lesson to take from it. The lesson worth keeping is smaller and more practical: the request and the need live at different depths, and your job is to travel between them. The person asking for a faster horse was telling you something true and valuable, that getting from here to there takes too long and they hate it. That's the need. "Horse" was just the only vehicle they'd ever seen. Dismiss the horse and you look clever. Dismiss the underlying complaint and you miss the whole point.
Digging without interrogating
The move is to ask about the situation, not the solution. When someone requests a feature, the reflex is to evaluate the feature: can we build it, should we, where does it go on the list. A better first question points backwards. What were you trying to do right before you thought of this? What happens now, without it?
Those questions feel almost rude in their simplicity, but they shift the conversation from the person's proposed fix to the actual event that triggered it. And the event is where the truth is. A feature request is a memory of a moment of friction, translated into product language by someone who doesn't build products for a living. The translation loses information every time. You're trying to recover the original. This is the unshowy middle of collecting feedback from the people who use your software: the request is the easy part to capture and the least useful part to act on directly.
It's also why asking the right thing at the right moment beats asking more. A question fired right after the friction happened catches the situation while it's still fresh. A question sent three weeks later gets you the person's tidied-up theory of what they wanted, which has drifted toward whatever solution they've since talked themselves into.
When the stated ask is the right one
Sometimes the horse is just a horse. Not every request hides a deeper need, and treating every piece of feedback as a riddle to decode is its own kind of failure. If a user says the button is hard to find and the button is genuinely hard to find, believe them and move the button. The skill is telling the two apart, and the tell is usually depth of consequence. "The button is in an odd place" is a shallow, self-contained problem. "I keep having to redo my work" is not, and requests wrapped in that kind of ongoing pain almost always have something bigger behind them.
The messy part is that users often bury the consequence and lead with the fix. You get "add a duplicate button" and have to work back to "I rebuild my report every week." That excavation only happens if the feedback channel gives people room to explain themselves, which is why open text still earns its place even though it's harder to sort through than a rating scale. The friction that made someone reach for a solution usually shows up in the words around the request, not in the request itself.
That's the practical reason I ended up caring about tools that keep the open-ended answer attached to the structured one. Qria runs an AI summary across both the forms you send and the public reviews that land on Google or Trustpilot, so the situation behind a stack of differently worded requests tends to surface without you rereading every single one. The signal you want is often in the sentence a customer wrote before they got to their suggestion.
None of this is complicated, which is maybe why it stays rare. It takes longer to ask "what were you actually doing" than to drop the requested item into a backlog and move on. But a backlog full of literal requests is how you end up with a product that does exactly what forty people asked for and still feels like it's fighting the person using it. The needs were in there the whole time. They just didn't arrive labelled as needs.
