Latest / Community Marketing with Fexingo: Discord, Slack Groups, and Brand Communities / How a 300-Person Discord Replaced a Full Product Research Team
Transcript
- Lucas: Welcome back to Community Marketing with Fexingo. I'm Lucas. Luna: And I'm Luna. Today we're talking about something I've been wanting to dig into: how a 300-person Discord effectively replaced a full product research team. Lucas: Yeah, this is a fascinating case. It's a B2B SaaS startup called Loomly — well, not Loomly, but a similar social media scheduling tool. They had a five-person product research team spending about $400,000 a year on user interviews, surveys, and usability tests. Luna: And they replaced that with a 300-member Discord server? How does that even work? Lucas: They shifted from a 'research at' model to a 'research with' model. Instead of recruiting participants for one-off studies, they built a persistent community where users could give feedback continuously. They set up dedicated channels: #feature-requests, #bug-reports, #beta-feedback, and even a #user-interviews channel where anyone could volunteer for a 20-minute call. Luna: So the community became the research panel. But how do you ensure the feedback is representative? A 300-person Discord might attract only power users. Lucas: That's the critical question. They actually tackled it by segmenting their user base. They had about 15,000 paying customers, so the 300 in Discord were about 2 percent. But they made sure to invite a mix: new users, mid-tier, enterprise, and even some churned users who still had goodwill. Luna: Did they just open the doors, or was it invite-only? Lucas: Invite-only, but strategically. They sent personalized invitations to users who had high engagement with their product — like those who submitted support tickets, attended webinars, or had high login frequency. They capped it at 300 to keep the signal to noise ratio high. Luna: What kind of incentives did they use? Because people don't just give you feedback for free. Lucas: They offered early access to new features, a direct line to product managers, and a community-only newsletter with development updates. But the biggest motivator was influence — users could literally see their suggestions get implemented. Within six months, 40 percent of features in development had originated from the Discord. Luna: Forty percent — that's huge. And that likely drives retention too. Lucas: Absolutely. Their Net Promoter Score went from 42 to 71 over the course of a year. And they reduced their feature validation cycle from an average of six weeks to about three and a half weeks. The research team was downsized from five people to one person who managed the community and synthesized feedback. Luna: So they went from $400K a year to maybe $80K? That's a dramatic shift. Lucas: Even less. The community manager cost about $70K, and the server itself is negligible. So they saved roughly $300K annually, while getting faster, more actionable feedback. And the quality improved because users weren't in a one-off 30-minute session — they were living with the product daily and could give nuanced feedback. Luna: But there has to be a downside. What about confirmation bias? If you're only hearing from 300 people, you might build features for them rather than the broader market. Lucas: That's a real risk. They mitigated it by running quarterly surveys to the full user base — about a 5 percent response rate — and comparing the priorities. In most cases, the Discord feedback aligned with the broader survey, but there were two instances where they over-indexed on power-user requests that didn't resonate with the mainstream. Luna: Can you give an example? Lucas: Sure. The Discord community pushed hard for an advanced analytics dashboard with custom metrics. The team built it, but only about 8 percent of users ever accessed it. Meanwhile, a simpler request — like better in-app notifications — was consistently asked for in surveys but rarely mentioned in Discord because power users already used workarounds. Luna: So the community can skew toward the sophisticated user. That's the classic early adopter trap. Lucas: Exactly. The key is to treat the Discord as one input, not the only input. But when used right, it's incredibly powerful. Another company I looked at — a project management tool — used a similar approach and cut their customer discovery time by 60 percent. Luna: I've seen a parallel in consumer products too. A direct to consumer mattress company I know of used a Facebook group of about 500 people to test new product designs before they ever built a prototype. They'd post concepts and get feedback within hours. Lucas: Right, because the community is always on. And you don't need to schedule a focus group or pay a recruiter. The economics are compelling, especially for startups that can't afford a dedicated research team. Luna: That's actually a good segue. Lucas, we talk about a lot of these strategies on the show, and I know a few listeners have mentioned they've tried implementing some of them. It makes me think about how this very podcast is funded — we don't have ads, and that's intentional. Lucas: Yeah, it's a good point. A handful of listeners chip in monthly through buy me a coffee dot com slash fexingo, and that's literally what keeps us going. It's not a big ask — just that if you've gotten value from these conversations, that's the way to keep them ad-free. Luna: Exactly. And it's a small group that makes it possible for us to do deep dives like this one. So thank you to those who already contribute. Lucas: Alright, back to the topic. Let's talk about what happens when a community-based research model fails. I found a cautionary tale from a fintech startup that tried this and ended up with a toxic community. Luna: What went wrong? Lucas: They opened the Discord to anyone, no screening. Within three months, it had grown to 1,200 members, but the signal to noise ratio plummeted. The loudest voices were often the most negative, and the product team started making changes based on complaints from a vocal minority. They ended up alienating their core users. Luna: So curation is critical. Lucas: Absolutely. The successful cases all have a clear community charter, active moderation, and a system for weighting feedback. For example, the B2B SaaS company I mentioned earlier used a simple upvote system in the #feature-requests channel, but they also tracked which requests correlated with higher retention. That data helped them decide what to build. Luna: So it's not just 'give us feedback' — it's a structured process. Lucas: Exactly. And they also rotated which product managers were active in the server each week, so users built relationships with the team. That human connection increased the quality of feedback — people were more thoughtful when they knew a real person was reading. Luna: I love that. It turns research from a transaction into a relationship. Lucas: That's the core insight. You can replace a research team with a community, but you can't replace the relationship-building that makes the feedback valuable. Luna: So for someone listening who wants to try this, what's the first step? Lucas: Start small. Invite 50 of your best customers — the ones who already send you thoughtful emails or are active in your support forum. Set up three channels: one for ideas, one for bugs, and one for general discussion. Then be genuinely responsive. If you ignore the community for a week, it dies. Luna: And measure the impact before you scale. Track how many feature requests turn into shipped features, and whether those features actually improve retention or revenue. Lucas: Right. The goal isn't to replace all research — it's to make research faster and cheaper while deepening customer relationships. And if you can do that with 300 people, you're winning. Luna: Great advice. That's all for this episode — thanks for listening.