Why Feature Requests Are Not Customer Needs

The feature request is the dominant form in which customer feedback reaches product teams in most organizations. A customer contacts support: "Can you add a filter to the reporting dashboard?" A sales call produces a note: "The prospect said they need a mobile app." A customer survey returns: "Easier export functionality." These are specific, actionable, and feel like clear signals from the market. They are almost always the wrong thing to build.

Not because the customers are wrong about wanting these things. But because a feature request is a customer's proposed solution to a problem they have not fully articulated — and the problem, if surfaced, almost always reveals that the feature the customer requested is not the most valuable response to it.

The Solution That Hides the Need

When a customer asks for a filter on the reporting dashboard, they are expressing a solution, not a need. The need underlying that request is something like: "I need to understand which part of my audience is converting, and right now I can't distinguish them from the noise." The filter is one solution to that need. But it might not be the best one. A different presentation of the data might make the filter unnecessary. A more fundamental restructuring of the reporting logic might address the need more completely. A different default view might solve the problem before the customer notices they have it.

This is the core of what the distinction between needs and solutions means in journey management. The customer's request is a hypothesis about a solution. The customer's need is the problem the solution is intended to address. The need is the right unit of analysis for product decisions because it is the unit that reveals the full range of solutions worth considering.

"A customer who asks for a filter is telling you they can't find what they need in the current interface. The filter is their proposed fix. Your job is to understand what they're looking for and why."

How to Uncover the Need Behind the Request

The technique is simple in principle and requires practice to execute well: ask "why" until you reach the problem that would still exist if the proposed solution were implemented perfectly.

"I want a filter on the dashboard." Why? "Because I can't find the data for our premium customers." Why does that matter? "Because premium customers are about to come up for renewal and I need to see their usage." What would you do with that information? "Decide which ones to prioritize for a success call before renewal."

The underlying need is not a filter — it is a way of identifying at-risk premium customers before renewal. The filter is one solution. An automated alert when premium customer usage drops below a threshold is another solution — one that might be more valuable because it doesn't require the customer to remember to check. A dedicated renewal dashboard that aggregates all renewal-relevant signals is a third solution.

The Implications for Discovery

If feature requests are the primary channel through which customer insights reach the product team, the team is systematically working on customers' proposed solutions rather than on customers' actual problems. This produces a roadmap full of features that individually satisfy the customers who requested them and collectively fail to address the structural experience problems that are limiting retention, expansion, and referral.

Journey management's discovery process is specifically designed to surface needs rather than solutions. The discovery questions ask: what are you trying to accomplish? Where does the current experience make that harder than it should be? What would need to change for that stage to feel effortless? These questions route around the feature request to the underlying need, producing insights that can justify a much more significant range of solutions than any individual feature request could.

The shift from feature requests to customer needs is not a methodological nicety. It is the foundation of a product development practice that addresses root causes rather than symptoms — and it is one of the most concrete contributions that journey management makes to organizations willing to take it seriously.