Counting is seductive. If forty people asked for dark mode and six asked for a better export, the ranking writes itself. You sort the list, the top row wins, and you get to tell the team the roadmap is data-driven. I've built those spreadsheets. I've also watched them steer a product into a wall, politely, with everyone nodding along.
The trouble starts with what a tally actually measures. A vote count tells you how many people were willing and able to type the same thing into your feedback box. That is not how many people need the thing, or how badly, or what it's worth to the business if you build it. It measures expressiveness, filtered through whoever happened to be paying attention that month.
Think about who shows up in a request queue. Heavy users tend to fill it, because they use the product enough to hit its edges and care enough to say something. Their requests are genuine, but they come from people already committed to staying. The person who signed up, got lost on day two, and quietly closed the tab never filed anything. Whatever they needed counts as zero. So the bias runs deeper than loud over quiet. A tally structurally excludes the people you most need to hear from. I've written before about why your most engaged users make unreliable narrators, and vote counting quietly hands them the microphone.
There's also the shape of the request. Popular asks cluster around things that are easy to name. "Add a calendar view." "Let me bulk edit." These are legible, so they get repeated, so they climb. The needs that are hard to put into words, the ones that arrive as "I'm not sure, getting started just feels like a slog," don't aggregate into a tidy row. They scatter across a hundred slightly different sentences. Counting rewards the requests that show up pre-packaged and buries the ones that turn up as a vague unease, even when the unease is pointing at the bigger problem.
A number invites a second bad habit too: treating the request as the specification. Forty votes for dark mode looks like forty people who want dark mode. Some of them do. Some are squinting at a bright screen late at night and dark mode is the only fix they can name. Ship exactly what got voted for and you satisfy the literal ask while missing the reason it was asked. That gap between the request and the reason behind it is a whole subject of its own, and it's the fastest way a well-counted roadmap ends up building the wrong thing well.
None of this makes volume worthless. Ten people describing the same broken checkout in the same week is a real signal, and you should trust it. The mistake is letting the count do your thinking for you. A raw tally flattens a lot of different information down to one axis, popularity, and says nothing about who's asking, how much it matters to them, whether they'd pay for it, or whether the eight people phrasing it eight different ways are describing one need or several.
So what do you do instead of ranking? You read. Tedious, but that's where the value hides. Reading the requests rather than tallying them tells you which segment each one comes from. A feature that thirty trial users want and your best-fit customers never mention is a completely different proposition from one that three of your largest accounts keep circling back to. Volume can't see that difference. A person reading the actual words can.
Grouping by underlying need beats grouping by proposed solution, as well. "Export to CSV," "email me a weekly report," and "add a public dashboard" can all be one person trying to get numbers in front of a colleague who won't log in. Sorted by feature name, they're three small requests that each lose the vote. Sorted by what the user was trying to accomplish, they're one clear need with real weight behind it. This is roughly the work I described in deciding what to do with requests you're never going to build: the request is a symptom, and symptoms are worth more read than counted.
That reading is part of why I ended up caring about Qria, which puts open-ended answers next to the structured ones and runs an AI pass across the lot, so the themes surface from what people actually wrote instead of from a leaderboard of the tidiest requests. The same summary sits alongside your public reviews, which tend to carry the same complaints in blunter language, so a pattern is visible whether a customer typed it into your form or left it on Google.
A vote count feels like accountability. It's a defensible artefact you can point at when someone asks why a feature is or isn't happening. But the thing you can defend and the thing that's true aren't always the same, and a ranked list is very good at making the first look like the second. The requests worth building are often a few rows down, described badly, by people who didn't think to vote twice.
