What this template is for
Feature requests are the second-highest-volume ticket type in most Jira projects, and the most neglected. Every product team has a backlog of feature requests filed by sales, support, and customers - most of which were never triaged and quietly rot.
This template forces two pieces of discipline:
- Required fields on the create screen - problem statement, proposed solution, business value, requestor count. Without these, triage is impossible; with them, triage takes minutes instead of meetings.
- STM-automated triage sub-tasks - acknowledge the requestor, check for duplicates, confirm requestor count, estimate value, decide, communicate. Created automatically on every new feature-request ticket so nothing falls through.
When to use it
Use this template for every external feature request - whether it comes from a customer ticket, a sales call, a customer support escalation, or an internal stakeholder. Use the user-story template instead for work the team has already committed to do.
A feature-request ticket should never go straight into a sprint. It should be triaged into either a decline reply, a backlog item, or one or more user stories scoped during refinement.
Fields to add to your Jira create screen
These are the fields a project admin should make sure exist on the Create Issue screen for this issue type (Project settings → Screens). Without these on the screen, reporters can't provide the information triage needs - and STM can't reference them either.
| Field | Example value | Required |
|---|---|---|
Summary | Bulk export attachments to S3 from a Jira filter | Yes |
Problem Statement (custom) | Customer is stuck doing X because Y | Yes |
Proposed Solution (custom) | What the requestor thinks the solution should look like | Yes |
Business Value (custom) | Retention / expansion / new-logo / cost reduction | Yes |
Requestor Count (custom) | 1 customer / 5 customers / 20+ customers | No |
Requested By | Customer name, internal team, or 'multiple' | No |
Triage Decision (custom) | Build now / Build later / Decline / Need more info | No |
Triage Decision Reason (custom) | Why this decision was made | No |
Linked Epic | PROJ-1023 - if accepted into a roadmap epic | No |
Components | checkout, integrations | No |
Labels | from-customer, sales-blocker | No |
Note on custom fields. STM currently supports up to 5 custom fields per template. You can add as many custom fields as you like to your Jira Create Issue screen - the 5-field limit only applies if you want STM to set or update those custom fields itself.
Sub-tasks STM creates automatically
Build an STM sub-task template containing the items below, then wire it to an On Create Issue Executor scoped to this issue type. Whenever a new issue of this type is created in the project, STM creates the full sub-task set in one step - with assignee, due date, and components inherited from the parent unless you override them.
- Acknowledge the request - reply to requestor within 5 business days
- Check for duplicates and link if found
- Confirm requestor count - is this 1 customer or 10?
- Estimate business value with input from Sales and Customer Success
- Triage decision - Build now / Build later / Decline / Need more info
- Communicate decision to requestor and link any follow-up work
Common questions
What's the difference between a feature request and a user story in Jira?
A feature request is an unvalidated input - a problem someone wants solved. A user story is the validated, scoped work the team has committed to do. Most feature requests should not become user stories directly; they should be triaged first, then if accepted, broken into one or more stories during refinement.
Who owns triage of Jira feature requests?
A named product manager, not 'product' as a group. Without single ownership, feature requests pile up unanswered and customers eventually stop submitting them. Set an SLA - even if it's 'we will respond within 30 days' - and stick to it.
Should sales or customer support log feature requests directly in Jira?
Yes, but with structure. Open-text feature requests filed by non-product people produce duplicates and miss the business-value field. Use a feature-request template (this one) so sales and support fill in problem, business value, and requestor count up-front. Product can then triage without going back for context.
How do you avoid feature-request backlog rot?
Make 'requestor count' a queryable field and run a quarterly cleanup: anything with one requestor and no triage decision for 6+ months gets auto-declined with a polite message. The signal-to-noise ratio of your backlog improves dramatically when you stop letting one-off requests live forever.
Automate the sub-tasks with STM
STM Issue Templates saves the sub-task list above as a reusable template and creates them on every new issue of this type - via an Executor on issue creation, on status transition, or triggered manually from the issue's "Create bulk sub-tasks" menu. STM does not change the parent issue's create screen (that's a Jira project-settings job) but it removes the manual work of creating the sub-tasks every time.
Try STM on the Atlassian Marketplace ↗ See how STM templates are built →