Every open request in your inbox is a vote for a different roadmap, and none of them arrive pre-ranked. The fix isn't a bigger spreadsheet or a louder Slack channel, it's three questions asked of every request before it's allowed onto the list: which customers, weighted by what they'd actually do if you said no, how many independent sources said the same thing, and what business outcome changes if you build it. Requests that can't answer all three don't get ranked yet. That's not a soft no, it's an honest one.
Counting Requests Rewards the Wrong Signal
The instinct when requests pile up is to tally them: whichever feature got mentioned the most times this month wins the next sprint. That feels objective because it's a number, but the number measures the wrong thing. A request count tells you who talked, not who mattered. Ten free-tier users mentioning the same nice-to-have in a support ticket can outscore two enterprise accounts 30 days from churning over a gap that's actually costing revenue, purely because ten is bigger than two.
Frequency looks like consensus, but it's really just measuring who happened to be vocal that week. A method that can't tell "loud" from "load-bearing" will always drift toward whichever segment emails the most, which is rarely the segment paying the most or closest to leaving.
Weight the Customer Before You Weight the Request
Not every voice asking for the same thing carries the same consequence if you ignore it. Before ranking requests, rank the customers behind them on one axis: what happens if this account doesn't get what they asked for. A customer 30 days past a usage cliff, already flagged in a churn interview, carries more weight than a customer who mentioned a feature once in a demo call and never brought it up again. This isn't about favoring your biggest logo by default, a small account that's a perfect fit for where you're trying to grow can outweigh a large one that's a poor strategic match. This mirrors the shift toward revenue-weighted feature prioritization that more product teams are adopting instead of counting votes at face value.
Customer weighting is the practice of ranking a feature request by the real consequence of ignoring the customer behind it, not by that customer's size or how recently they asked. A request from a churn-risk account with a named contract date carries more weight than one from an account that's merely active, regardless of which one asked first or asked twice.
Independent Sources Beat Repeat Mentions From One Account
The second filter catches a different failure mode: one loud account asking for the same thing five times across five channels looks like five data points, but it's one opinion with five delivery mechanisms. Count sources, not mentions. A support ticket, a sales call transcript, and a churn interview from three separate accounts is three independent signals. Five Slack messages from one customer success manager relaying the same client's ask is one signal, no matter how many times it gets forwarded.
This distinction matters most when a request feels urgent because it's recent and repeated. Recency and repetition from a single source produce the same emotional weight as genuine consensus, without being consensus. The check is simple: can you name three different accounts, in three different conversations, independently landing on the same ask? If the honest answer is one account said it several times, that's useful context, not ranking evidence.
Tie Every Request to an Outcome, Not a Feeling
The third filter is the one most teams skip because it's the most uncomfortable to apply honestly: what measurably changes, for the customer or for the business, if this ships. "It would be nice" and "customers keep asking" are both feelings, not outcomes. A real outcome names a number: renewal risk removed for a named account, a support ticket category that drops to zero, a stated blocker in a sales cycle that closes. If nobody can name what changes, the request isn't ready to rank, regardless of how many people mentioned it.
Worked Example: Four Requests, One Table
Here's the three-filter method applied to four requests a small team might actually be holding at once:
| Request | Customer weight | Independent sources | Tied outcome | Rank |
| Bulk CSV export | 2 accounts, one 30 days past a usage cliff, contract renewal in 6 weeks | 3 (2 support tickets, 1 churn interview) | Removes a stated blocker to renewal for both accounts | 1 |
| Slack integration | 1 account, mid-tier, no renewal risk flagged | 1 (a single Slack thread, same account, mentioned twice) | Unclear, no stated workflow change named | 4 (not ranked this round) |
| Custom dashboard views | 4 accounts, none at risk, all on growth plans | 4 (4 separate support tickets, 4 different accounts) | Reduces a support ticket category that's grown 20% this quarter | 2 |
| Dark mode | Mixed, no specific accounts named | 0 (mentioned in a general survey, no named source) | None stated | Not ranked |
Notice the ranking doesn't reward volume. The Slack integration only has one voice behind it, however often that voice repeats itself, and it drops out this round. Dark mode never had a named customer or source in the first place, so it never enters the ranking at all rather than getting a low score anyway.
What This Replaces: Feature Voting Boards and Ticket Tallies
Most feedback tools default to a version of a voting board: customers or internal teams upvote requests, and whatever has the most votes floats to the top. That's a real improvement over pure gut-feel, but it inherits the same flaw as manual tallying, a vote is still just a count, blind to who cast it or what's actually at stake if it goes unanswered. Even RICE, one of the most widely used prioritization frameworks, runs into this same ceiling: its reach and impact scores are only as honest as the evidence feeding them. Feedback repositories are built to collect and organize requests, not to weigh them against each other, which is a different job entirely.
| Method | What it counts | What it misses |
|---|---|---|
| Manual tally / spreadsheet | Raw mention frequency | Who's asking, and what's at stake if ignored |
| Feature voting board | Votes, often one per account | Consequence of the account behind each vote |
| Customer-weighted, source-checked ranking | Weighted consequence, independent sources, tied outcome | Nothing that can't be named and sourced makes the list |
The Information Gain: Requests That Never Get Ranked Are a Feature, Not a Gap
Most prioritization advice treats an unranked backlog as an unfinished job, something to eventually score and slot in. The three-filter method treats "not ranked yet" as a legitimate, permanent state for a request that can't name a weighted customer, an independent source, or a tied outcome. That's the proprietary part of this approach: the goal isn't to eventually rank everything, it's to make the unranked pile visible and honest, so the team stops quietly treating "mentioned a lot" as equivalent to "worth building." A backlog with forty unranked, unsourced requests sitting openly in a queue is more useful than a backlog where all forty got a fake score just to make the spreadsheet feel complete.
This is close to what P8's decide layer does with customer signal: it doesn't try to force every piece of feedback into a ranked decision. It surfaces what has enough weight and evidence to act on this week, and leaves the rest visibly, honestly unranked until it earns its place.
Running the Filter Without It Becoming a Full-Time Job
The three filters only stay useful on a cadence that survives a busy week, not as a one-time cleanup:
- Log every request with its source and account as it comes in, not in a batch review weeks later when details have blurred.
- Apply the filters weekly to new requests only, so the check stays under twenty minutes.
- When a request clears all three and ships, write one line on what actually happened to the tied outcome, so you can check a quarter later whether the weighting was any good.
- Let requests sit visibly unranked rather than forcing a score just to clear the queue. The next independent source might be the one that qualifies it.
Want your customer calls, tickets, and requests turned into a ranked list with the sources attached, instead of a spreadsheet you fill in from memory? Ask P8 for your first brief.
Product capabilities described reflect P8's current approach, not a guarantee of specific features.
