A feature request template asks what someone is trying to achieve before it asks what they want built. That order matters more than any single field: a request for "a dark mode toggle" and a request for "I work at night and the glare hurts my eyes" can lead to the same fix, but only the second one tells you there might be a better fix you haven't thought of yet.
This page is one part of a larger guide. For the whole subject in one place, see feature request tools.
Why ask what they're trying to achieve, not what they want built?
A feature request is usually a customer's own attempt to solve a problem, filed as if it were the only solution. "Add an export button" is a solution. The problem behind it might be "I need to get this data into my accounting software," and that problem could be solved by an export button, an integration, or an API, three very different amounts of work with three very different reaches.
This is job-to-be-done framing: the customer hired your product to do a job, and the feature they're asking for is their guess at how to do that job better. Asking for the job, not just the guess, is what lets you build the fix that actually works rather than the fix that was asked for. It also means two customers who phrase their requests completely differently can turn out to be asking for the same thing underneath, which only becomes visible once you have the underlying goal written down next to both.
A minimal template for customers
Three fields. The second one is the job-to-be-done question, and it is the one worth protecting even if you cut everything else.
What do you want to be able to do?
What are you trying to achieve, and what do you do today instead?
How often would you use this?- What do you want to be able to do: the customer's own proposed feature, in their words, unedited.
- What are you trying to achieve: the underlying goal. This is the field that lets you solve the problem a different, possibly better way.
- How often would you use this: a cheap signal for how central the request is to their actual work, separate from how strongly they feel about it right now.
A fuller template for internal use
For requests that come in through sales calls, support conversations, or internal ideas, where more context is available and worth capturing before it is lost.
Title:
Requested by: [customer name, account, or internal]
What they asked for:
What they're trying to achieve:
What they do today instead (workaround):
How many customers have asked for this or something like it?
Priority: [low / medium / high]
Estimated effort: [small / medium / large / unknown]
Related requests:
Notes:- Title: short enough to scan in a list of fifty other requests.
- Requested by: where the request came from, so it can be tied back to a real account if you need to ask a follow-up question.
- What they asked for: the literal request, kept separate from your interpretation of it.
- What they're trying to achieve: the job-to-be-done field again, this time filled in by whoever heard the request, not just the customer.
- What they do today instead: the current workaround. This tells you how painful the gap actually is, and sometimes shows you a smaller fix than the one requested.
- How many customers: the difference between a one-off preference and a pattern worth building for.
- Priority and estimated effort: two separate axes. A cheap fix for a rare request and an expensive fix for a common one look nothing alike on a roadmap, and conflating them into one number loses that.
- Related requests: links the request to anything similar already filed, so a roadmap doesn't carry the same idea under five different titles.
One payment, no subscription, unlimited products.
What fields does a public feature request form actually need?
Fewer than the internal template, and in a specific order. A public form is filled in by someone who was not planning to spend five minutes on your website today, so every field you keep has to earn its place.
- A title field, short, so the request is scannable in a list next to a hundred others.
- A description field, which should default to a prompt asking what they're trying to do, not what they want built, since most people will write the solution unless the form actively asks for the problem.
- A way to see and vote on existing requests before submitting a new one, which does more to reduce duplicate submissions than any wording on the form itself.
- An optional field for how they'd use it or how often, kept optional, because forcing it costs you submissions from people who would have given you the core request but not the elaboration.
Everything past that is a field the team wants, not a field the customer needs to give. If you host the board yourself rather than a hosted tool, the self-hosting guide covers the operational side of running one.
Which fields reduce submissions without improving them?
Some fields feel responsible to ask for and mostly just cost you the submission.
- Mandatory categorisation into a long list of tags or product areas. A customer does not know your internal taxonomy, so this becomes a guess they have to make before they're allowed to finish, and guessing under pressure is exactly when people give up.
- Requiring an account before submitting. Every additional step between "I have a thought" and "it's submitted" loses people, and a login wall is the biggest one you can put in that path.
- A mandatory business justification or ROI field on a public form. This is a field for an internal request tracker, not for a customer who is doing you a favour by telling you what they want.
- Asking for a detailed technical specification of the solution. Most customers cannot write one, and the ones who can will usually write a worse spec than your own team would, because they don't have the codebase in front of them.
- A CAPTCHA or verification step justified as spam prevention, placed before the form rather than after. It filters out genuine customers on a slow connection along with the spam, and most spam on a feature request form is low-value enough that moderating it after the fact costs less than the submissions the gate loses.
The test for any field on a public form is whether the answer changes what you build. If it doesn't, it's a field for your own curiosity, and curiosity is not worth someone's drop-off.
Frequently asked questions
Should a feature request form ask for a use case?
Yes, and it should be the field the form leans on hardest. Asking what someone is trying to achieve, rather than only what they want built, is what turns a list of feature suggestions into a list of actual problems you can solve, sometimes in a way better than what was literally asked for.
How many fields should a public feature request form have?
As few as the request can survive on: a title, a description that asks for the underlying goal, and optionally how they'd use it. Anything requiring the customer to categorise, justify, or specify a solution belongs on an internal tracker, not a public form.
Should feature requests be public or private?
Public, wherever the request touches something other customers would also want, because a visible list lets people vote for an existing request instead of filing a duplicate, and duplicates are the biggest hidden cost in a feedback pipeline. Keep private submission available for anything a customer would rather not put their name to.
What's the difference between a feature request and a bug report?
A bug report describes something that is supposed to work and doesn't. A feature request describes something that has never existed. The distinction matters because a bug report needs a reproduction and a feature request needs a use case, which is a different field with a different job.
Do internal and customer-facing feature request templates need to match?
No, and they shouldn't. A customer template should be short enough to fill in in under a minute. An internal template can be longer because whoever fills it in already has the context and is doing it once, not for every request that arrives.