How to prioritize user feedback when you can't build everything

Short answer: put all feedback in one place, group it by the underlying problem rather than the requested feature, and score each problem by how many people it affects, how badly, and how much effort it takes to fix. Fix bugs and confusion that block people first, then work on what moves your main goal. Say no (politely) to the rest, and tell people what you changed because of them.

Why can't I just build what users ask for?

Users are great at describing problems and poor at designing solutions. "Add a dark mode" might mean "the app hurts my eyes at night"; "add a tutorial" might mean "I don't understand the main screen". If you build every request literally, the app grows complicated and the real problem may stay unsolved. Your job is to find the problem behind each request.

How do I collect feedback in one place?

Feedback arrives everywhere: store reviews, email, social media, Discord, feedback sites, testers. Pick one place to collect it, like a spreadsheet, a task board or a notes database, and give every item:

• The original words, copied or linked.
• Source and date.
• Type: bug, confusion, request or praise.
• Device and version for bugs.
• The problem behind it, in your own words.

Once a week, move everything new into this list. It takes 20 minutes and stops feedback from getting lost.

How do I group feedback?

Group by problem, not by request. For example, these three messages:

• "Can you add a search bar?"
• "I can never find my old notes."
• "Please add folders."

are all one problem: people can't find old content. Grouping shows you how many people share a problem even when they describe it differently, and gives you freedom to choose the best fix.

How do I score what to work on?

For each problem group, give a quick score from 1 to 3 on four questions:

Question	Low (1)	High (3)
Reach: how many users does it affect?	A few	Most users
Impact: how bad is it?	Mild annoyance	Blocks a core task or causes data loss
Goal fit: does fixing it support your current goal?	Unrelated	Directly
Effort: how much work is the fix?	Weeks	Hours

Add the scores (effort counts higher when the work is smaller). You don't need precise math; the point is to compare problems side by side instead of reacting to the loudest message.

How often should I review the list?

A steady rhythm beats occasional big clean-ups:

• Weekly (20 minutes): add new feedback, group it and update counts.
• Before planning each release: look at the top-scored problems and pick a few that fit the release goal.
• After each release: check whether the problems you fixed stopped appearing in new feedback. If they didn't, the fix missed the real cause.
• Every few months: archive old items that nobody has raised again, so the list stays readable.

If you work with others, review the list together. Hearing a teammate say "I've seen that complaint five times this week" adds context no spreadsheet captures.

What should always come first?

Some things skip the queue:

• Crashes and data loss. Nothing else matters if the app loses people's work.
• Security and privacy issues.
• Problems in the first minutes, such as sign-up, onboarding and the main screen. If new users get stuck, they never reach the features others are asking for.
• Payment problems. If people can't pay or don't get what they paid for, fix it immediately.

How do I handle feedback I won't act on?

Saying no is part of the job. Be honest and kind:

• Thank the person and restate their problem so they know you understood.
• Explain briefly why it isn't planned now, for example "we're focused on making sync reliable first".
• Keep it on the list. If more people raise the same problem later, its score goes up.
• Never promise dates you aren't sure about.

How do I close the loop?

People give more and better feedback when they see it matters:

• Reply when you fix something someone reported: "Thanks, this is fixed in 2.3."
• Mention fixes in release notes in plain language.
• Thank your community publicly (with permission) for reports and ideas that shaped an update.
• Reply to public reviews calmly and specifically when an issue they raised is fixed.

What mistakes should I avoid?

• Letting the loudest user decide. One angry email is one data point.
• Counting requests instead of problems.
• Ignoring silent users. People who quit rarely write. Watch where users drop off and run small usability tests too; see how to run a usability test.
• Building in secret. Share what's coming so people know their feedback was heard.

Next steps

Set up your feedback list this week, group what you already have and score the top ten problems. Need more input? List your app on TrueLaunch, where every review answers what worked, what could be better and which bugs showed up, and read how to get honest feedback on your app.