Anonymous Feature Request Form

When to use this template

A feature request form gives users a low-friction channel to suggest improvements. The right design captures both the what (the specific feature) and the why (the underlying problem), so you can prioritize based on real customer pain rather than feature wish-lists.

Use this template:

• In your product, embedded in a "feedback" or "suggest a feature" link
• At the moment of friction — when users hit limits, when error messages occur, when features don't quite do what they expected
• In your documentation — at the bottom of docs articles ("missing something? Tell us")
• In your community forums — pinned post inviting feature suggestions
• In support replies — link to the form when support deflects a missing-feature request

Pair with a public roadmap (e.g., Canny, Productboard's public roadmap, or just a simple Trello board) so users see what made it onto the roadmap.

Why anonymous feature requests get higher quality input

Logged-in feature request tools (Canny, Productboard, Aha!, ProductPlan) work well for power users — the engaged minority who'll spend 5 minutes writing a detailed request with their account attached. They produce the "loud minority" pattern: 5% of users contribute 95% of requests, and those requests skew toward power-user needs that may not represent the broader user base.

Anonymous embedded feature requests capture the quieter 95%. The user who hits a friction point, mutters "I wish this would just do X," and would never log in to file a formal request, will dash off a quick anonymous note. Volume goes up 3–5×; the distribution of requests becomes more representative.

The tradeoff: you can't follow up with the specific requester or weight requests by account value. Most teams accept this; the patterns in anonymous requests are typically more actionable than the per-user weighting.

Anonymeter logs no IPs, sets no cookies, stores no respondent IDs. Requests are anonymous structurally, not just by policy.

The 4 questions, explained

1. "What feature would you like to see?" (text, required) — the feature itself. Required because the rest of the form makes no sense without it.

2. "What problem would this solve for you?" (text, optional) — the underlying need. Critical for prioritization. A user requesting "a dark mode toggle" because "I work at night and the white screen hurts my eyes" is more actionable than just the toggle request — you might solve the problem with a different feature (auto-dim based on time, e.g.).

3. "How important is this for your workflow?" (choice: Nice to have / Important / Critical, optional) — prioritization signal. Don't take "Critical" too seriously (users overweight their own asks) but the distribution across categories is useful — features marked "Critical" by many users get attention.

4. "Anything else we should know?" (text, optional) — catch-all. Often surfaces context that didn't fit the structured questions.

4 questions is the right size. Beyond 4, users abandon the form. The "what feature" + "what problem" pair captures 90% of the value.

Best practices

• Place the form at friction points. A "Suggest a feature" link buried in settings gets ignored. A small "Did this fail to do what you wanted? Tell us" link near error messages gets used.
• Acknowledge requests publicly — even if you can't build everything, "we received X requests for Y this month" signals you're listening.
• Don't promise to build everything that's requested. Better to ship a fast public roadmap that says "we got 30 requests for X, here's why we're not building it" than to silently ignore them.
• Group similar requests together when reading. "Export to CSV," "Download data," "Backup my responses" might all be the same request phrased differently.
• Don't ask for account info or contact details — kills response rate. If a user wants to follow up, they'll add it in the text.

What to do with the responses

The pattern that works:

1. Weekly: review new requests. 15 minutes to read and tag by theme.
2. Monthly: aggregate by feature, count requests. The volume of requests per feature is the strongest prioritization signal you have.
3. Monthly: share counts with the product team. "We got 45 requests for X this month, up from 12 last month — surfacing for prioritization."
4. Public roadmap reflects the top-requested items, with status (Planned, In Progress, Shipped, Declined-with-reason).
5. When you ship a requested feature, announce it back to the form's audience. "We shipped X — thanks to everyone who requested it. Next, we're working on Y."
6. Use Anonymous Follow-Up for ambiguous requests — Anonymeter lets you reply to a specific request asking "can you give an example of where you'd use this?" without identifying the requester.

Why Anonymeter for feature requests

Dedicated feature request tools (Canny, Productboard, Aha!) cost $80–$500+ per month and add value through upvoting, roadmap visualization, and integration with your dev tools. Worth it if you have a community of vocal power users who want to vote on features. Overkill if you just want a stream of input from users who'd never log in to vote.

Anonymeter is the unbundled version. Free embedded form, collect requests, prioritize internally. $9/month Pro adds CSV export (for joining to your own roadmap tool) and Anonymous Follow-Up (for clarifying ambiguous requests).

The structural anonymity captures input from users who'd never bother with a logged-in vote — broader signal than dedicated tools typically produce.