Collecting feedback is the easy part. Most teams have plenty of it: support threads, sales notes, a board full of requests, a survey nobody has opened since launch. What they do not have is a repeatable way to get from that pile to a decision they can defend on Monday.
This is a walkthrough of the loop that does that, with a worked example at the end. Collect, cluster, decide, ship, then say what you shipped.
Why does feedback pile up without turning into decisions?
Three things break the chain, and they are almost always the same three.
The first is that the same request arrives in five different wordings, so nothing ever looks urgent. "Can I get this as a spreadsheet", "export to Excel", "API for reporting" and "download my data" are one problem and four entries. Split four ways, each one looks like a minority ask.
The second is that nobody owns the pile. Support answers the thread and closes it. Sales notes it in the CRM. The request never becomes a product artifact anyone reviews.
The third is that feedback arrives without the context that would make it decidable. "The dashboard is confusing" is not actionable. "I open the dashboard every Monday to pull last week's numbers for a client report, and I can never find the date filter" is a change you can make this week.
Fix those three and the rest of this is mechanical.
What does organised feedback actually look like?
Not tidy. Decidable. You want to be able to answer four questions about any request in under a minute:
- How many people asked for this? Not how many complained loudest, how many distinct accounts.
- Who are they? Trial users and your three biggest customers deserve different weight, and you cannot see that from a vote count alone.
- What is the underlying job? The thing they are trying to do, not the solution they proposed.
- What did we decide, and when? Including the ones you said no to, or you will re-litigate them every quarter.
A public feedback board gets you the first one almost for free: people either vote or they do not, and the count is the count. The second is conditional — a board that lets people vote without an account, which is the setting that collects the most feedback, gives you numbers without names. If you need to weight a request by who is asking, you have to buy that with something: requiring an email to vote, authenticating voters against your app, or linking the board to your CRM. Decide which of the two you want before you turn the board on. The third and fourth are work either way.
How do you cluster requests that are worded five different ways?
Cluster by the job, not by the words. The four export requests above collapse into one entry: get my data out on a schedule. That entry now carries four voters instead of four entries carrying one each, and it moves up the list because it deserves to.
Two rules keep this honest.
Merge, do not delete. The original wording is evidence. When you merge a request into a cluster, keep the text and pool the votes, so the person who wrote it still sees their words and still gets notified when it ships. Duplicate detection helps by surfacing similar requests to someone as they type, which heads off some of the split before it happens — but it is a suggestion, not a gate, so merging afterwards stays part of the job.
Do not cluster two jobs because they share a noun. "Export to CSV" and "import from CSV" are not one thing. If you would build them in different weeks, they are different entries.
A worked example: forty notes, one shipped change
Here is the loop on a small pile, with numbers, so the shape is concrete. The numbers are illustrative, but the shape is what a real month looks like.
Collect. Over a month you gather 40 pieces of feedback: 22 from support threads, 11 submitted to the board, 5 from cancellation notes, 2 from sales calls.
Cluster. Those 40 collapse into 9 distinct jobs. The top four:
| Cluster | Distinct accounts | Where it came from |
|---|---|---|
| Get data out on a schedule | 9 | support, board, 2 cancellations |
| See who voted on a request | 7 | board |
| Slack notification when status changes | 5 | sales, board |
| Dark mode | 4 | board |
Decide. Vote count is an input, not the decision. Three things break the tie:
- Does it appear in cancellation notes? Two of the nine export askers left. That is the only cluster on the list with churn attached, and it moves to the top for that reason alone.
- Is it load-bearing for the people asking? The export askers all describe the same weekly ritual. Dark mode is preference. Both are legitimate; only one is blocking work.
- What does it cost? A scheduled export is a week. Dark mode is two days. If the cheap one were also blocking work, it would go first — small and urgent beats large and urgent.
You pick the scheduled export. Write the decision down, including why, and say no out loud to the other three. A written no is a decision. An unanswered request is a debt.
Ship, then close the loop. When it goes out, the nine people in that cluster hear about it by name, and it goes in the changelog. This is the step teams skip, and it is the step that makes the next round of feedback better: people who see their request shipped file better requests next time. People who never hear back stop filing.
Measure. One month later: did the export cluster stop generating support threads? Did the two accounts that mentioned it in cancellation notes renew? You will not always get a clean answer, but "support threads about exports went from six a month to zero" is a real result and it takes ten minutes to check.
How do you decide when the votes are close?
When two clusters are within a few votes of each other, the vote count has stopped being informative. Fall back to evidence that is not a popularity contest:
- Churn attachment. A request that shows up in cancellation notes outranks one that does not, at any vote count.
- Frequency, not volume. Something a user hits every Monday beats something they hit twice a year, even if more people asked for the twice-a-year thing.
- Whether a workaround exists. If people have found a clumsy way through, it is annoying. If they are stuck, it is blocking.
- What it unlocks. Some work makes the next three things cheaper. That is worth a discount on its vote count, but be honest with yourself about how often this argument is actually true.
Frameworks like RICE formalise this. They are useful for making the trade-off visible to other people, and they are not a substitute for having read the actual requests.
How do you keep the loop running week after week?
Make it a standing 30 minutes, not a project. Once a week: read what came in, merge the duplicates, move anything decided into a status the submitter can see, and answer the ones you are declining. A public roadmap does the rest of the communicating for you, because the answer to "are you doing X" becomes a link instead of an email.
The reason to keep the cadence tight is that stale feedback is worth less. A request from three months ago has lost its context and possibly its author. Thirty minutes a week beats a four-hour triage session every quarter, and it is the difference between a board people trust and a board people gave up on.
Frequently asked questions
What should I do with feedback I am never going to build?
Answer it and close it, publicly. "Not planned, here is why" is a complete and respectable outcome. Leaving it open forever is worse for you and for the person who asked, because you both keep re-reading it.
How many votes make a request worth building?
There is no threshold, and any number you pick will mislead you. A five-vote request that appears in two cancellation notes matters more than a twenty-vote request nobody is blocked on. Use votes to shorten the list, not to decide it.
Who should own feedback triage on a small team?
One named person, and on a small team that is usually whoever ships. The failure mode is not "the wrong person owns it", it is "everyone owns it", which means nobody reads it.
How often should I review incoming feedback?
Weekly, in a short fixed slot. Monthly is already long enough that you lose the context around a request, and quarterly triage sessions tend to get postponed.
Do I need a dedicated tool, or is a spreadsheet enough?
A spreadsheet works until you need two things it cannot do: let users vote so demand is visible without you interpreting it, and let people see what happened to their request. If you are still copying feedback into a sheet by hand, you are paying that cost weekly.
What is the most common mistake with feedback data?
Treating the vote count as the decision. It is one input, it is biased toward whoever is loud and online, and it says nothing about who is about to leave.