A feature request form template that gets useful answers

Most feature request forms are built to collect features: a title field, a description field, maybe a priority dropdown. Then the team reads the submissions and can't act on any of them, because "Add bulk editing" with no context is not a decision input — it's a slogan.

The fix is to design the form around the problem instead of the feature. You want to leave the form knowing what the person was trying to do, what they do instead today, and how much it costs them. Here's a template that asks exactly that, and nothing else.

The template

Copy this into your form tool, Notion, or a GitHub issue template:

## Feature request
 
**What are you trying to do?**
(The task or goal — not the feature you want. "I need to
give our auditors a monthly log of admin actions," not
"add audit export.")
 
**What do you do today instead?**
(Your current workaround, even if it's "nothing, we skip
it" or "we do it by hand in a spreadsheet.")
 
**How often does this come up?**
( ) Daily  ( ) Weekly  ( ) Monthly  ( ) Rarely, but it's
painful when it does
 
**What would change for you if this existed?**
(One or two sentences. Time saved, a process unblocked, a
stakeholder satisfied.)
 
**If you have a specific solution in mind, describe it.**
(Optional. The problem above matters more.)
 
**Your email**
(So we can ask follow-ups and tell you when this ships.)

Six fields, one optional. Guides on form design converge on the same warning: a form with fifteen required fields doesn't get filled in — the best template is the shortest one that captures enough context to act on (Featurebase, monday.com).

Why each field earns its place

"What are you trying to do?" is the whole trick. Customers propose solutions shaped by the tools they've seen, and the proposed solution is routinely worse than what you'd design once you understand the goal. Putting the problem question first — and phrasing the solution field as optional — reorders the conversation.

"What do you do today instead?" is your severity signal. "We built an internal script" means a technical team with real need. "We skip it" might mean low priority — or a silent dealbreaker. Either way you learn more than a 1–5 priority dropdown would tell you, which is why this template doesn't have one: everyone picks 5.

"How often does this come up?" separates the daily paper cut from the quarterly annoyance. Note the fourth option — "rarely, but it's painful" — because frequency alone undercounts things like billing, audits, and migrations.

"What would change for you?" produces the sentence you'll quote in the planning meeting. It also makes the requester articulate stakes, which quietly filters idle wishes from real needs.

Email is non-negotiable. An anonymous feature request can't be clarified, can't be weighed by account, and can't be followed up when it ships. If you drop every other identity field, keep this one.

What to leave out

• Priority dropdowns — self-reported priority is uniformly "high."
• Category pickers — taxonomy is your job, not the requester's; they'll guess wrong and you'll re-tag anyway.
• Desired implementation date — invites expectations you haven't agreed to.
• Long legal or account preambles — every extra field before the first question costs you submissions.

Where the form fits — and where it doesn't

A form captures the requests people bother to file. That is a minority of the feature signal most teams receive; the rest is said in passing — in Slack threads, support tickets, sales calls, community channels — by people who will never open a form. Treat the form as one inlet, not the system.

Disclosure: we build Modem, which works the opposite side of this: it captures feature requests from the conversations where they naturally occur (Slack, Discord, support, email) with the requester attached, and dedupes them into topics alongside whatever your form collects. Both streams land in the same context graph, so a form submission and a Slack aside about the same feature merge into one counted topic with both requesters attached. If your product is early and your users are few, the form plus a spreadsheet is genuinely enough — see our feedback tracker templates. The form stops being enough when most of your feedback stops arriving through it.

Wherever the submissions land, apply the same processing rules as any other feedback: log with requester, merge duplicates, respond with a real status — we cover the replies in how to respond to feature requests.

The smallest version to start this week

Paste the template above into whatever form tool you already have, link it from your docs and your support macro, and route submissions to one owner. When the first submission arrives with a filled-in "what do you do today instead?", you'll see why the form is shaped this way.