Product feedback: how to collect it, sort it and act on it
Product feedback arrives through support, sales, email and your app. This guide shows how to bring it into one place, turn requests into problems you can solve, decide on a rhythm and tell people what happened.
The hard part of product feedback is rarely getting it. It is having one place where it all ends up, and a habit of doing something with it. A request mentioned on a sales call, a complaint in a support ticket and an idea someone typed into your app are often the same request in three different words, and nobody sees that until a customer asks why nothing happened.
This guide walks through a product feedback process that a small team can run in an hour or two a week: where feedback comes from, how to collect it in one place, how to turn requests into problems you can solve, how to decide and how to reply.
What counts as product feedback
Product feedback is anything users tell you about what your product does or should do:
- Feature requests: “I wish I could share a notebook with someone outside my team.”
- Bug reports: “Export fails when a note has an image in it.”
- Friction and complaints: “It takes me five clicks to find last week’s notes.”
- Questions that reveal a gap: “Is there a way to pin a note?” usually means there isn’t one.
- Praise, which tells you what not to break.
It is narrower than customer feedback, which also covers billing, support quality and the rest of the relationship. Keep the two apart: a slow support reply is a real problem, but it does not belong on your product roadmap.
There is one more source that users never write down: what they actually do. Nielsen Norman Group’s long-standing advice is blunt about the gap between the two: “pay attention to what users do, not what they say”.Source [1] Written feedback is still valuable. It tells you what people struggle with and in what words. Treat the solution a user proposes as a hint, and look for the problem underneath it.
Where product feedback comes from
Before you build a process, list every place feedback arrives today. For a B2B software product it might look like this:
| Channel | Who hears it | What usually happens to it |
|---|---|---|
| Support tickets and chat | Support | Answered, then forgotten in the ticket history |
| Sales and success calls | Sales, account managers | Written in a CRM note or a call summary |
| Email to the founder or team | Whoever receives it | Stays in one person’s inbox |
| A form or widget in the app | Product | Collected, often without the user’s context |
| Community, social, review sites | Marketing | Noticed when it is loud |
The point of the table is the last column. Feedback is rarely lost because people ignore it. It is lost because it lives in five systems and no one counts it.
Step 1: one place for every request
Pick a single home for product feedback and make every channel feed it. A shared spreadsheet works for a while; a feedback board works better once more than a handful of people are involved, because users can find an existing request and vote on it instead of writing a new one.
Three rules keep that place useful:
- Record the source and the person. When support or sales hears a request, they add it (or add a vote) on behalf of the customer, so that person can be told later what happened.
- One request, one post. Search before posting, and merge duplicates as soon as you spot them, keeping every vote and follower on the post you keep.
- Make it easy for users to reach. A link in your help menu or a widget inside the product brings feedback to you in the moment people feel the friction, not days later.
Step 2: turn requests into problems
A request like “add a calendar view” is a solution. Before you can judge it, you need the problem: maybe the person plans meetings in your app and cannot see what is due this week, or maybe they want to print a schedule for a client. Two people asking for the same feature can have different problems, and one feature might not solve either.
When a request arrives without context, ask one question in a comment:
- “What were you trying to do when you missed this?”
- “What do you do today instead?”
- “How often does this come up?”
Our feature request guide has a template that asks these questions up front, so fewer requests need a follow-up.
Step 3: sort it so patterns show
Sorting is what turns a pile of posts into something you can decide on. Keep it light:
- Status: every request should say where it stands, for example Open, Under review, Planned, In progress, Shipped or Closed. A status is a promise to the person who asked that someone has looked.
- Area tags: a handful of tags for parts of the product (editor, sharing, mobile) let you see which area collects the most friction.
- Who is asking: note the segment, such as plan, company size or role, when you have it. Ten requests from trial users and ten from your largest accounts mean different things.
Votes help, but read them carefully. A vote count measures demand among the people who found your board and chose to vote. It does not count customers who never visit the board, and it favours ideas that are easy to explain over problems that are hard to describe.
Step 4: decide on a rhythm
Feedback is only useful if it changes decisions. A rhythm keeps that from depending on anyone’s memory:
- Weekly triage (30 minutes). Go through new posts: merge duplicates, ask the missing question, set a status and tag. Nothing new should be older than a week without a status.
- Monthly review (an hour). Look at the most requested problems by area and segment, next to your own plans. Move a few requests to Planned, and close the ones you will not do.
- Quarterly check. Compare what you shipped with what users asked for. If none of it overlaps, either your direction or your board needs attention.
Saying no is part of deciding. A request that sits in Open for a year tells its voters you are not listening; a request closed with a clear reason tells them you are.
Step 5: reply and close the loop
The last step is the one teams skip: telling people what happened. When a request moves to Planned, ships or is closed, everyone who asked, voted or followed it should hear about it. That reply is what makes people give feedback again. We cover it in detail, with message templates for each status, in How to close the customer feedback loop.
If your plans are public, a public roadmap does part of this job, and a changelog with links to the requests it shipped does the rest. Our changelog tool checklist covers what to look for.
Mistakes to avoid
- Treating votes as the roadmap. Votes are one input; your strategy, the problems behind the requests and the effort involved are others.
- Collecting without answering. A board full of unanswered posts is worse than no board: it shows users their input goes nowhere.
- Keeping internal notes on public posts. Discuss customers, revenue and estimates in private notes, not in public comments.
- Letting one channel win. If only the loudest channel reaches the board, your view of demand follows whoever is loudest.
A weekly product feedback routine
Copy this into your team’s calendar invite:
- Open the board, filter to posts with no status.
- Merge duplicates and keep their votes.
- Ask one clarifying question where the problem is unclear.
- Set a status and an area tag on everything else.
- Reply to any request that changed status since last week.
- Note the top three problems by area for the monthly review.
How UpVoiced fits
UpVoiced, which we are building, is a feedback board, public roadmap and changelog in one place. Users post and vote on a portal in your brand or from a widget inside your app; your team triages everything in a keyboard-first inbox, with similar-post hints that cut duplicates and merging that moves votes to the post you keep. When a status changes, everyone who voted, commented or followed gets an email. See how the widget works or the whole loop.
UpVoiced is in development and not open for sign-ups yet. You can look around a fictional demo board and request early access.