Upvotes are useful evidence, but they are not a product strategy. The most-voted request often serves the loudest segment, not the most valuable problem — and roadmaps built on votes alone drift toward incremental tweaks while strategic bets starve.

Prioritization works better as an explicit scorecard: a small set of signals, weighed in the open, so every decision can be explained to the customer who asked and the executive who questions it.

Why vote counts mislead

Voting portals reward whoever shows up. Power users, free-tier tinkerers, and organized interest groups vote far more than busy enterprise buyers — yet the quiet accounts often carry the revenue and the deepest workflow pain.

Participation bias

A fraction of users ever vote, and they rarely match your revenue mix.

Solution fixation

Votes pile onto specific fixes, hiding the shared problem underneath.

No cost signal

Voting is free, so nothing distinguishes a nice-to-have from a blocker.

Recency distortion

New and heavily campaigned requests outrun older, deeper needs.

Example

A dashboard export collects 240 votes from free-tier users. Meanwhile, six enterprise accounts quietly churn over missing audit logs.

Vote-only prioritization ships the export. Revenue says otherwise.

The five-signal scorecard

Score every grouped problem — never raw requests — on five signals from 1 to 5. Keep the scale coarse on purpose: fine-grained numbers create false precision and endless debate.

Scorecard rubric
signals:
  reach: # how many customers feel this pain
    1: single account
    3: a clear segment
    5: most of the base
  severity: # cost of leaving it unsolved
    1: annoyance with a workaround
    3: painful, workaround is costly
    5: blocker, churn risk
  strategy: # fit with where the product is going
    1: off-direction
    3: neutral
    5: accelerates the roadmap
  urgency: # time pressure from renewals, deals, regulation
    1: no deadline
    3: tied to a renewal or launch
    5: blocking revenue now
  effort: # cost to build and maintain, inverted
    1: multi-quarter project
    3: a focused sprint or two
    5: days, mostly configuration

score: reach + severity + strategy + urgency + effort
rule: discuss anything above 18, park anything below 12scorecard.yaml
Problem groupReachSeverityStrategyUrgencyEffortTotal
Audit logs for compliance3545320
Dashboard CSV export5221515
Dark mode for reports4121412

The table does what votes cannot: it makes the trade-off legible. Anyone can see why audit logs beat the export, and the export’s supporters can see exactly what would change the outcome.

Score problems in one workshop

Run scoring as a short, recurring ritual — not a quarter-long process. One hour, one cross-functional group, one batch of grouped problems.

The weekly scoring workshop

1
Present the problemRead the customer's words first. No solutions on the table yet.
2
Score silentlyEveryone scores all five signals at once. Silence kills anchoring.
3
Debate the gapsOnly discuss signals where scores differ by two or more points.
4
Record and notifyLog the score, the decision, and tell every linked account.

Workshop agenda, 60 minutes

0 of 5 done

Say no without burning trust

Most prioritization output is rejection — the scorecard earns its keep in how clearly you can explain it. Tailor the message to the audience, but never change the reasoning.

Rejection templates that keep the door open

  • Reference their specific use case and renewal context.
  • Show where their problem scored and which signal held it back.
  • Offer the workaround plus a named contact for updates.
  • Keep it short: what you decided and the one main reason.
  • Link the public roadmap so they can watch for movement.
  • Invite them to add context that would change the score.
  • Share the full score breakdown, not just the verdict.
  • Name what would need to change for a different outcome.
  • Agree on a re-review date instead of relitigating weekly.

Explain decisions with

  • The score and the signal that decided it
  • Customer evidence anyone can inspect
  • A concrete re-review trigger

Never hide behind

  • “Not enough votes” as the whole reason
  • Vague promises of “maybe someday”
  • Silence while the request goes stale

Traps to avoid

If an executive can overrule the rubric without new evidence, the team stops scoring honestly. Overrides need written reasoning attached to the record.
Ten duplicate asks split the demand signal ten ways. Group first, then score the group — otherwise the math punishes popular problems.
Adjust weights between cycles based on outcomes, never mid-debate to favor a pet project. Changing the ruler during measurement destroys trust.
They hold the severity and urgency evidence. A product-only workshop scores on guesses.

A prioritization system is a communication system. The score matters less than the fact that everyone — customers included — can see how it was reached.

From signal to roadmap

EV
EvidenceGrouped problems
SC
ScoreFive signals
DE
DecideDiscuss, commit
TE
TellClose the loop
Building ACME

Have a feedback workflow that feels harder than it should?

We are building ACME to help SaaS teams collect feedback, understand customer demand, plan roadmaps, and close the loop.

Tell us about your workflow →