How to Run User Research in a Discord Community With a Standing Panel

How to run user research in a Discord community: stop posting open calls and recruit a standing panel of thirty to sixty members, selected across tenure, segment and product usage. Ask them on a fixed cadence, compensate them with access, and publish a monthly one page report with a named decision beside each finding.

---

Before: the open call

Here is what research in a community usually looks like. A product manager needs input on a decision that is already half made. They post an announcement asking for volunteers. Nine people reply within an hour. Six of them are the same six who reply to everything. Two calls get booked, one no-shows, and the finding is written up as a sentence beginning with the word members. Nothing about that process is lazy. It is fast, cheap, and it feels like listening. The problem is that it has no denominator. You learn what nine self-selected people think, and you cannot tell whether that is the market speaking or a hobbyist with strong opinions and free time. There is a second cost that shows up later. Open calls train the enthusiastic members to expect access and everyone else to ignore research requests entirely, which narrows your input every time you run one.

After: the standing panel

The same product manager opens a document containing forty two names. Each name has a segment tag, a tenure figure, and a usage band beside it. They pick the eleven names that match the decision, send a three question set, and have twenty eight responses within two days because the panel already agreed to be asked. The difference is not effort. It is that selection happened once, in advance, rather than being outsourced to whoever was online.

Building the panel

Aim for thirty to sixty people. Below thirty you cannot segment. Above sixty you cannot maintain relationships, and the relationship is the reason the response rate holds. Select deliberately across three axes:

1. Tenure. Include members from their first month, their first year, and the people who were there before the product looked like this. New members are the only ones who can still see your onboarding.
2. Segment. If you serve three kinds of customer, the panel needs all three in rough proportion. A panel weighted toward your most technical users produces a roadmap only technical users want.
3. Usage. Heavy, moderate and light. Light users know exactly where the product lost them, which is the most valuable information in the building and the hardest to obtain. One more selection rule that people resist: include members who have complained. Not the abusive ones, the specific ones. A member who wrote four paragraphs about a broken workflow has done unpaid analytical work and is usually delighted to be asked properly.

⚠️ Recruit privately, one message at a time, and say how often you will ask and how long the commitment runs. Panels recruited by public announcement are open calls with extra steps.

The cadence

Rhythm is what keeps a panel alive. Pick one and hold it for two quarters before changing anything.

Every two weeks   Three question set, closes in 48 hours
Every month       Two thirty minute calls
Every quarter     One open thread on a named theme
Every quarter     One report back on what changed

That last row is the one teams drop first and the one that determines whether the panel exists in a year. People stay in research programmes to see their input become something. Silence reads as extraction.

A panel that never hears what changed becomes a mailing list, and mailing lists have declining response rates.

Paying people properly

Cash works and creates a strange incentive: it attracts people who want the payment rather than people who want the product to improve. Better currencies, in rough order of effectiveness:

• Early access, genuinely early, before the polish
• A direct line to someone who can answer a question rather than log it
• Their name attached to a shipped change, with their permission
• A visible role in the community that signals contribution
• A small credit or gift for calls, which respects the time without becoming the motive The fourth item does more work than its cost suggests. Recognition is durable in a way a one-time payment is not.

Routing the findings

A finding that stays inside a community channel changes nothing. The panel earns its place through a document that leaves the community team. One page, monthly, same shape every time: the question asked, how many people answered, what they said in three lines, and the decision it informs, with a named owner. Send it to product, support and marketing. The reason to write the decision beside the finding is that it converts research into a record. Six months later, somebody can trace a shipped change back to a specific panel response, which is the single most effective defence of this programme in any budget conversation.

Two ways this fails

The first is panel capture, where the same eleven names get asked everything because they respond fastest. Rotate deliberately and track who has been asked in the last quarter. The second is fatigue, which arrives quietly through frequency creep. A team asks weekly during a launch, then keeps the pace out of habit. Response rates fall, the fastest respondents dominate again, and you have rebuilt the open call inside your own panel.

What the panel does not do

A research panel is one layer. It does not replace the reporting loop that summarises what the whole membership is saying, and it does not replace support routing, which is where problems arrive before anybody thinks to research them. It also adds moderation load, because a more engaged membership generates more of everything, including friction. What it does replace is guessing dressed up as listening. Thirty to sixty selected people, asked on a rhythm, reported with decisions attached, is enough structure to make community input something a product team can plan around.

Selection is the part of research that happens before anybody asks a question. Do it on purpose. More at danieljeong.org.