Why feature voting boards fail (and what to do instead)
The feature voting board is the most intuitive feedback tool there is: put ideas on a public page, let customers vote, build the top of the list. Teams adopt one, watch it work for a quarter, and then watch it slowly become a liability — a graveyard of stale requests with a top ten they have no intention of building.
The failures aren't random. They're structural, and worth understanding before you decide what role, if any, a board should play.
“export is broken for us”
“any update on SSO?”
“we hit the rate limit again”
Read + clusteredFailure 1: votes measure popularity, not value
The first page of a board gets more votes than the second, and already-popular posts attract more votes simply because they're visible — herd behavior, not independent signal. Savio's rundown of voting board downsides and Jason Evanish's essay both land on the same point: you end up making expensive build decisions on popularity among board users, a population that skews toward your most online customers and away from your largest ones. Ten votes from free-tier users and one quiet email from your biggest account are not ordered the way the board orders them.
Failure 2: customers vote on solutions, not problems
A board entry is a proposed solution ("add a Gantt view"). The valuable feedback is the problem underneath ("I can't see which projects will slip"). Votes without comments strip exactly the qualitative context you'd need to build something better than what was asked for — Productboard's own post-mortem on voting forums makes this point from the perspective of a company that ran one. Voters also can't see your strategy or the engineering cost, so the ranking they produce ignores both.
Failure 3: most feedback never reaches the board
Real feedback arrives as a sentence in a Slack channel ("is there any way to export this? kind of a dealbreaker for our finance team"), a support ticket, a remark on a sales call. Asking that person to also go find your board, search for an existing post, and vote is a conversion funnel, and most feedback doesn't convert. Customers who do visit tend to vote on what's already listed rather than adding what they actually need. The board becomes a sample of a sample.
Failure 4: the public backlog becomes a public liability
Everything on the board is a permanent public statement. Competitors can read it as a list of your gaps. Customers can read the timestamps: a top-voted request sitting at "Open" for three years says "we don't listen" louder than having no board at all. Declining a request in public is awkward, so teams don't, and the ambiguity curdles.
What to do instead
Capture feedback where it already happens. Instead of asking customers to come to a board, collect the requests already occurring in Slack, Discord, support tickets, and sales calls. This gets you the full population of requests with their original wording and context — the problem statements that boards strip out.
Count requesters, not votes. Deduplicate the same request across channels and keep the list of who asked, with segment and revenue attached. "Export to CSV: 19 requesters, 4 enterprise accounts, one renewal at risk" is a decision-grade input; "Export to CSV: 214 votes" is not. Full disclosure: we build Modem, which does this capture-and-count automatically instead of running a board — what it builds underneath is a context graph linking each request to the requesters and accounts behind it — so we have an obvious position here — but the manual version (a spreadsheet and a tagging habit) delivers the same shape of signal at low volume.
Close the loop directly. The one thing boards do well is notify voters on status changes. You can keep that property without the board: because you know who asked for each thing, you can tell exactly those people when it ships, in the channel where they asked. That's the mechanism described in close the loop, and it's more personal than a status flip.
If you keep a board, keep it as one channel. Boards still fit products with genuine vote-driven communities — public-roadmap devtools, games, consumer apps — and tools like Canny do that pattern well (our comparison covers where each fits). The failure isn't having a board; it's treating the board as the feedback system rather than one input among several. Weigh its votes accordingly, and prune it ruthlessly so it never shows three-year-old open requests.
The smallest version this week
Skip the board decision entirely for now. Create one spreadsheet, spend 30 minutes pulling every feature request from the last month of support tickets and Slack into it, deduplicated with requester names. Compare that list to your board's top ten, if you have one. The gap between the two lists is the argument this guide has been making.
