Why can't users describe what they need?

THE SHORT ANSWER

Users are great at telling you where it hurts but bad at prescribing the medicine. They know their problems deeply because they live with them every day, but the solution they suggest is limited to what they know is possible, which is usually a slightly better version of what already exists. Before the iPhone, people asked for better Blackberry keyboards, not a touchscreen app platform. So treat feature requests as symptoms, not specifications: dig into the why behind every request, prototype the underlying problem's solution, and use feedback as input, not direction.

There is a Steve Jobs line that gets quoted too much and understood too little: "people don't know what they want until you show it to them." Most people hear that and think it means ignore your users. That is wrong. It means users are great at telling you where it hurts, but bad at prescribing the medicine.

Feature requests are symptoms

When a user says "I need a date filter on this dashboard," what they are really saying is "I cannot find what I am looking for." The filter might help. Or you might need to rethink how the data is surfaced in the first place. The trap is that feature requests feel like clear direction, so it is tempting to just build them. But when you do that across a whole roadmap, you end up with a patchwork of fixes rather than something coherent. I spent a year at one company where the entire roadmap was driven by customer requests funneled through sales. We shipped 40+ features. Churn did not move. The product got more complicated and nobody's core problem was solved.

The gap between problem and solution

Users know their problems deeply. But the solution they suggest is limited to what they know is possible, which is usually a slightly better version of what exists. Before the iPhone, people asked for better battery life and a nicer keyboard on their Blackberry. Nobody was asking for a touchscreen app platform. That did not mean they did not need it. In PM work this shows up constantly: users ask for more detailed analytics because they cannot find insights, but the fix might be better visualization or surfacing key metrics automatically, not more data.

What I do instead

I still talk to customers every week. That will never change. But I changed what I do with what I hear.

Dig into the why. What are you trying to accomplish? Why is the current approach not working? If you could wave a magic wand, what would be different about your day? These get you past the surface request into the actual problem.

Prototype before you plan. Instead of writing a spec based on what users asked for, build something that solves the underlying problem in a way they have not seen. AI tools make this fast. You can have a working prototype in a couple hours, then put it in front of customers and watch. The reaction to a real thing is completely different from the reaction to a mockup. People push buttons. They say "wait, can it also do this?" That is where the real product insights live.

Use feedback as input, not direction. Customer feedback is one signal among many. It sits alongside usage data, market trends, competitive moves, and product vision. The job is to synthesize all of it into a direction, not to build a backlog sorted by vote count.

This week, take one recurring feature request, ignore the surface ask, and prototype a solution to the problem underneath it. Then show it to the customer who asked. Listen to everything. Build what matters.

SOURCES

THE LONG VERSION

RELATED ANSWERS

Last reviewed 2026-07-31 · 3 min read