# Feedback Board Triage Rubric

How to read a public feedback board without letting it write your roadmap.
From saasfeedback.ai — https://saasfeedback.ai/blog/feedback-board-for-saas

---

## The bias you are correcting for

A public board samples the 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 1–3% of your user base, and it systematically excludes
the group whose opinion is most predictive of revenue: the people who already
left.

Boards are not wrong. They are unrepresentative in a known direction. This rubric
corrects for the known direction.

---

## Step 1 — Score every request on four axes

| Axis | Question | Scale |
|---|---|---|
| **Vote weight** | How much MRR is behind the votes, not how many votes? | £ sum |
| **Silent corroboration** | Does this theme also appear in churn conversations, support tickets, or sales-lost notes? | 0 = board only, 1 = one other source, 2 = two or more |
| **Requester fit** | Are the requesters in the segment you have decided to win? | 0 = no, 1 = mixed, 2 = yes |
| **Solution confidence** | Do you know what problem this solves, or only what they asked for? | 0 = feature only, 1 = problem understood |

**A request scoring 0 on silent corroboration should not enter the roadmap on
board evidence alone**, no matter how many votes it has. High votes with zero
corroboration usually means one enthusiastic power user rallied a thread.

---

## Step 2 — The four quadrants

|  | **High votes** | **Low votes** |
|---|---|---|
| **High corroboration** | **Ship it.** The board found something real. This is the board working. | **Investigate.** Silent, expensive problem your engaged users have worked around. Often the best item on the list. |
| **Low corroboration** | **Interview before building.** Loud minority. Talk to five requesters and five non-requesters. | **Log and leave.** |

The bottom-left quadrant is where boards earn their keep — and it is the
quadrant no board UI surfaces, because the whole interface is sorted by votes.

---

## Step 3 — 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:

| Posted as | Rewrite as |
|---|---|
| "Add a Zapier integration" | "Users need [product] data in tools we don't integrate with. Which tools, how often, and what breaks today?" |
| "Dark mode" | "Users work in this for long sessions in low light" — or, quite often, "users think we look dated" |
| "Bulk edit" | "A recurring task costs N clicks × M times per week" |
| "Better reporting" | Unusable as written. Go ask three requesters what they exported last. |

If you cannot write the problem statement, you have not earned the right to
build the feature.

---

## Step 4 — What to do with the board publicly

**Do:**
- Reply to every request within a week, even with "not now, here's why".
- Merge duplicates aggressively; a fragmented board understates real demand.
- Publish what you shipped and link back to the request that prompted it.
- Close requests you will never do. An honest no beats indefinite "under
  consideration", which readers correctly interpret as no anyway.

**Don't:**
- Publish vote counts as if they were a roadmap ranking. You are training your
  users to campaign, and campaigns favour whoever has the biggest Slack
  community, not whoever has the biggest problem.
- Promise dates on the board.
- Let the board be your only intake. If board volume is your main feedback
  source, your product decisions are being made by your 2% most vocal users.

---

## Step 5 — 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.

- **Items on both lists** → highest confidence work in your company.
- **On the board, not in churn** → engagement features. Real, but rarely
  revenue-critical.
- **In churn, not on the board** → the list that matters most, and the one that
  is invisible if the board is all you read. These are the problems people leave
  over rather than complain about.

The third column is the entire argument for collecting feedback from people who
have already gone. Nobody files a feature request on their way out the door.