Most teams do not have a prioritisation problem. They have a data problem: the requests live in six places, nobody knows which accounts asked, and the spreadsheet that was supposed to fix it went stale three sprints ago. Prioritisation only becomes easy once every request has votes, an owner and a revenue number attached to it.
Stop scoring what you have not centralised
A scoring model applied to an incomplete list produces confident nonsense. Before you rank anything, consolidate intake: support conversations, sales calls, in-app submissions and internal ideas all land on one board with one set of categories.
Centralising is also what makes duplicates visible. Three tickets that each look minor are often one theme with more demand behind it than the feature you were about to build.
Weight votes by who is voting
Raw upvote counts favour whoever is loudest, which is usually your free tier. Attach plan, MRR and renewal date to each voter so a request with eleven votes from enterprise accounts outranks one with sixty votes from trials.
This is the single change that makes engineering trust the board. 'Forty-two votes' is an opinion; 'forty-two votes representing $310k of ARR, nine of it renewing next quarter' is a decision input.
Score on value, confidence and effort — nothing more
RICE, WSJF and value-versus-effort all work. What kills them is field sprawl: once a model needs nine inputs, nobody fills it in. Keep three, make two of them automatic, and let the third be a human estimate.
Re-score quarterly, not weekly. Scores that move every standup are noise, and they teach stakeholders that lobbying works.
Close the loop or the data decays
Every request that ships should notify the people who asked for it. Without that, submission volume collapses within two quarters and your board becomes a graveyard that no longer represents demand.
Linking a status change to an automatic changelog entry and voter notification is the cheapest retention mechanic in product management.
What to look for in tooling
You need account context on votes, a status model your team actually uses, and pricing that does not punish you for inviting the whole company into the conversation. Per-seat pricing quietly caps how much of your organisation can participate.
Compare how the major tools handle each of those before you commit — the differences are largely in pricing model and account context, not in whether they can render a list of ideas.