Usero Journal

The Loud 1% Are Not Your Users.

Q: Do feedback portals work?

Feedback portals work for publishing your roadmap and deduplicating common requests, but they fail as a primary way to learn what users want. The vast majority of users never post on them, so the board over-represents a small group of vocal power users. The highest-signal feedback, the problems driving churn and poor activation, usually arrives through support threads, cancellation flows, and session replays instead. Use a portal to show decisions, not to make them.

Q: Why don't users post on feedback boards?

Posting on a feedback board is real work done in public. A user has to leave their task, write a clear title and description, and attach their name to it in front of other users. Most people won’t do that, so they abandon the request, mention it to a colleague, or simply leave. The result is that boards capture the small, confident minority and miss the silent majority who churn without a word.

Q: What's the alternative to a feature request board?

The alternative is signal-first feedback collection: actively hunting for involuntary feedback instead of waiting for users to file it. That means reading support threads for repeated questions, adding an open text box to your cancellation flow, watching session replays of users who dropped off, logging direct DMs and Slack messages, and tracking the questions prospects ask on sales calls. You can still keep a public roadmap and changelog as a publishing surface, just don’t treat the board as your main intake.

Q: Why is session replay better than a feedback portal for finding problems?

Session replay captures what users do when they aren’t trying to give feedback, which is where the most valuable signal lives. It shows rage-clicks, dead-end pauses, and the exact step where onboarding loses people, none of which users can articulate in a written request. A feedback portal only captures the voluntary, performed feedback that a small minority chooses to write down. Replays catch the symptoms users feel but can’t name.

Q: Is Canny worth it for a small team?

Canny is a polished feature request board, but it removed its free tier in 2023 and now starts around 79 dollars a month, with most teams landing closer to 359 dollars. For a small or bootstrapped team, that’s a steep price for what is fundamentally a publishing surface for your roadmap. Cheaper boards like Featurebase (from about 49 dollars) or Frill and Nolt (from about 25 dollars) cover similar ground. The bigger question is whether a board should be your primary feedback channel at all, since most users never post on one.

Q: How should you prioritize feature requests if not by votes?

Prioritize by evidence of impact on activation and retention, not by vote counts. Vote totals only measure popularity among the small group already posting on your board, which is a skewed sample. Instead, weight repeated support questions, reasons given in cancellation flows, and drop-off points seen in session replays, since these reflect what’s actually costing you users. Then use the public board to communicate what you decided, not to decide it.

Will Smith·May 31, 2026·8 min read

Stop standing up a public feedback portal as your default way to learn what users want.

The vast majority of your users will never post on it, and the ones who do are not representative of the ones who matter. A feedback portal is a place where the loudest 1 percent file requests they can already articulate, while the problems actually killing your activation and retention sit somewhere else entirely, unwritten, in a support thread or a rage-quit or a cancellation nobody read.

I watched a founder do everything the playbook says. He stood up a feature request board, wired up voting, posted a tidy changelog. Three months later the board had nineteen posts, fourteen of them from the same four power users, and the top-voted item was a dark mode that, once shipped, moved no metric at all. Meanwhile his activation rate was leaking from a confusing second step in onboarding that not a single person had ever mentioned on the board. The portal wasn’t lying to him. It just wasn’t telling him anything that mattered.

This is not an argument that feedback tools are useless. It’s an argument that the portal is the wrong default. The right default is to go hunt for feedback where it actually lives, and to treat the rare typed request as a prompt to ship a fix, not to add a row to a vote tally on a roadmap nobody reads.

Why portals fill up with the wrong feedback

Three things conspire to make a feedback portal misleading.

First, posting is work, and it’s public. To file a request a user has to stop what they’re doing, click into a board, find or write a title, describe the problem in a box, and put their name on it in front of everyone. Most people won’t. They’ll abandon the task, mutter to a colleague, or just leave. So the board self-selects for the small group with the time, the confidence, and the stake to perform in public. That’s your power users and your most opinionated outliers. It is not your median user and it is definitely not the silent ones who churned.

