You decide which customer feedback to act on by running each request through five filters before it reaches your roadmap: how often it shows up across unrelated customers, whether the person asking fits your actual ICP, what it costs to build relative to what it's worth, how easily you could undo it if you're wrong, and whether anything beyond the request itself backs it up. Feedback that clears all five earns a build. Feedback that clears one or two earns a "noted" and nothing more.
Most founders don't have a feedback problem. They have a filtering problem. The requests keep arriving, fine. The failure is upstream of the backlog: nothing stops a well-phrased ask from a friendly customer looking exactly as urgent as a pattern showing up across forty accounts.
Why "loudest voice wins" is the default, not a choice
Nobody sits down and decides to prioritize by volume of enthusiasm. It happens because the alternative, a real filter, takes discipline that's easy to skip when someone's on a call telling you their exact problem in vivid detail.
A customer who calls, emails twice, and pings you on LinkedIn about the same request has generated three data points that feel like three separate signals. It's one person. Meanwhile the eleven customers who silently worked around the same friction and never said anything generated zero data points and don't show up anywhere. Recency bias does the rest: the request from this morning's call outcompetes the pattern buried in last month's support export, not because it matters more but because it's more available.
The customers who speak up are a biased sample of the customers you have. A filter that only asks "how strongly did someone want this" inherits that bias by design, the same way ranking calls, tickets, and analytics by which one feels most convincing does in which signal wins when your evidence disagrees.
The five-filter pass
Run every request through these in order. A request that fails filter one usually doesn't need filters two through five: you've already got your answer.
1. Frequency, not intensity. Has this shown up from customers who don't know each other? One passionate ask is an anecdote. Three unconnected customers describing the same friction in different words is a pattern. Count distinct accounts, not distinct mentions: the same customer raising it four times is still one data point.
2. ICP fit. Is the person asking inside your actual target segment, or adjacent to it? A request from your best-fit customer and an identical request from someone who was never going to renew anyway are not the same signal, even though they read identically in a support ticket. This is the filter most founders skip, because it feels rude to weight a paying customer's request by how good a fit they are. Skip it anyway and you'll optimize for the customers you're about to lose instead of the ones you're trying to keep.
3. Build cost versus stated value. What does this actually cost, not in story points, in weeks of a founder's attention that could go somewhere else? Then: does the value described match that cost, or is a two-week build being justified by a nice-to-have? Founders post-seed rarely have a real cost-tracking system for this; a rough gut-check split into "days," "weeks," or "quarter" is enough to stop a small request from quietly becoming a big one.
4. Reversibility. If you build this and it turns out to be wrong, how expensive is undoing it? A config flag or copy change is cheap to reverse and can clear a lower evidence bar. A schema change or a pricing model shift is expensive to reverse and should need corroboration from more than one source before it moves.
5. Independent evidence. Does anything besides the request itself support it? A support ticket that lines up with a usage-analytics dip, or a call request that a competitor's changelog also seems to be addressing, is a corroborated signal. A request that exists only because one person said it out loud is still worth logging, just not worth building on its own.
Continuous product optimization is the practice of treating prioritization as a standing, evidence-checked filter rather than a one-time roadmap exercise. Every new signal gets run through the same criteria instead of being ranked by how recently or loudly it arrived.
Scoring the five filters
Most requests don't need a spreadsheet. They need five yes/no checks and a decision rule for what a passing score actually means.
| Filter | Passes when... | Fails when... |
|---|---|---|
| Frequency | 3+ unconnected accounts raised it independently | Only one account, or repeated asks from the same account |
| ICP fit | Requester matches your defined target segment | Requester is a poor-fit trial or an account you expect to churn regardless |
| Cost vs. value | Stated value plausibly exceeds the build cost | Cost is vague, open-ended, or clearly outweighs the described benefit |
| Reversibility | Cheap to undo if wrong (copy, config, a flag) | Expensive to undo (schema, pricing, core workflow) |
| Independent evidence | A second, unrelated source corroborates it | The request stands alone with nothing else pointing the same way |
A request that passes frequency and ICP fit but fails the other three isn't dead. It's a candidate for the cheapest, most reversible version of the fix, not the full build the customer originally described. A request that fails frequency outright, regardless of how it scores elsewhere, goes in the log and waits for corroboration. It doesn't go in the sprint.
What this filter doesn't do
It doesn't replace judgment, and it doesn't produce a single objectively correct answer. Two founders applying the same five filters to the same request can land in different places if they weight ICP fit differently, or if one of them has a higher risk tolerance on reversibility. That's fine. The point of the filter isn't to remove judgment, it's to make the judgment visible and repeatable, so the same request evaluated in March and again in September gets a consistent answer instead of whichever one felt more urgent that week.
It also doesn't work as a one-time exercise. Feedback keeps arriving after the roadmap is set, and a filter that only runs during planning misses everything that shows up in between, which is most of it. The founders who get the most value from this run it continuously against whatever's landing that week, not quarterly against a backlog that's already stale.
The gap this exposes
Here's what a five-filter pass surfaces that most teams don't expect: most of what's sitting in a support inbox or a call-notes doc fails filter one before it gets anywhere near cost or reversibility. Not because the requests are bad, but because nobody ever checked whether they were isolated or part of a pattern, since checking requires pulling together calls, tickets, and analytics that usually live in three different tools with three different owners.
That's the actual bottleneck. The five filters are simple. Running them consistently against every new piece of feedback, across every source, without someone manually cross-referencing three systems every time a request comes in, is the part that breaks down. P8 for founders covers how that cross-referencing gets automated once you're past the point of doing it by hand in a spreadsheet.
FAQ: How do you decide which customer feedback to act on?
Does the most frequent request always win? No. Frequency is the first filter, not the only one. A high-frequency request that fails ICP fit (asked for mostly by customers outside your target segment) still shouldn't jump the queue over a lower-frequency request from your best-fit accounts.
What if a request only came from one customer, but that customer is your biggest account? Treat single-account requests as a starting hypothesis, not a decision. Check filters three through five (cost, reversibility, and independent evidence) more carefully than usual, since you don't have frequency to lean on. A cheap, reversible fix can still be worth doing on one account's say-so. An expensive, hard-to-reverse one shouldn't be, no matter how important the account.
How is this different from a RICE or ICE score? RICE and ICE score initiatives you already believe are worth comparing against each other. This filter runs earlier: it decides whether an individual piece of feedback deserves to become an initiative at all. Most requests that clear this filter are small enough that they don't need a full RICE pass; the ones that don't clear it never reach that stage.
Related reading: how to decide what to build next after getting it wrong for years covers the decision brief this filter feeds into once a request clears all five checks.
Product capabilities described reflect P8's current approach, not a guarantee of specific features.
