Are customer feature requests always telling us what customers actually need?
When someone asks for a feature, it's tempting to assume they've already identified the solution to their problem.
But sometimes the request is only one possible way to solve something deeper.
For example, a customer might ask for another dashboard when what they're really struggling with is knowing which information deserves their attention.
I can see two approaches.
1. Build what customers request. They've experienced the problem firsthand, and responding quickly can strengthen trust.
2. Investigate the problem behind the request. You might discover a simpler solution or something that benefits more customers.
The challenge is knowing when to take a request literally and when to investigate further without making customers feel unheard.
For founders who've experienced this, have you ever discovered that the problem behind a feature request was different from what the customer originally asked for? What changed your understanding?
Replies
Yes, and reading other people's reviews made it clearer than my own requests did. Before deciding what to add to my song app, I read about 200 public reviews of AI music apps. The requests came in many shapes: change the lyrics, edit one line, swap the voice, fix a section. Grouped, they were one need: keep the song I already like, change one thing. One reviewer put the real problem plainly, fixing one part damages the others. Nobody asked for "stable regeneration", but that is what every request was about. So my rule of thumb: take the request literally as evidence, but group requests by what the person is afraid of losing, not by the feature they named.
I'd designed my kanban and Gantt as separate pages and thought that was better. Then one user asked to switch views in place. I checked, saw Notion and Asana both already did it, and shipped it the same day. What changed my mind was seeing the request matched what people already expect from other tools.