A customer asks for a feature. Then another one does. Before long it feels like everyone wants it. But a handful of requests doesn't prove that customers will use it, or that it solves the problem they actually have.
Why Requests Can Mislead
Customers describe solutions, often based on tools they've used before. The problem behind the request may have a better fix. Building exactly what was asked can lead to features nobody uses.
The cost of building the wrong thing
Product analytics research cited at a 2024 industry panel found that about 20% of features drive roughly 80% of usage. UX consultant Judd Antin went further, saying that “more than 80% of features are probably not used.” Each unused feature costs a sprint you could have spent elsewhere.
more than 80% of features are probably not used.
Judd Antin, UX consultant
Find the Problem Behind the Request
Ask why
When a customer requests a feature, ask what they're trying to do. A request for “export to spreadsheet” might really mean “I need to share this report with my boss.” That problem might have a simpler fix. Ask a couple of follow-up questions. How do they handle this today? What happens when they can't do it? The answers show how painful the problem really is.
Search existing feedback
Look for the same problem in other channels, such as support tickets and survey comments. If many customers describe it in their own words, it's real. If only one account mentions it, treat it as a useful signal to watch rather than a priority. Our guide to AI theme extraction shows how to find these patterns.
The request versus the problem
What they ask for
- A solution, often from tools they've used
- “Export to spreadsheet”
What they need (the approach the article favours)
- The problem behind the request
- “I need to share this report with my boss”
- Might have a simpler fix
Validate Before You Build
Use feedback to test demand at each step:
- Count how many customers mention the underlying problem.
- Check the revenue and churn risk tied to those customers.
- Share a mockup or prototype with a few of them.
- Ask whether it would solve their problem and how often they'd use it.
Watch what people do
What customers say and what they do can differ. If you can, test with a small release or a beta group. Track whether people use the feature once it's in front of them, and for how long. A feature that gets tried once and abandoned didn't solve the problem. Even a simple test, where a new button leads to a short note about an upcoming feature, can show how many people try to use it.
Test demand before you build
- Count customersWho mention the underlying problem
- Check revenue and churn riskTied to those customers
- Share a mockupOr prototype, with a few of them
- Ask if it solves itAnd how often they'd use it
Free review snapshot
See what your customers are saying, before you talk to us.
No commitment. We use your details only to send your snapshot and follow up. Privacy policy
Decide and Communicate
Sometimes the evidence says build it. Other times it points to a different fix or a polite no. Tell the customers who asked either way. A clear “we're not building this, here's why” keeps trust better than silence. Customers who hear a clear reason often suggest a workaround or a different priority, which gives you more useful input.
Keep the evidence with the decision
Record the evidence and test results alongside each decision. When the same request comes up next year, you'll know why you decided what you did. Our post on preventing feature creep covers how to score requests consistently. You can find feedback on any request in NPS analysis, or book a demo.
Frequently asked questions
What does it mean to validate a feature request?
It means checking that a real customer problem exists and that your proposed solution would solve it before you build.
How many requests prove demand?
There's no fixed number. Look at how many customers share the underlying problem and the revenue tied to them.
Should you build exactly what customers ask for?
Not always. Find the problem behind the request and look for the best way to solve it.
How do you test a feature before building it?
Share mockups or prototypes with affected customers, or release a small version to a beta group.
Should you tell customers when you decline a request?
Yes. Explaining your decision keeps trust and shows their feedback was heard.
Where should validation evidence live?
Alongside the decision in your product tool, so future teams can see why you chose what you did.
