The Situation
You're collecting customer feedback. Sales shares what customers are asking for. Support shares what customers are complaining about. You're doing user interviews. You have surveys, NPS scores, feature requests. There's no shortage of input.
But when you try to turn this feedback into product strategy, it becomes chaos. Every piece of feedback feels important. The loudest voice wins. You end up building features that satisfy individual customers but don't create coherent strategy.
The problem isn't that you don't have enough feedback—it's that you don't have a way to turn feedback into strategy. Feedback is data. Strategy is decisions. You need filters, not backlogs.
What Most Teams Try (and Why It Doesn't Work)
Most teams try to organize feedback better, but this doesn't solve the real problem.
Building a feedback backlog
If you're collecting feedback in a backlog, you're treating it as a todo list. But feedback isn't a todo list—it's information. You need to synthesize it into strategy, not execute it as tasks.
Prioritizing by volume
If you're prioritizing by how many customers asked for something, the loudest voice wins. But the loudest voice isn't always the right voice. You need to understand why customers are asking, not just what they're asking for.
Building what customers ask for
Customers are good at describing problems, but they're not always good at describing solutions. If you build what customers ask for, you'll build features that solve symptoms, not problems.
How I Approach This in Practice
I turn feedback into strategy by focusing on patterns, constraints, and decision filters—not individual requests.
Look for patterns, not requests
Individual feedback is noise. Patterns are signal. Instead of building what one customer asked for, look for what multiple customers are trying to solve. The pattern reveals the problem, not the request.
Understand constraints, not just desires
Customers describe what they want, but they don't always describe what they can't have. Understand the constraints that are driving the request. What can't they do? What's blocking them? The constraint reveals the real problem.
Create decision filters, not backlogs
Instead of collecting feedback in a backlog, create filters for evaluating feedback. Does this align with what you're optimizing for? Does this fit within your constraints? Does this solve a pattern, not just a request? Use the filters to make decisions, not to organize tasks.
Focus on problems, not solutions
Customers describe solutions, but you need to understand problems. What problem are they trying to solve? Why is it important? What happens if it doesn't get solved? The problem guides strategy, not the solution.
A Real Example
A B2B SaaS company collecting feature requests from customers. They had hundreds of requests, prioritized by volume. The loudest customers got their features built, but the product felt scattered. No coherent strategy.
Instead of a backlog, we created decision filters: Does this align with what we're optimizing for? Does this solve a pattern across multiple customers? Does this fit within our constraints? We used the filters to evaluate requests, not to prioritize them.
When we looked for patterns instead of requests, we found that customers were asking for different features to solve the same problem. We built one feature that solved the pattern, not ten features that solved individual requests.
The outcome wasn't a better backlog—it was clearer strategy. We still listened to customers, but we synthesized their feedback into decisions, not tasks.
When This Matters
This approach works when:
- You have lots of feedback but unclear strategy. You're collecting input but not synthesizing it into decisions.
- The loudest voice is winning. You're building what individual customers ask for instead of solving patterns.
- Feedback feels like a todo list. You're treating feedback as tasks to execute, not information to synthesize.
This approach doesn't work when:
- You don't have enough feedback. If you're not talking to customers, that's a different problem. Get feedback first, then synthesize it.
- Feedback is actually clear. If customers are consistently asking for the same thing and you know why, you might not need filters. But this is rare.
- You're using feedback to avoid decisions. If you're collecting feedback because you can't decide, that's a different problem. Fix the decision-making first.
Related Session Notes
If you're dealing with unclear product direction, Why Most Roadmaps Don't Actually Guide Decisions might be relevant. Or if you're trying to create clarity on priorities, Product Intake Without Sales Hijacking It addresses similar challenges.