How to Use Discord to Get Feedback About Your Product
Why Use Discord to Get Feedback
If you're running a B2C product, this is close to a no-brainer.
The core problem Discord solves is that most feedback never reaches you. People have thoughts about your product constantly, but a lot of that never becomes an email, a support ticket, or a forum post — because it feels too small, too half-formed, or not "worth" the effort of a formal channel. Discord gives people a place to say things casually, in passing, the way they'd mention something to a friend. That lowers the bar enough that feedback which would otherwise never reach you — the stuff people don't think is "good enough" to justify a forum post or an email — actually surfaces.
Want to understand what your members are talking about?
Track topic analytics, issues, queries & feedback weekly and overtime with the most powerful Discord analytics
Giving feedback is also a social behavior. It's not something everyone does naturally — it's something people learn and get more comfortable doing over time, especially when they see others doing it and see it being welcomed. A community space is one of the best environments for that kind of behavior to develop, because it's social by default.
Discord also sits in a useful middle ground. On one end, you have a fully public building — where everything is visible to everyone, all the time. On the other, you have a private building, where nobody outside the team knows what's happening. Discord is a good compromise: you get a semi-open space where your most engaged users can see and participate in what's happening, without it being fully public.
And that group — your Discord members — already tends to like you. They joined because they're interested in your product, so you start with real goodwill. If you close the loop and show them that their feedback was seen, considered, or acted on, that goodwill compounds. People stick around longer when they feel heard, and that reinforcement effect is a big part of why Discord works so well for this specifically.
Bottom line: if you're a brand that is collecting product feedback, doing it on Discord — especially for a B2C product — is close to free money.
Set Up Discord Right
Not all Discords serve the same purpose. Some are social — people join to hang out and make friends. Some are support-focused — people join expecting to ask questions and get answers. And some are a blend of support and feedback. Where your server lands matters, because feedback isn't something that happens naturally in a community — you have to deliberately design the environment to invite it.
Start by making the server unmistakably about your product. Don't assume people arriving already know who you are or why they're there. A solid chunk of your server should be read-only channels that explain the basics: what your product does, what people can try, how to give feedback, where to download the app — everything and anything that explains why someone should give your product a shot. This sets the tone immediately: this is a product server, not a general social space.
Create dedicated spaces for feedback — and start with forums. Forums are the easiest format to manage for a few reasons. Early on, they discourage spam, since spamming means deliberately opening a new thread rather than just dropping a message into a live channel. Tags let you organize feedback by topic far more cleanly than a flat channel does. And forum threads are easier to index for outside search, which can quietly work in your favor for growth.
That said, some communities run feedback as a regular channel instead, and that's fine too — it's just harder to manage, since you get a lot more low-signal, trivial messages mixed in with the real feedback. With the right analytics in place, you can manage a channel-based setup nearly as well as a forum. Another pattern some servers use: auto-threading every message in a channel, so a team member can reply inside the thread rather than in the main channel. That keeps responses organized, but it also means every single message spins up its own thread — worth thinking through before you commit to it.
Whatever format you choose, give people an unambiguous place to put their feedback. Naming matters more than it seems. A channel just called "Feedback" is generic, but it works. If you want more specific feedback, name the channel for that specific thing — "Product Ideas" instead of "Feedback," for example — so people immediately know what belongs there. There's real inertia the first time someone considers giving you feedback. If they land on a channel and aren't sure their thought belongs there, most people won't post it and see what happens — they'll just stay quiet. Precise naming removes that hesitation.
One practical note: we typically combine feedback and bug reports into a single channel. They're really the same underlying signal — something isn't working the way a user expects — and you just triage and manage them differently once they come in. If you're getting a high volume of either one specifically, it's worth splitting them into separate channels. But starting combined is the easier default.
Incentivize Users to Give You Feedback
Just because you've made a place for feedback doesn't mean people will use it. Giving feedback is a surprisingly tall ask. The moment a user starts typing, a lot of second-guessing kicks in: Is this feedback stupid? Am I going to look dumb for pointing this out? Is this too small a thing to mention? Will anyone even respond? That hesitation is the real barrier — not the lack of a channel.
So early on, you need to actively reward people for showing up with feedback at all. If you already have guidelines for the kind of feedback you're looking for, great — but in the beginning, the priority is welcoming every single piece of feedback that comes in, even if you also gently coach the person on how to make it more useful next time. In our own server, we use a bot (CommunityOne) that lets a team member manually award points to a user for giving feedback, visible to everyone in the server. That public recognition does double duty: it rewards the person who spoke up, and it signals to everyone watching that feedback gets noticed here.
The other lever is roles. Giving a special, visible role to users who consistently show up with feedback turns a one-time action into an identity — "I'm someone who gives this team feedback" — which tends to keep people coming back.
But the single most important thing you can do — more than points or roles — is respond to the feedback itself. We'll get into this more in the next section, but it's worth saying plainly here: what people actually want, more than a reward, is acknowledgment. Directly addressing what someone brought to you is the most powerful form of that acknowledgment there is, and it's the thing that makes a feedback server sustainable over the long run rather than a channel that goes quiet after the first week.
Organize Feedback Properly
Once feedback is coming in, how you document it determines how useful it actually is.
If you're using a forum, this starts with proper tagging — that's the easiest lever you have, and it should be non-negotiable.
Beyond tags, organizing feedback usually means working closely with your product team, because different people on that team will read the same piece of feedback differently. When someone tells you they want you to build X, Y, or Z, the most useful thing you can do isn't take the request at face value — it's dig into who they are, what their use case is, and why they want it. Understanding the why behind a request matters far more than the request itself, because it's what lets your engineers design the right solution instead of just building exactly what one user asked for.
It's also worth drawing a clear line between short-term issues and long-term feedback — users themselves usually can't tell you which is which, so that judgment call is on you. A short-term issue is something like a bug that only shows up 1% of the time but is genuinely annoying everyone who hits it. Those need to be identified and escalated quickly, because they're fixable and time-sensitive.
Long-term feedback looks different — it's the "I wish you all had built this" kind of comment. For that category, the most important thing is remembering it over time, since a single piece of long-term feedback rarely justifies action on its own; it only becomes clear once you see the pattern across many conversations. This is where a tool like CommunityOne helps, and it's also worth deliberately resurfacing that feedback whenever the team is actually discussing that part of the product.
Bottom line: keep a firm mental (or tooled) separation between bugs and long-term feedback. They move at different speeds and need to be managed differently.
Close the Loop: Give Updates on Feedback
A healthy feedback community is a loop, not a one-way funnel. People give you feedback, and you close the loop by telling them what happened to it. Bigger organizations often split this work across different people and teams — product, engineering, community — but that doesn't have to break the loop, as long as someone owns making sure it closes. A few concrete ways to do that:
Make community acknowledgment a habit in your announcements. Not every announcement needs to be a product update, but when you ship something that came directly from a community member's feedback, say so — "we fixed this, thanks to [member] for flagging it." Over time, this trains the whole server to understand two things at once: feedback here gets acknowledged, and this server is genuinely about the product.
Give every piece of feedback some kind of initial response. Sometimes that's simply asking for clarity. Sometimes it's telling someone honestly that you're not going to solve this right now — you're logging it as a GitHub issue and it'll take time. People rarely ask for a specific timeline; they understand there are competing priorities. And sometimes the honest answer is that you're not going to fix something for a long time, maybe ever. Say that plainly. Most community members already understand you can't resolve everything, and they'll accept a clear "no, and here's why" far better than a vague "we'll get to it" that never happens. What actually damages trust is silence — leaving feedback unanswered signals to everyone watching that you don't care what people think.
Follow up individually when it matters. When you ship something that was requested repeatedly, go back — using your analytics — and find the people who actually asked for it, then DM them directly to say it's fixed. People are consistently surprised by this, and that surprise buys real goodwill; they keep giving you good feedback afterward. The most magical version of this is solving something almost instantly — a small bug you happen to be able to fix right in the moment. It won't happen often, but when it does, it creates a genuinely delightful experience, and people repay it with more engagement and more feedback.
Treat feedback as raw marketing material. Feedback often reveals gaps beyond the product itself — confusing documentation, missing tutorials, features people don't know how to use. Some communities take this further and turn it into regular content: weekly videos that walk through recent product changes and directly reference the feedback that drove them. Communities love this kind of content, and it turns your feedback loop into an ongoing source of material rather than just a backlog to work through.
Analyze Your Feedback
If you have the volume to justify it, the fastest path here is a dedicated analytics tool rather than reading every message by hand. This is the kind of problem CommunityOne's analytics was built for: it breaks feedback down by how long an issue has been around, how many people have raised it, the full context behind it, and whether it's been addressed — and it automatically buckets messages into issues, queries, feedback, and general marketing material. There's also a search layer that lets you trace how much conversation exists around a given topic and follow it back to the source. It runs $150/month if that's a fit for where you're at.
If you're doing this manually — either by choice or because your volume doesn't justify a tool yet — a few patterns are worth watching for:
Separate new users from established users. This is the single biggest fault line in what kind of feedback you get. New users almost always struggle with onboarding, UI, and UX — and you should be genuinely grateful when they tell you, rather than just quietly bouncing. Established users give feedback that's usually deeper and only surfaces after real usage. Both groups matter, but your established users are arguably the more important signal, since they're your recurring users — and how much good feedback you get from them is a real proxy for how healthy your community actually is.
Remember that not every user is right. Someone might tell you "you should build X, Y, Z." Your job as a community manager isn't to have the answer on the spot — it's to get the context: who they are, why they're using the product, why they think this is the right fix, and critically, whether this is something they're working around or an actual deal-breaker that will make them stop using the product. Bringing specific use cases and specific situations back to your team is far more useful than relaying "here's what a user wants."
Watch for too much positive sentiment. This sounds counterintuitive, but a community that's overwhelmingly positive is a red flag, not a good sign. Every product has real problems, so if you're not seeing them surface, something is suppressing negative feedback — usually over-incentivizing engagement, like running too many giveaways, which trains people to post praise instead of concerns. When that happens, the people who do have real problems just quietly leave instead of speaking up, because the room already feels like it only wants good news. Keep an eye on this balance — if everyone's only saying nice things, you've actually lost your feedback channel, even though it looks like it's thriving.
Feature decisions and bug decisions need different kinds of evidence. If you're on the product side, you often already know what to prioritize without needing analytics to tell you — if the same request keeps surfacing, you'll remember it, and that repetition is one of the best signals you have for what to work on next. One failure mode to watch for as a community manager: dismissing a piece of feedback as too minor or "not something we're going to do" and then never mentioning it again — which means the same feedback can resurface four or five separate times across the community, each time looking like an isolated, weak signal, because no one's tracking that it's actually the same recurring request. Documenting that something has come up before, even when you've decided not to act on it yet, prevents that pattern. And it's still worth periodically reading through the raw message data yourself rather than only working from a dashboard — a lot of people can report the same underlying problem but be affected by it in different ways, and seeing those specific positions is often what tells you whether your fix needs to be broader or whether you're actually looking at a set of edge cases.
Bugs are a different story: you need a detailed, reproducible report, because you have to be able to recreate the circumstances to actually confirm it's fixed.
User Patterns and the Right KPI
How you treat a user's feedback should depend on what kind of server you're running. In a more product-driven server, a new user who shows up with enthusiastic feedback deserves a fast, direct response — acknowledge it, DM them, work with them, and try to keep them engaged. In a more support-driven server, most people will just get their answer and move on, and that's completely normal — you're not trying to convert every support interaction into a relationship.
A useful benchmark to aim for is roughly an 80/20 split: about 20% of your users show up consistently — not necessarily every day, but repeatedly, surfacing different bugs and issues over time. Some of these users will go a step further and propose actual solutions, not just problems — when that happens, acknowledge it and reward it, whether with points or something else. But the core thing you're watching for isn't the sophistication of what they say — it's that they keep showing up.
The single biggest driver of how long you retain these long-term users is how fast you respond to their feedback. The best-case version is actually fixing the issue. But short of that, even just acknowledging it, giving an update, or explaining honestly why something can't be done right now — without requiring a lot of backend work — goes a long way toward making people feel appreciated.
One important distinction: engagement and feedback are not the same KPI, even though people often conflate them. A lot of communities optimize for engagement — messages, reactions, activity — but for a product-driven community, the priority should be getting valuable feedback you can actually act on, not maximizing engagement for its own sake. There is some correlation — more engagement generally does mean more feedback — but the relationship is looser than it looks. The real KPI to track is closer to: how much genuine value can you extract from your community, and how well are you serving that community in a way that actually improves your product.
Putting It All Together
If you take one thing from this, it's that a Discord feedback server isn't a channel you set up once and leave running — it's a system with four moving parts. First, set your Discord up for success on the product side: make it unmistakably about your product, and give people a clear, low-friction place to put feedback. Second, actively incentivize and encourage the behavior of giving feedback — most people won't do it on their own, so reward and recognize the people who do. Third, close the loop on the feedback you get, so the whole thing becomes sustainable rather than a one-way funnel that quietly trains people to stop bothering. And fourth, build a real process and system for understanding what people are actually asking for — proper analytics, whether that's a tool or your own disciplined review, so feedback turns into decisions instead of just noise.