User feedback is what the people who use a product say about using it, whether they were asked or not.
That definition is doing one piece of quiet work. It says people who use the product, not people who pay for it, and in business software those are regularly different people.
Once you notice the gap, a lot of arguments about what to build turn out to be arguments about which of the two groups a team has been listening to.
What is user feedback?
Anything a person using the product tells you about the experience of using it, from a bug report to an offhand complaint in a support chat.
It arrives in two ways and the difference matters more than the label. Solicited feedback is what you get when you ask, through a survey, an interview or a prompt in the product.
Unsolicited feedback is what arrives because somebody was annoyed enough or pleased enough to say something without being invited. The first is easier to count and the second is usually more urgent.
How is user feedback different from customer feedback?
The user operates the product. The customer pays the invoice. In a lot of businesses they are the same person and in a lot of others they are not.
Picture a tool bought by an operations manager and used all day by twelve people on a support team. The twelve have opinions about the parts that slow them down.
The manager has opinions about reporting, price and whether the renewal is worth signing. Both sets are real. Only one of them will cancel the contract, and only the other one knows what is actually broken.
A team that hears only users builds a product people like and cannot explain to a buyer.
A team that hears only customers builds a product that demonstrates well and irritates everybody who has to open it on a Tuesday. Customer feedback is written up separately, and the interesting part of both pages is where they disagree.
Who does a feedback board actually hear from?
Whoever bothers, which is a smaller and stranger group than the word everybody.
A public board hears from people willing to write something in public under a name. That excludes the quiet majority by construction, and it is why a board is a source rather than a census.
What it does well is collapse many descriptions of one problem into one row with a count beside it, so a thing thirty people mentioned separately stops looking like thirty unrelated complaints.
The count is what a board adds, and the count is also its trap. The loudest cluster is not automatically the most valuable cluster, which is the mechanism written up as vocal minority bias.
Can you tell which users are customers?
On this product, yes, and it is the reason the voter list exists.
Every voter on a board here is a row with what you know about them attached, including the plan they are on and what they pay, once billing is connected or a spreadsheet of accounts is imported.
That turns the question of whether the twelve support agents or the one manager asked for something from a guess into a column.
The point of knowing is not to ignore the people who pay nothing. It is to stop mistaking volume for value in either direction. A request from one account paying you a lot and a request from forty accounts paying you nothing are both real signals, and they are not the same signal.
What do you do with user feedback once you have it?
Sort it by something you can defend, then tell the people who asked what happened.
The sorting is where most tools stop and most teams struggle. Ordering by raw votes is popularity. Ordering by a score somebody typed in is an opinion with a number attached.
Here the option is ordering by votes multiplied by what each voter pays, so the list moves when your paying customers act rather than when a meeting happens, and the formula behind that is published rather than described.
The second half is the one almost everybody skips. Feedback that goes in and never comes back out teaches people to stop sending it, which is the loop described on the customer feedback loop page.
14 days, a card at signup, then $9 or $39 a month.