How to Prioritize Customer Feedback Without Just Counting Votes

A request sits at the top of your board with ninety-one votes. Everyone on the team already knows what happens next quarter.

That's the problem.

Ninety-one votes tells you that ninety-one people clicked a button. It doesn't tell you who they were, what it would cost to build, or whether it moves your product anywhere you wanted to go. A vote count is an input to a decision, not the decision itself.

We've written before about where feature voting works and where it breaks down, the short version is that a vote tells you someone cares, and very little else. This one is about what happens next: what to do once you're looking at several requests whose signals point in different directions, because that's the situation a scoring framework alone doesn't resolve for you.

Start with the shortlist, not the whole backlog

You don't need to score five hundred open requests. Most of them aren't close to being built this cycle, and running the full exercise on all of them is how a good process gets abandoned by its second quarter.

Pull ten to twenty candidates, whatever's realistically in contention for the next planning cycle, and do the comparison work on those. Everything else stays on the board, collecting votes and context, until it earns a spot on the shortlist.

Demand and importance are not the same question

Vote count tells you volume. It doesn't tell you who's behind it or whether it's still building.

A request can have real volume and weak importance, forty votes, evenly spread, no recent activity, nobody mentioning it in a renewal call. Another can have a fraction of the votes and be far more important, a handful of enterprise accounts, two of them tied to deals closing this month, all in the last few weeks.

Both numbers are true. They're just answering different questions, and the mistake is letting the bigger one stand in for the more important one.

The part customers can't vote on

Customers can tell you how much they want something. They can't tell you what it costs you to build, or whether it belongs in the product you're trying to become.

That's what impact, effort, and strategic fit add, not more demand data, but the other half of the decision. A request can win on every customer-facing measure and still be the wrong thing to build this quarter, because it's expensive, or because it pulls the product toward a market you already decided not to serve.

Where it gets interesting: when the signals disagree

This is the actual work of prioritization. Most requests don't need it,  the ones with high demand, clear impact, and low effort are easy calls. The shortlist is worth building because a few requests every cycle will have signals that point in different directions, and those are the ones that decide what your roadmap actually says about your product.

Take two requests sitting near the top of the board.

By vote count alone, A wins by a wide margin. Looked at across every signal, B is the better call: it's smaller to build, tied directly to renewals, gaining momentum right now, and closer to the direction the product is already heading. A isn't a bad idea, it stays on the board, keeps its votes, and can be reconsidered when the evidence changes, but it doesn't win this cycle just because it has the bigger number attached to it.

That's the comparison a leaderboard can't make for you. It takes looking at the row, not just the column everyone defaults to sorting by.

Don't average it into one number

The temptation, once you've got six or seven signals per request, is to collapse them into a single blended score so requests can be ranked again.

Resist it. A request that's a 5 on demand and a 1 on strategic fit is a genuinely different situation from one that's a 3 across the board, even if the totals land close together, and an average hides exactly that difference. The disagreement between signals is the useful part. Flattening it back into a ranking throws away the reason you looked past the vote count in the first place.

Keep the signals visible side by side, the way the table above does, and let the team actually discuss the row where they disagree. That conversation is the prioritization decision. The score is just what you're discussing.

Know when to say no

Some requests will look at this and still lose, decent demand, reasonable effort, poor strategic fit. Those need an explicit, visible "not planned, here's why," not a quiet drift toward the bottom of the board.

Leaving a popular request in limbo for two years costs you more credibility than declining it plainly. It also keeps the rest of the board meaningful,  if nothing ever gets a real answer, "planned" stops telling anyone anything.

Reassess when the evidence changes

Prioritization is a snapshot, not a permanent ranking. A request that loses this cycle can easily become the stronger candidate next time: it picks up thirty more votes, a new enterprise account starts asking, the effort estimate drops after an unrelated piece of work ships, or the roadmap shifts in a direction that suddenly makes it a stronger strategic fit.

Reassess the shortlist at each planning cycle instead of maintaining one running ranking that ages in place. The comparison you ran three months ago was right for the evidence you had three months ago. It isn't owed any loyalty once the evidence has moved.

How Loopful handles prioritization

Loopful shows top and rising requests side by side, so momentum is visible without checking timestamps by hand. Loopful lets you see demand in the context of the customers and segments behind it, so demand concentrated in a few enterprise accounts looks different from the same count spread across free trials. Impact and effort scores sit next to each request, and requests you decide against can be marked not planned with a reason attached, rather than left to sit.

The goal isn't to hand the decision over to a single number. Loopful keeps the context around each request visible, so your team can compare the signals and make the final prioritization call.

FAQ

Should votes count at all, then?

 Yes, they're still the fastest way to see raw demand. The mistake is stopping there, not counting them in the first place.

How many requests should actually get the full comparison?

 Not the whole backlog. Reserve it for a shortlist of the requests genuinely in contention for the next planning cycle, usually ten to twenty.

What if two requests still tie after comparing every signal?

 Recent momentum can be a useful tie-breaker, but also look at strategic fit, dependencies, and whether one request is tied to an immediate customer or revenue risk.

Who should estimate impact and effort?

 Impact estimates usually come from whoever's closest to the customer relationship. Effort estimates should come from whoever will actually build it. Neither should be guessed by whoever's running the comparison alone.

How often should the shortlist be reassessed?

 At each planning cycle. Treat it as a fresh comparison against current evidence, not a list you carry forward and lightly edit.