Feature Request Form Template
Collect feature ideas with the context that makes them buildable — the underlying problem, current workaround, urgency, and a beta-tester pipeline.
Good ideas die in support tickets. Put yours here instead — with enough context, it can go straight onto the roadmap table.
Feature requests arrive as solutions — "add a button that does X" — and the actual need hides underneath. This template is engineered to dig the need out. Its required questions are the feature's name and the problem it solves, in that order, and the problem prompt explicitly asks for the situation rather than the solution, because product teams can evaluate a situation but can only say yes or no to a demand.
Why these fields. The one-line name gives your backlog a scannable title; discipline at the title level is what keeps a request board readable at two hundred entries. The problem field is the heart: a request that describes the moment of pain can be solved several ways, including ways cheaper than the requester imagined. The workaround question is the most underrated field here — workarounds reveal how much the problem actually costs (people who built a spreadsheet pipeline care; people with no workaround might not), and sometimes the workaround is the spec. Urgency and frequency are separate axes on purpose: a blocking-but-rare problem and a daily-but-mild one demand different roadmap treatment, and collapsing them into one "priority" question destroys that information. The beta opt-in converts requesters into your launch cohort — the email field only appears for people who say yes, keeping the form contact-free for everyone else.
What we left out. Votes and upvote counts (that is a board feature, not a form field), category dropdowns (your team's taxonomy changes; free text plus tags in your tracker ages better), and screenshots as a required step — friction belongs on bug reports, not idea capture.
Who uses this. SaaS teams link it from the app's help menu, indie developers pin it in their community server, and platform teams inside larger companies use it to give internal customers a single intake instead of drive-by Slack requests.
Make it yours. Wire a webhook to create a card in your project tool for each submission — the urgency answer arrives as structured data you can map to labels. When a feature ships, filter the CSV export by that request and email the beta list from it. If requests pile up in one area, clone this form with the AI generator and aim a focused version at just that feature space.
One door, even for insiders. The quiet failure mode of feature intake is fragmentation — requests arriving through support threads, sales calls, and hallway conversations, each in a different shape, none comparable. Make this form the single door and have your own team file on a customer's behalf whenever an idea surfaces elsewhere: a rep who must articulate the problem and the workaround before submitting applies the same discipline to a pet idea as to a customer wish. Uniform intake is what keeps the board honest, because ideas end up competing on the strength of the need rather than on who carried them in.
Frequently asked questions
How do we keep duplicate requests under control?
Let them arrive — duplicate volume is demand data. Group them in your tracker by problem, and the CSV export makes clustering by keyword straightforward.
Why is there no public voting?
This form is a structured intake, not a public board. Feed submissions into whatever planning tool you use via webhook; voting dynamics tend to reward loudness over need anyway.
Does the beta email field make the form less anonymous?
It only appears when someone opts into beta testing, and it is optional even then. Requests without contact details are just as valid on the board.
Can requesters attach mockups?
Add a file upload block if your audience sketches — images and PDFs up to 10MB per file are supported. For most teams the problem description matters more than the mockup.