A feature request template is a reusable structure that captures what someone wants built, why it matters, and who it affects, so your team can evaluate it without a dozen follow-up questions. This post gives you a feature request template you can copy today: a general format, a GitHub issue version in markdown, a customer-facing feedback form, plus a filled-in example and a quick way to prioritize the requests that pile up.
Most requests arrive as one vague line: "can we add export?" That gap between a one-liner and a decision is where roadmaps stall. A good template closes it. If you also keep bug reports consistent, pair this with our bug report template so your intake stays clean on both sides.
What a good feature request includes
A feature request is not a spec. It is the minimum information a product owner needs to decide whether something is worth building and roughly how big it is. Strip out everything else and you are left with six fields.
| Field | What it captures | Why it matters |
|---|---|---|
| Title | A short, specific summary | Makes the request searchable and scannable |
| Problem / use case | The job the user is trying to do | Separates real needs from solution guesses |
| Proposed solution | How the requester imagines it working | Gives a starting point, not a mandate |
| Who it affects | User segment, role, or account size | Shows reach and helps weigh priority |
| Priority / impact | Severity and expected value | Feeds straight into ranking decisions |
| Alternatives considered | Workarounds already tried | Reveals urgency and prevents duplicates |
The single most useful field is problem or use case. When someone writes "add a Kanban view," you do not yet know the problem. Maybe they want to see status at a glance, or spot bottlenecks, or stop missing deadlines. Each of those points to a different solution. Capture the problem first and the proposed solution becomes one option among several.
The "alternatives considered" field does quiet work. If a requester has already tried three workarounds, the need is real and pressing. If they have tried nothing, the request may resolve itself once you point them to an existing setting.
General feature request template (copy-paste)
This is the format that works for internal teams, stakeholders, and anyone comfortable writing a short paragraph. Drop it into a Notion page, a shared doc, or your issue tracker.
Title: [One specific sentence describing the request]
Problem / use case:
What are you trying to do, and what is getting in the way today?
Proposed solution:
How do you imagine this working? (Optional. Describe the outcome
if you are not sure about the mechanics.)
Who it affects:
Which users, roles, or account types hit this? Roughly how many?
Priority / impact:
How often does this come up, and what happens if it is not solved?
[ ] Blocking [ ] High [ ] Medium [ ] Nice to have
Alternatives considered:
What workarounds have you already tried?
Links / context:
Screenshots, related requests, support tickets, customer names.
Keep proposed solution optional. The people closest to the problem are often the furthest from the right implementation, and forcing a solution can anchor your team on a weak idea. The outcome matters more than the mechanism.
GitHub feature request template (markdown)
For open-source projects and engineering teams, a GitHub feature request template lives at .github/ISSUE_TEMPLATE/feature_request.md. GitHub renders the front matter into a labeled issue form. This version mirrors the fields above but fits a developer workflow.
---
name: Feature request
about: Suggest an idea or improvement for this project
title: "[Feature] "
labels: enhancement
assignees: ''
---
## Is your feature request related to a problem?
A clear description of the problem. Ex. I'm always frustrated when [...]
## Describe the solution you'd like
What you want to happen.
## Describe alternatives you've considered
Other solutions or workarounds you've tried.
## Who would use this
The users, roles, or use cases this would help.
## Additional context
Screenshots, links, or context about the request.
Save that file to your repo and GitHub adds it to the "New issue" chooser automatically. Adding the enhancement label up front keeps feature work separate from bug triage. If your team also files structured bugs, a matching bug_report.md in the same folder keeps both flows tidy.
Customer-facing feedback form template
Customers will not write paragraphs. A public feedback form trades depth for completion rate, so keep it to four short questions and infer the rest from context.
1. What would you like us to add or improve?
[ short text field ]
2. What are you trying to do that this would help with?
[ short text field, this is the "why" ]
3. How much would this help you?
( ) I can't do my work without it
( ) It would save me real time
( ) It would be a nice improvement
4. (Optional) Anything else we should know?
[ long text field ]
[ Email, so we can follow up and tell you when it ships ]
Question two is the one to protect. Customers default to proposing solutions, so a gentle prompt for the underlying goal turns "add dark mode" into "I work at night and the bright screen strains my eyes," which you can solve in more than one way. For more on collecting input that converts into action, see our notes on process documentation examples.
A filled-in example
Here is the general template completed by a real-sounding requester, so you can see the difference between a vague ask and a useful one.
Title: Let admins export billing history as CSV
Problem / use case:
Our finance team reconciles SaaS spend monthly. Right now I screenshot
each invoice from the billing page because there is no export. It takes
about 40 minutes and I make transcription errors.
Proposed solution:
A "Download CSV" button on the billing page that exports all invoices
in a date range, with columns for date, amount, plan, and status.
Who it affects:
Account admins and finance roles. Affects every paying team that does
monthly reconciliation, probably most of our 200+ business accounts.
Priority / impact:
High. It comes up in roughly one in five support chats from finance
users, and two prospects asked about it during sales calls last month.
Alternatives considered:
Tried copying invoices into a spreadsheet by hand and using the
print-to-PDF view, but neither gives clean tabular data.
Links / context:
Support tickets #4821, #4990. Screenshot of current billing page.
Notice what this gives a product owner: a clear job, a reach estimate, evidence of frequency, and a sales angle. That is enough to rank the request without a single follow-up message.
How to manage and prioritize feature requests
Templates fix intake. Prioritization decides what actually ships. Once requests are consistent, score them so the loudest voice does not win by default.
- Collect in one place. Route every request from support, sales, and the public form into a single board or table. Scattered requests get counted twice and forgotten once.
- Tag and merge duplicates. Five tickets asking for "Slack alerts" are one request with a demand signal of five. Merge them and keep a count.
- Score each request. A lightweight model like RICE works well: Reach (how many users), Impact (how much it helps each), Confidence (how sure you are), and Effort (rough build size). Score equals reach times impact times confidence, divided by effort.
- Review on a cadence. Triage weekly or biweekly. Move items into "planned," "considering," or "not now," and write one sentence on why.
- Close the loop. Tell requesters what happened. A short "we shipped this" or "we are not doing this because X" builds more trust than silence ever does.
The scoring step is where the "who it affects" and "priority" fields pay off. A request from one loud customer scores lower than a quiet pattern across fifty accounts, and your template already captured the data to see that.
Where this process breaks down is documentation. The template, the scoring rubric, and the triage rules tend to live in one person's head or a buried doc. Tools like Docsio keep your feature request process and product docs in one searchable place, so the format and the rules are findable by everyone who submits or triages a request, not just the PM who wrote them.
Best practices
- One request per submission. Bundled asks ("add export, dark mode, and SSO") cannot be prioritized or shipped independently. Split them on intake.
- Lead with the problem, not the feature. The title can name a feature, but the body must explain the job. Solutions are negotiable; problems are not.
- Make submission frictionless. Every extra required field drops completion. Ask for the minimum and infer the rest.
- Keep an internal and an external version. Customers get four questions; your team gets the full template with effort and segment fields.
- Document the format where people work. A template no one can find gets ignored. Link it from your issue tracker, your support tool, and your internal wiki.
- Acknowledge every request. Even a templated "thanks, logged it" keeps people submitting. Silence trains them to stop.
A consistent feature request template is the cheapest product-management upgrade you can make. It costs one afternoon to set up and saves a follow-up question on every request after that. For adjacent formats your team will reach for next, see our PRD template, user story template, and product documentation template. If you want the AI to draft and structure these docs for you, Docsio's AI generation turns a rough outline into a clean, searchable docs site.
FAQ
What is a feature request? A feature request is a suggestion from a customer, stakeholder, or team member to add new functionality or improve an existing capability in a product. It usually describes a problem the requester wants solved and an idea for how the product could solve it.
How do you write a feature request? State the request in one clear sentence, then explain the problem or job behind it. Describe how you imagine the solution working, note who it affects and how often, and list any workarounds you have already tried. Lead with the problem, not a fixed solution.
What should a feature request include? A useful feature request includes a specific title, the underlying problem or use case, a proposed solution, who it affects, the priority or impact, and any alternatives the requester has already considered. The problem and the affected users are the two most important fields.
How do you prioritize feature requests? Collect all requests in one place, merge duplicates, and score each one with a model like RICE, which weighs reach, impact, confidence, and effort. Review the scored list on a regular cadence, decide what to build, and tell requesters the outcome either way.
What is the difference between a bug and a feature request? A bug report describes behavior that does not match how the product is supposed to work. A feature request asks for new behavior the product does not have yet. Bugs restore expected functionality; feature requests add or expand it.