Second, votes are theater. A feature request board ranks items by how many existing posters upvoted them. That measures popularity among people already on the board, which is a tiny, skewed sample. “Top requested” sounds like data. It’s a popularity contest inside a room most of your users never enter. Shipping the top-voted item feels responsive and frequently changes nothing, because the people who voted were going to stay anyway.

Third, and worst, is the articulation problem. Users report symptoms, not causes. Someone writes “add a bulk export button” because that’s the workaround they imagined for a problem they can’t name. The actual issue might be that your reporting view is too slow to use one record at a time. If you build the button, you’ve treated the symptom and missed the disease. Feedback portals collect proposed solutions from people who don’t have your view of the system. The most valuable feedback, the kind that explains why people don’t stick, almost never arrives as a clean feature request. It arrives as confusion, hesitation, and silence. Why companies ignore customer feedback is usually a story about listening to the wrong channel, not failing to listen at all.

Where the real feedback actually lives

If the board is the wrong place to look, here are the right ones. None of them require the user to do anything they weren’t already doing.

Support threads. Every “how do I...” ticket is a usability bug in disguise. If three people ask the same question this week, that’s not three support tickets, it’s one design problem with a 100 percent reproduction rate. Read your own support inbox weekly and tag the questions by the feature they’re about. The clusters are your roadmap.
Churn and cancel flows. The single highest-signal moment you have is the second someone decides to leave. Put one open text box on the cancellation screen: “What made you cancel?” Read every answer yourself. These people have no reason to flatter you, so they tell the truth, and they are the exact population a portal never captures because they left without posting.
Session replays. Watch real recordings of people using the product, especially the ones who dropped off. You will see rage-clicks on things that aren’t buttons, long dead-end pauses on a screen, and the precise step where the second onboarding page loses people. Nobody files a ticket that says “I hovered over this for nine seconds, got confused, and closed the tab.” The replay shows you anyway. This is the channel that catches the symptom the user couldn’t articulate. (If the term is new, here’s what session replay is and how teams use it.)
Direct DMs and Slack. When a user emails you directly or sends a Slack DM, that’s feedback they cared enough to deliver privately, which usually means it’s real. The instinct is to answer and move on. Don’t. Log it somewhere durable, because a DM is just a feature request that skipped the board, and it’s often higher quality precisely because it was lower friction.
Onboarding and sales-call questions. Every question a prospect asks on a demo is a gap in your product or your story. If five prospects ask “can it do X” and the answer is yes but they couldn’t find it, that’s not a feature request, it’s a discoverability bug worth more than any board post. Keep a running list of demo questions and treat the repeats as priorities.

Notice the pattern. The best feedback is involuntary. It’s what people do when they aren’t trying to give feedback. A feedback portal only ever captures the voluntary, performed kind, which is the thinnest slice of the truth.

The one thing a portal gets right

I should steelman the portal, because it does one genuine job well. A public feature request board is a credible signal that you listen. When a prospect sees a roadmap with shipped items and a changelog that updates, it builds trust in a way a private backlog can’t. A public board also dedupes loud asks: instead of answering the same integration request in ten separate emails, you point people at one post and let them pile on. That’s real value. It turns a recurring conversation into a single link.

So keep that. Keep the public roadmap, keep the changelog, keep one place to say “yes, we heard you, here’s where it stands.” What you should drop is the ceremony, the belief that the board is your primary intake, that vote counts are a prioritization engine, and that an empty board means users are happy. The board is a publishing surface for decisions you made using better data. It is not the place those decisions should come from.

Portal-first: wait for users to file and vote, then build the top of the list. Signal-first: hunt the involuntary feedback, decide what to build, then use the board to show your work.

A better default: shorten the distance from feedback to shipped

Once you stop treating the portal as the goal, the real metric becomes obvious. It was never “how many requests did we collect.” It’s “how fast does a real problem become a shipped fix.” A feature request board optimizes the wrong end of the pipe. It makes collecting feedback frictionless and leaves the hard part, turning a complaint into a change in the product, exactly as slow as it always was. You end up with a beautifully organized backlog and the same shipping speed. Organizing feature requests helps only if organizing was your bottleneck, and for most teams it isn’t. The bottleneck is the distance between a user saying something and a fix going live.

