Feedback Boards for SaaS: Useful Tool, Terrible Roadmap
A public board is a good customer-relations tool and a bad prioritisation instrument. The difference matters, because most teams use it as both.
Public feedback boards are genuinely useful. They give customers somewhere to put an idea, they cut duplicate support tickets, they make a small company look responsive, and they occasionally surface something nobody internally had thought of.
The problem starts when the vote count gets treated as a priority ranking. Because at that point you have handed your roadmap to a sample with a known, severe, and entirely predictable bias.
A board samples people who are (a) still customers, (b) engaged enough to log in, (c) comfortable posting in public, and (d) motivated enough to type. That is typically one to three percent of your users. It systematically excludes the group whose opinion best predicts revenue: the people who already left.
Nobody files a feature request on their way out the door. Every board is, structurally, a survey of people who stayed.
TL;DR
- Boards are excellent at customer relations and duplicate deflection, and unreliable at prioritisation.
- The sample is your most engaged 1–3%, which is the group least likely to churn — the exact opposite of who you need to hear from.
- Vote counts measure campaigning ability, not demand. Weight by MRR behind the votes, not by vote count.
- The four-quadrant triage: votes on one axis, corroboration from churn and support on the other. Low-vote/high-corroboration is where the best items hide.
- Never put a request on a roadmap in the words it was posted in. Rewrite it as a problem statement first.
What Boards Are Genuinely Good At
Worth stating clearly, because the rest of this article is critical and the criticism is narrow. A public board does four things well:
- Deflects duplicate tickets. “Already tracked, here's the thread” is a real support saving.
- Gives an idea somewhere to go. Customers who have somewhere to put a thought stop putting it in a renewal call.
- Signals responsiveness. A board with recent replies makes a small company look attentive, and that impression is not fake — replying is attentive.
- Surfaces the occasional genuine unknown. Rare, but it happens, and the items are usually oddly specific.
None of those are prioritisation. Every one of them is customer relations, which is a legitimate reason to run a board — just not the reason most teams give.
The Sampling Bias, Stated Precisely
1–3%
Typical share of users who ever post or vote
4
Filters a user passes before their vote is counted
0
Board posts written by users who already churned
~90%
Of your revenue signal, invisible to the board
Four filters compound before a vote exists. The user must still be a customer; must be engaged enough to be logged in; must be comfortable posting under their name in public; and must care enough to write. Each filter is individually reasonable. Together they select for a very specific person: the enthusiast.
Enthusiasts are wonderful customers and terrible proxies. They have already worked around your rough edges — that is why they are still here — so the things that would have made them leave are invisible to them now. They request refinements to a product they have mastered.
The people best positioned to tell you why customers leave are, by definition, not on your feedback board. They churned, and churning users do not file tickets. They just stop.
This is the same structural problem that affects in-app surveys, NPS, and session replay — six of the nine tool categories covered in the feedback tools breakdown can only see people who stayed.
Votes Measure Campaigning, Not Demand
The moment a board is public and vote-sorted, you have created an incentive to campaign. Customers with Slack communities, active user groups, or agency clients can mobilise dozens of votes for an item that matters to one organisation.
This is not cynicism about customers — it is a completely rational response to the interface you built. If votes determine what gets built, of course people will gather votes.
| What you think a vote count measures | What it actually measures | |
|---|---|---|
| Demand | How many customers need this | How many engaged users saw the post |
| Value | How much revenue depends on it | How well the requester can organise |
| Urgency | How badly it is needed now | How long the post has been up |
| Breadth | How widely felt the problem is | Whether it was worded in a way people recognised |
The minimum correction is to weight votes by the MRR behind them rather than counting heads. Ten votes from $20 accounts and one from a $2,000 account are not the same signal, and neither ranking is automatically right — but you should at least be choosing which one you mean.
Cagan's long-standing objection to feature-request-driven roadmaps applies almost word for word to vote-sorted boards: customers are excellent at describing problems and unreliable at specifying solutions, and a board collects solutions.
The Four-Quadrant Triage
The fix is not to close the board. It is to stop reading it alone. Score every request on two axes: vote weight, and whether the same theme appears in a second source — churn conversations, support tickets, or sales-lost notes.
| High votes | Low votes | |
|---|---|---|
| High corroboration | Ship it. The board found something real. | Investigate. Often the best item on the list. |
| Low corroboration | Interview before building. Loud minority. | Log and leave. |
The interesting cell is low votes, high corroboration: a silent, expensive problem that your engaged users have already worked around and your departing users left over. It is frequently the best item on the board — and it is the one no board UI will ever surface, because every board interface is sorted by votes.
Equally: a request with high votes and zero corroboration should not enter the roadmap on board evidence alone, however many votes it has. Talk to five requesters and five non-requesters first. Two of those conversations usually settle it.
Feedback Board Triage Rubric
The four-axis scoring sheet, the quadrant map, the request-to-problem rewrites, and the monthly correction ritual.
- Four scoring axes: vote weight, silent corroboration, requester fit, solution confidence
- The quadrant map and what to do in each cell
- A request-to-problem rewrite table for the four most common posts
- Public board hygiene: what to do and what never to promise
- The monthly ritual that compares board items against churn themes
Translate Requests Into Problems
Never put a request on a roadmap in the words it was posted in. Rewrite every item before it enters planning — and if you cannot write the problem statement, you have not earned the right to build the feature.
| Posted as | Rewrite as | |
|---|---|---|
| Integration | "Add a Zapier integration" | "Users need our data in tools we don’t integrate with. Which tools, how often, what breaks today?" |
| Appearance | "Dark mode" | "Users work in this for long sessions in low light" — or, often, "users think we look dated" |
| Efficiency | "Bulk edit" | "A recurring task costs N clicks × M times per week" |
| Reporting | "Better reporting" | Unusable as written. Go ask three requesters what they last exported. |
The dark mode example is worth dwelling on, because it is the one where the rewrite most often changes the decision. Roughly half the time the underlying problem is genuinely about eye strain in long sessions. The other half, it is a proxy for “your product looks old” — and shipping dark mode does not fix that.
Running the Board Publicly Without Making Promises
Reply to everything within a week
Even “not now, here's why”. An unanswered board is worse than no board — it publicly documents that you are not listening.
Merge duplicates aggressively
A fragmented board understates real demand, which is the one direction of error that hurts you rather than the customer.
Close what you will never do
An honest no beats indefinite “under consideration”, which readers correctly interpret as no anyway, but with added resentment.
Publish what shipped, linked to the request
This is loop closure, and it is the highest-return thing on the board. People who see their input land will post again.
Never promise dates in public
A date on a public board is a commitment to everyone who reads it, including people who have not bought yet.
Customers are reliable narrators of their problems and unreliable specifiers of solutions. A feedback board collects solutions. That is not a flaw in your customers — translating a problem into the right change is the job you were hired for, and it is the one part they genuinely cannot do for you.
The Monthly Correction Ritual
Once a month, pull the top ten board items and the top ten themes from churn conversations. Put them side by side. Three columns emerge:
| Column | Meaning | What to do |
|---|---|---|
| On both lists | Highest confidence work in the company | Ship it. This is the easy decision. |
| Board only | Engagement features. Real, rarely revenue-critical. | Batch them. Ship a few per quarter for goodwill. |
| Churn only | The list that matters most | This is your roadmap. It is invisible without churn data. |
The third row is the entire argument for collecting feedback from people who have already gone. If your board is your only intake, that column is empty and you will never know it was supposed to have anything in it. Building the churn side of the ledger is what the churn feedback guide covers, and the seven-stage system shows where a board fits inside a complete setup.
Frequently asked questions
- Should my SaaS have a public feedback board?
Probably yes, for customer relations — it deflects duplicate tickets, gives customers somewhere to put an idea, and makes replying visible. Just do not treat the vote ranking as a roadmap. Run it as a communication channel with a triage rubric behind it, not as a prioritisation instrument.
- Public board or private feedback collection?
Public boards are better for community and worse for honesty — people moderate what they say under their own name next to their company. Private collection gets more candid answers and gives up the deflection benefit. Most teams should run both, with the public board for ideas and a private channel for the reasons people leave.
- How do we handle a feature request we will never build?
Close it, publicly, with the reason. Not “great idea, we'll consider it” — an actual no with an actual explanation. Customers do not expect to get everything they ask for; they expect to be told. The indefinite “considering” state is read as a no with extra steps, and it costs you the credibility an honest refusal would have earned.
- Do vote counts on a feedback board predict churn?
No, and often inversely. The people voting are your most engaged users, who are the least likely to churn. A heavily-voted item usually indicates enthusiasm, not risk. To connect feedback to churn risk you need the requests weighted by revenue and corroborated against what departing customers actually said.
Sources & further reading
- 1The nature of product — Marty Cagan — Silicon Valley Product GroupOn why customer-requested feature lists make poor roadmaps.
- 2First Rule of Usability? Don’t Listen to Users — Nielsen Norman GroupWhy stated preferences and actual behaviour diverge.
- 3SaaS Retention Report — ChartMogulRetention benchmarks for weighting board items against real revenue risk.
Keep reading
The column your board can never fill.
saasfeedback.ai collects the themes that only churned users can tell you — the ones nobody posts on a board. Compare them against your board next month.
Book a demo