Latest / Community Marketing with Fexingo: Discord, Slack Groups, and Brand Communities / Why Your Community Should Decide Your Next Product Feature
Transcript
- Lucas: Luna, I've been thinking about this one community that let its members vote on which new feature to build next. And it wasn't just a poll — the result actually changed their product roadmap. Luna: That's bold. Most companies are terrified of letting customers make product decisions. Lucas: Right, and that fear is usually justified. But this mid-sized SaaS company — I'll keep them anonymous — they had a community of about four thousand active users. They'd been debating two features for months internally. So they decided to put it to a vote. Luna: And what was the result? Did the community pick the one the product team wanted? Lucas: Actually, no. The community picked the feature that the product team had rated as lower priority. And that was the twist — because they went with the community's choice, adoption was thirty percent higher than any previous feature launch, and churn dropped by a quarter. Luna: So letting go of control actually made their product better. How did they frame the vote to get that outcome? Lucas: It wasn't just 'which do you want?' They gave context: here's the problem each feature solves, here's the rough effort involved, here's what we think the impact could be. They made it a strategic decision, not a popularity contest. Luna: That's smart. So the community felt like they were making an informed choice, not just picking a shiny object. Lucas: Exactly. And that transparency is what I think turned the vote into real engagement. The members who voted — even the ones on the losing side — were more invested in the outcome. They felt heard. Luna: But what about the losing feature? Did they just shelve it forever? Lucas: They didn't. They published a roadmap that showed the losing feature as 'next up' with a timeline. And they explained why it didn't win — not enough votes — but they committed to revisiting it after the winning feature shipped. That follow-through is crucial. Luna: So you're saying the key isn't just the vote itself, but what happens after. Lucas: One hundred percent. The vote is just the beginning. The real work is in the communication — before, during, and after. And that's exactly what we're going to unpack today. Lucas: Let's start with the why. Why would a company hand over part of its product roadmap to a community? It's not about being democratic for the sake of it. Luna: I'd say it's about alignment. If your community is your best customers, they're basically a focus group that lives with you. Lucas: And they're more representative than a focus group you assemble for one afternoon. These are people who use the product daily. They know the pain points. In that SaaS case, the feature that won — it was a reporting enhancement that their most engaged users had been requesting for a year. The product team had been ignoring it because it wasn't 'sexy.' Luna: It's not sexy, but it's what keeps people from churning. That's a classic disconnect. Lucas: So the vote surfaced a misalignment between what the product team thought was important and what the market actually wanted. And by letting the community decide, they corrected that in one move. Luna: Okay, but there's a catch. How do you make sure the vote isn't just flooded by the loudest voices? What about the silent majority? Lucas: That's the classic problem. In the case I mentioned, they didn't just count votes — they weighted them. Users with higher engagement — more logins, more feature usage — got double weight. That's a way to ensure that the people who actually live in the product have more say. Luna: Interesting. So it's not a pure democracy, it's more like a weighted vote based on experience. Lucas: Right. And you have to be transparent about that weighting, or else people will feel cheated. They published the methodology beforehand, so everyone knew what they were getting into. Luna: What about timing? A vote like that can drag on forever if you let it. Did they set a deadline? Lucas: They had a seven-day window. That's short enough to maintain momentum, long enough for everyone to weigh in. And they announced it with a countdown, which built anticipation. Lucas: Now, the results. When the vote came in, the product team was honestly a little deflated — their pet project lost. But they didn't show that. They announced the winner with genuine enthusiasm, congratulated the losing side for their advocacy, and shared the exact vote totals. Luna: So they acknowledged the losing side's passion. That's a classy move. Lucas: It's essential. If you make people feel like their vote was a waste, they'll disengage. They made sure the losing side knew their voices were heard and would inform future decisions. And they actually added a 'next up' label to the losing feature on their public roadmap. Luna: So that builds trust for the next time you ask the community for input. It's not a one-off transaction. Lucas: Exactly. The community becomes a strategic council, not just a feedback box. And that's the long-term value. Luna: But what if the community picks something that's technically impossible, or would take a year to build? How do you keep the vote realistic? Lucas: You set guardrails. In this case, they only offered features that were already on the internal roadmap — they just let the community pick the order. That way, nothing was off the table, but everything was feasible. Luna: So it's not 'what should we build next?' but 'which of these two should come first?' That's a much safer question. Lucas: Right. You're not asking for a blank slate — that's how you get 'build a mobile app' when you're a desktop-only tool. You're offering a curated choice that aligns with your strategic direction. Lucas: And there's another pitfall: expectation management. You have to be crystal clear that the vote is advisory, not binding. In this case, they were committed to following the result, but they also had a clause that if something catastrophic happened — like a security issue — they could pivot. And they communicated that upfront. Luna: So you're setting the rules of the game before the game starts. That's fair. Lucas: It's the only way to avoid resentment later. If people think you're going to build exactly what they vote for, and then you don't, you've lost trust. Being transparent about the advisory nature protects both sides. Luna: And after it's built, what do you do? Just say 'done' or do you go back to the community? Lucas: You absolutely go back. They did a beta release to the community first, gathered feedback, made tweaks, and then launched broadly. And they publicly credited the community for the feature's success. 'You asked, we built' — that's a powerful narrative. Luna: That's a great way to reinforce the value of their input. And it probably makes them more likely to participate next time. Lucas: Exactly. That's the flywheel. And now, thinking about it, if you're listening and you've ever been in a community that made a product decision, or you've thought about doing one for your own product, this is the kind of thing that could genuinely help you avoid some mistakes. Luna: Yeah, I think this episode is packed with practical insight. Lucas: And if today was actually useful to you, the way these stays ad-free is through listener support. You can buy me a coffee at buy me a coffee dot com slash fexingo. It's a small gesture that keeps this kind of conversation going. Luna: And it's because of that support that we can keep digging into these real-world community stories. Lucas: So, back to the vote. One more thing that impressed me was how they handled the losers' aftermath. They didn't just say 'sorry, better luck next time.' They created a dedicated channel in their community for the losing feature's supporters to discuss what would make it more compelling for the next vote. Luna: That's a brilliant move. It turns disappointment into a constructive conversation. Lucas: It kept those members engaged, and it gave the product team a wealth of qualitative feedback. They learned that the losing feature was actually more of a pain point than they thought, but the user base didn't understand its full value. So they had a knowledge gap, not a product gap. Luna: That makes sense. So the vote was almost a diagnostic tool. Lucas: Exactly. And that's the deeper lesson: community votes aren't just about picking a winner. They're about understanding your users' psychology and their relationship with your product. The vote itself is just the visible part of the iceberg. Luna: So, if someone wants to try this in their own community, what's your one piece of advice? Lucas: Start small. Don't vote on a huge strategic direction. Pick a small, reversible decision — like which of two new emojis to add, or which of two blog posts to feature — and walk through the whole process. That builds the muscle for when it's time to make a bigger call. Luna: Practice makes perfect. And it also builds trust with the community — they see you're serious about listening. Lucas: That's the thing. Ultimately, it's not about the vote. It's about the signal you send: we trust you with decisions that matter. And that's a brand value that's hard to copy.