If the goal is shrinking the distance between a user’s complaint and a fix, that’s the bet behind what we build at Usero. When a piece of feedback comes in, Usero can turn it into an AI-authored pull request against your GitHub repo, so the loop is feedback to shipped code, not feedback to vote count. The portal pieces still exist, public roadmap, voting, changelog, session replay in the free tier, because they’re useful substrate, but they’re not the point. The point is collapsing the gap between hearing and fixing.

On cost, it’s worth knowing the field before you commit. Canny removed its free tier in 2023 and now starts around 79 dollars a month, with most teams landing closer to 359 dollars. Featurebase starts around 49 dollars with AI clustering and is popular with bootstrapped SaaS. Frill and Nolt run simpler boards from about 25 dollars. Productboard is enterprise-leaning and overkill for a team under ten. None of that pricing changes the core point: a more expensive feedback portal is still a feedback portal, and the tool isn’t your problem if the board was the wrong default to begin with. If you’re comparison shopping anyway, weigh the best user feedback tools on how short they make the loop, not how pretty they make the board.

Closing

The feedback portal isn’t evil. It’s just a publishing surface that the industry sold as an intake system, and the gap between those two jobs is where founders lose months building dark mode while their activation quietly bleeds out. Stop asking users to file tickets. Go watch what they do, read what they write when they’re leaving, and answer the DMs they send you directly. Then ship the fix and let the changelog brag about it.

Here’s the rule of thumb to keep: don’t measure how much feedback you collect, measure how fast a complaint becomes a commit.

If you want to try the signal-first version

Usero ships the portal pieces (roadmap, voting, changelog, session replay in the free tier) but treats them as substrate, not the goal. The point is collapsing the gap between a complaint and a fix. Spin up a board and wire in your support inbox and replays to see what the involuntary feedback turns up.

Frequently Asked Questions

Do feedback portals work?

Feedback portals work for publishing your roadmap and deduplicating common requests, but they fail as a primary way to learn what users want. The vast majority of users never post on them, so the board over-represents a small group of vocal power users. The highest-signal feedback, the problems driving churn and poor activation, usually arrives through support threads, cancellation flows, and session replays instead. Use a portal to show decisions, not to make them.

Why don't users post on feedback boards?

Posting on a feedback board is real work done in public. A user has to leave their task, write a clear title and description, and attach their name to it in front of other users. Most people won’t do that, so they abandon the request, mention it to a colleague, or simply leave. The result is that boards capture the small, confident minority and miss the silent majority who churn without a word.

What's the alternative to a feature request board?

The alternative is signal-first feedback collection: actively hunting for involuntary feedback instead of waiting for users to file it. That means reading support threads for repeated questions, adding an open text box to your cancellation flow, watching session replays of users who dropped off, logging direct DMs and Slack messages, and tracking the questions prospects ask on sales calls. You can still keep a public roadmap and changelog as a publishing surface, just don’t treat the board as your main intake.

Why is session replay better than a feedback portal for finding problems?

Session replay captures what users do when they aren’t trying to give feedback, which is where the most valuable signal lives. It shows rage-clicks, dead-end pauses, and the exact step where onboarding loses people, none of which users can articulate in a written request. A feedback portal only captures the voluntary, performed feedback that a small minority chooses to write down. Replays catch the symptoms users feel but can’t name.

Is Canny worth it for a small team?

Canny is a polished feature request board, but it removed its free tier in 2023 and now starts around 79 dollars a month, with most teams landing closer to 359 dollars. For a small or bootstrapped team, that’s a steep price for what is fundamentally a publishing surface for your roadmap. Cheaper boards like Featurebase (from about 49 dollars) or Frill and Nolt (from about 25 dollars) cover similar ground. The bigger question is whether a board should be your primary feedback channel at all, since most users never post on one.

How should you prioritize feature requests if not by votes?

Prioritize by evidence of impact on activation and retention, not by vote counts. Vote totals only measure popularity among the small group already posting on your board, which is a skewed sample. Instead, weight repeated support questions, reasons given in cancellation flows, and drop-off points seen in session replays, since these reflect what’s actually costing you users. Then use the public board to communicate what you decided, not to decide it.

Build a feedback loop your team actually uses

Usero collects, clusters, and turns user feedback into shipped fixes.

Get started free