# Topic voting category for public feature requests > Keep feature requests in a dedicated voting category so demand gathers on one public thread instead of splintering across duplicate asks. - Canonical HTML: https://growth.iangoh.com/growth-ideas/topic-voting-category-for-public-feature-requests/ - Source: [meta.discourse.org](https://meta.discourse.org/t/discourse-topic-voting/40121?silent=true) - GrowthDex source hub: [Discourse Meta: Discourse Topic Voting](/sources/discourse-meta-discourse-topic-voting-meta-discourse-org/) - Last checked: 2026-05-29 - Rarity: uncommon - Budget: free - Channels: Community, Product, Sales - Stages: feature requests, community signal, roadmap trust, public proof - Key metric: Topic Voting gives users the ability to vote on topics in a specified category. ## Why this can grow A public forum gets messy fast when feature requests arrive as plain conversation. The same idea gets posted three times, support cannot point prospects to one live record, and product loses the compounding signal of visible demand. Discourse Topic Voting gives a cleaner lane by letting specific categories run on votes. That makes each request page work harder. It becomes a demand counter, a place for clarifications, and a public artifact sales or success can reuse. The gain is not just prioritization. It is a more legible product story in public. ## Ian's take From scaling consumer platforms across MENA and Southeast Asia, my default is to distrust growth work that only looks good in a slide. My bias is to treat this as a small market test first. Make the audience narrow, make the promise concrete, and let the first real response decide whether it deserves more work. I would run it small enough to learn quickly, then only scale the parts that real users repeat, save, reply to, or buy from. For this tactic, I would watch one clear growth signal before putting more time or budget behind it. ## Action plan 1. Define one narrow startup segment where topic voting category for public feature requests can create a measurable lift. 2. Turn the tactic into one offer, page, campaign, or workflow for the Community and Product channel. 3. Use the evidence from meta.discourse.org to set the first version of the message, format, and audience. 4. Launch a small test for 7 to 14 days with one success metric: one measurable growth signal. 5. Review the result, keep the winning message, remove weak variants, and turn the learning into a repeatable growth playbook. ## Source-backed example Discourse's official Topic Voting plugin lets admins enable voting on topics inside specified categories. ## Adjacent tactics in the same lane - [Canny Slack notifications before feedback gets buried](/growth-ideas/canny-slack-notifications-before-feedback-gets-buried/) - 3 shared channels - [Prospect vote required before feature promise](/growth-ideas/prospect-vote-required-before-feature-promise/) - 2 shared channels, 1 shared stage - [Roadmap stage notifications for feature requesters](/growth-ideas/roadmap-stage-notifications-for-feature-requesters/) - 2 shared channels, 1 shared stage - [Founder-calendar pricing page for first sales](/growth-ideas/founder-calendar-pricing-page-for-first-sales/) - 2 shared channels ## Read GrowthDex essays Browse the plain-English essay index at [GrowthDex Blog](/blog/). ## Related GrowthDex essays - [The forum should keep the answer after the chat scrolls away](/blog/the-forum-should-keep-the-answer-after-the-chat-scrolls-away/) - community-led growth, support deflection, forum seo ## Advisory If you want help turning this into a working growth system, Ian Goh offers advisory at https://iangoh.com/advisory.