Question 1

How is this different from a feature-prioritization survey?

Accepted Answer

Different structure and different point in the product-development cycle. A feature-prioritization survey is structured against a pre-curated list of candidate features the team is already considering — users rank, choose, or allocate budget across the team's existing roadmap candidates. A feature-request form is open-ended and unsolicited — users submit single-feature requests with their own framing, without seeing the team's roadmap candidates first. The request form is upstream of the prioritization survey: feature requests are the raw material that gets clustered and triaged into roadmap candidates, which then go into prioritization surveys to validate priority order. Both forms have a place in a mature product-development cycle. Use the request form for continuous open intake; use the prioritization survey for periodic structured validation of the team's roadmap hypothesis. Don't confuse them — using a request form for prioritization produces vague wishlists rather than ranked preferences, and using a prioritization survey for open intake misses the requests the team didn't think to include as candidates.

Question 2

Should feature requests be public or private?

Accepted Answer

Tradeoffs in both directions. Public boards (Canny, Featurebase, Headway, Productboard portals, Sleekplan, GitHub Discussions, public community channels) increase deduplication because users see existing requests and vote rather than create duplicates; enable community voting that signals demand; build community engagement; show transparency. Public boards also create downsides: bad-faith competitors can use the public roadmap against you; security-sensitive feature requests need to be hidden; the moderation overhead of a public feedback forum is real; and competitively-sensitive product directions get exposed to anyone watching. Most mature B2B SaaS lands on a hybrid: a public board for the majority of feature requests with private intake available for enterprise customers, security-related requests, and competitively-sensitive product directions. Developer tools and open-source projects tend toward fully public (GitHub Discussions for transparency); consumer products tend toward private intake with status updates via email or in-app notification; enterprise SaaS tends toward private with optional public roadmap snapshots. The right answer depends on your audience and your competitive sensitivity.

Question 3

How do we handle duplicate requests?

Accepted Answer

The deduplication challenge is real and most teams under-invest in it. Three approaches, in order of investment. Pre-submission search: before the user submits a new request, the form (or the public board) surfaces existing similar requests and offers the user the option to vote on one rather than create a new entry. Canny, Featurebase, Headway, Productboard portals, Sleekplan all do this automatically with their search-before-submit pattern. Post-submission clustering: the product team's triage process clusters submissions weekly or bi-weekly into themes, merging duplicates and identifying patterns. This requires dedicated triage time (typically a product manager spending 1-3 hours per week on triage for a moderately-active feedback board). LLM-assisted clustering: emerging tools (Productboard AI, Canny AI features, custom LLM-based clustering) can semantically group similar feature requests automatically, reducing the manual triage burden significantly. For high-volume request streams (consumer products, large B2B SaaS), the LLM-assisted approach is increasingly standard. For lower-volume streams, manual triage is fine but should be scheduled as a recurring product-team task, not deferred indefinitely.

Question 4

Should users be able to vote on others' requests?

Accepted Answer

Yes, in most cases — voting is one of the highest-value features of public feature-request boards because it lets you distinguish requests with broad demand (high vote count) from one-customer specificity (low vote count). The voting data feeds prioritization decisions, validates problem-framing across multiple users, and creates social proof that builds community engagement around the request board. Three caveats. First, voting can be gamed — competitors can register accounts and vote down rival features, sock-puppet accounts can inflate vote counts on specific requests, and the gaming risk increases with the visibility of the board. Most boards apply account-based vote limits (one vote per user per request) and bot-detection to mitigate. Second, voting signal is not the same as priority — a feature with 500 votes from one user persona may be less important than a feature with 100 votes from a high-value enterprise persona, and the product team's triage needs to apply weighting beyond raw vote count. Third, voting works best when it's combined with comment or use-case capture — "I want this because I'm trying to do X" alongside the vote reveals the underlying problem and helps the product team think of solutions.

Question 5

How do we communicate "we won't build this"?

Accepted Answer

Transparently and with reasoning. The implicit contract of soliciting feature requests is that the team responds to the request — saying yes, saying not now, saying never, all are acceptable but silence is not. The standard pattern: triage every request within 1-4 weeks of submission with a status update to the user. The statuses that work: "acknowledged" (we've read it and it's in the queue), "considering" (we're evaluating this for an upcoming cycle), "on roadmap" (planned for an upcoming version), "in development" (being built now), "shipped" (with a link to the changelog or release notes), and "won't build" with explicit reasoning. The won't-build status is the hardest one for teams to use because it feels negative, but a clear won't-build with reasoning ("this conflicts with our positioning around X," "the implementation cost would be prohibitive for the audience size," "a third-party tool already solves this well, so we're integrating with that tool instead") is dramatically better than silence — users understand decisions they disagree with as long as the decisions are explained. The longest-running and most-successful public request boards (Linear's, Notion's, Stripe's, Vercel's, Cursor's) all use the won't-build status liberally with clear reasoning, and their users continue submitting requests because they trust the process.

Feature request form — capture problems, not just solutions

Feature request form — capture problems, not just solutions

Who this template is for

From user request to triaged backlog entry in under 60 seconds

What's included

Built for the product categories where feature-request volume scales with engaged users

Tune the form to your team's triage capacity and your public-board strategy

Feature request form FAQ

Related templates

Free Product-Market Fit Survey Template

User onboarding survey — personalize activation and segment new signups

Bug report form — capture reproducible reports that engineers can actually fix

Ready to build forms that work for you?