A feature request template gives structure to the ideas your customers and teammates submit. Without a template, you get vague one-liners like "make it faster" or "add dark mode." With one, you get actionable requests that include context, use cases, and enough detail to evaluate.
But here's the thing: not every team needs the same template. A two-person startup processing 20 requests a month needs something different from an enterprise product team. That team juggles thousands of requests across multiple customer segments.
This guide provides five templates you can copy and paste today, each designed for a different situation. Pick the one that fits, adapt it, and start collecting better feedback.
Feature requests without structure create three problems:
A good template solves all three by prompting the requester to provide what your team actually needs to make a decision.
That said, templates should reduce friction, not create it. If your template has 15 required fields, people won't use it. The best template is the shortest one that captures enough context to act on.
Best for: Early-stage products, small teams, public-facing feedback boards where you want maximum participation.
This template keeps things simple. Three fields, no jargon. Use it when you want to lower the barrier to submitting feedback and you're okay filling in gaps yourself.
Feature Request
Title: [Short, descriptive name for the feature]
Description: [What should this feature do? Be as specific as you can.]
Use Case: [What problem does this solve for you? How would you use it?]
When to use it: When you're collecting feedback from end users who are not technical, or when you're just getting started with a feedback process. The use case field is the most valuable part. It tells you the "why" behind the "what."
Example:
Feature Request
Title: Export dashboard as PDF
Description: I'd like a button on the dashboard page that exports the current view as a PDF file, including all charts and data tables.
Use Case: I share weekly reports with my manager who doesn't have a login. Right now I take screenshots and paste them into a doc, which takes 15 minutes every Monday.
Best for: Product teams that need to evaluate, score, and prioritize requests systematically. Works well when PMs are translating customer conversations into backlog items.
Feature Request
Title: [Short, descriptive name]
User Story: As a [type of user], I want to [action] so that [outcome].
Description: [Detailed explanation of the feature, including any specific behaviors, edge cases, or constraints.]
Acceptance Criteria:
- First criteria that must be true when this feature is complete
- Second criteria
- Third criteria
Priority Suggestion: [Critical / High / Medium / Low]
Affected Users: [Which user segment or persona does this impact?]
Additional Context: [Screenshots, links, related requests, or anything else that helps evaluate this.]
When to use it: When your product team needs structured input for sprint planning. The user story forces the requester to think about who benefits and why. Acceptance criteria make it easier to estimate effort and define "done."
Example:
Feature Request
Title: Bulk status update for feedback items
User Story: As a product manager, I want to update the status of multiple feedback items at once so that I can keep our board current after sprint planning without clicking into each item individually.
Description: Add a multi-select checkbox to the feedback list view. When multiple items are selected, show a toolbar with a "Change Status" dropdown. Selecting a status updates all selected items and triggers notifications to voters.
- User can select multiple items via checkboxes
- Bulk toolbar appears when 2+ items are selected
- Status change applies to all selected items
- Voters receive notifications for status changes
- Action is logged in the activity feed
Priority Suggestion: High
Affected Users: Product managers and admins managing large boards
Additional Context: We currently have 400+ open items and status updates take over an hour each sprint.
Best for: Support teams and product teams that deal with requests that blur the line between bugs and features. This template helps classify ambiguous reports.
Request
Title: [Short description of the behavior]
Expected Behavior: [What should happen?]
Actual Behavior: [What actually happens?]
Steps to Reproduce:
- [First step]
- [Second step]
- [Third step]
Is this a bug or a feature request?
- Bug — This used to work and is now broken
- Bug — This doesn't match documented behavior
- Feature — This works as designed but I want it to work differently
- Not sure — I need help classifying this
Environment: [Browser, OS, account plan, etc.]
When to use it: When your users frequently report things that could be either bugs or feature requests. The classification checkbox helps your triage team route items correctly. Slow performance, confusing UX, missing edge cases, and mobile compatibility issues all live in this grey zone.
Example:
Request
Title: Search doesn't find items by tag name
Expected Behavior: Searching for "enterprise" should return all items tagged with "enterprise."
Actual Behavior: Search only matches against titles and descriptions. Tag names are not included in search results.
Steps to Reproduce:
- Tag a feedback item with "enterprise"
- Use the search bar to search for "enterprise"
- The tagged item does not appear unless "enterprise" is also in the title or description
Is this a bug or a feature request? Feature — This works as designed but I want it to work differently
Environment: Chrome 120, macOS, Pro plan
Best for: B2B companies where sales, customer success, and leadership submit feature requests on behalf of customers or for strategic reasons. This template captures the business case alongside the feature description.
Internal Feature Request
Title: [Short, descriptive name]
Requested By: [Your name and team]
Customer/Account: [Which customer is this for, or is it internal?]
Business Case: [Why does this matter to the business? What happens if we don't build it?]
Revenue Impact:
- Current ARR from affected accounts: $[amount]
- At-risk ARR if not built: $[amount]
- New ARR opportunity if built: $[amount]
Effort Estimate: [Your rough guess: Small / Medium / Large / Unknown]
Deadline: [Is there a specific date this needs to ship by? Why?]
Description: [What the feature should do, from the customer's perspective.]
When to use it: When internal teams need a structured way to advocate for features. The revenue impact section forces the requester to quantify the ask. This helps product teams weigh it against other priorities. This template works especially well alongside a scoring framework like RICE or ICE.
Example:
Internal Feature Request
Title: SAML SSO support
Requested By: Jamie Chen, Customer Success
Customer/Account: Acme Corp (Enterprise plan)
Business Case: Acme Corp's IT policy requires SAML SSO for all SaaS vendors. Their annual renewal is in 90 days and they've indicated this is a blocker for renewal. Two other enterprise prospects have also listed SSO as a requirement during sales calls.
Revenue Impact:
- Current ARR from affected accounts: $86,000
- At-risk ARR if not built: $36,000 (Acme renewal)
- New ARR opportunity if built: $50,000+ (pipeline prospects)
Effort Estimate: Large
Deadline: Must ship before April 15 renewal date for Acme.
Description: Support SAML 2.0 SSO with major identity providers (Okta, Azure AD, OneLogin). Admin should be able to configure SSO from the settings page. Users should be redirected to their IdP login when accessing the workspace.
Best for: Product teams at companies where large deals drive the roadmap. This template captures the competitive and commercial context that product managers need when evaluating enterprise requests.
Enterprise Feature Request
Title: [Short, descriptive name]
Account: [Company name]
ARR / Deal Size: $[amount]
Account Owner: [Sales rep or CSM name]
Stage: [Prospect / Active Customer / Renewal Risk]Use Case: [How would this account use the feature?]
Competitive Pressure: [Is a competitor offering this? Which one? Is the customer evaluating alternatives?]
Deadline: [When does this need to ship? Is it tied to a renewal, QBR, or procurement cycle?]
Other Accounts Requesting: [List any other accounts that have asked for the same thing.]
Workaround: [Is there any current workaround the customer is using? How painful is it?]
Decision Maker Quote: [Direct quote from the customer about why this matters to them.]
When to use it: When you need to evaluate feature requests through a commercial lens. The competitive pressure and deadline fields help product teams understand urgency. The "other accounts requesting" field reveals whether this is a one-off or a pattern.
Example:
Enterprise Feature Request
Title: Custom roles and permissions
Account: GlobalTech Inc.
ARR / Deal Size: $120,000/year
Account Owner: Sarah Kim
Stage: Prospect (final evaluation)Use Case: GlobalTech has 50+ users across 8 departments. They need role-based access so marketing can only see their feedback board while product leadership sees everything.
Competitive Pressure: They're also evaluating Aha! which already has granular permissions. This is the #1 gap they've identified in our product vs the competitor.
Deadline: Procurement decision is March 30. They need to see this on a public roadmap or have a commitment by March 15.
Other Accounts Requesting: MegaCorp (existing, $45K ARR), StartupCo (prospect, $18K deal)
Workaround: Currently we'd need to create separate workspaces, which breaks cross-board reporting.
Decision Maker Quote: "We love the product but we can't roll it out company-wide without proper access controls." — VP of Product
| Situation | Template | Why |
|---|---|---|
| Public feedback board with end users | Basic | Low friction, maximum submissions |
| Product team managing a backlog | Detailed | Structured enough for sprint planning |
| Support tickets that mix bugs and features | Bug-Adjacent | Helps triage and route correctly |
| Sales and CS teams advocating internally | Internal Stakeholder | Captures the business case |
| Enterprise deals driving the roadmap | Enterprise | Includes commercial context |
You can also combine templates. Use the Basic template for your public-facing board and the Internal Stakeholder template for requests that come through sales. As long as both feed into the same prioritization process, the different formats work fine.
Here's a counterintuitive take: rigid templates can actually reduce the quality of feedback you receive.
When you force users into a strict form, several things happen:
The alternative is to let users submit feedback naturally, in their own words, at whatever level of detail they want. Your product team can add structure afterward.
This is how tools like ProductLift work. Users submit ideas on a public feedback board with a title and description. Other users vote and comment. Your team then adds tags, categories, priority scores, and links to roadmap items on the back end. You get the best of both worlds: low-friction input from users and structured data for your team.
If you want to move beyond templates entirely, a dedicated feature request tool handles the collection, voting, and organization. Your team can then focus on deciding what to build.
Whichever template you choose, keep these principles in mind:
External users are doing you a favor by submitting feedback. Respect their time. Three to five fields is plenty for a public-facing form.
The most valuable field in any template is the one that asks "why." Users are great at describing problems but often propose solutions that aren't the best approach. Teach your team to look past the proposed solution and focus on the underlying need.
Whatever template you use, make sure submitters can see what happens to their request. Nothing kills participation faster than a feedback form that feels like a black hole. Show statuses, send notifications when things change, and close the loop when you ship.
Templates that never get reviewed become stale. Set a monthly cadence to look at recent submissions. Are people skipping fields? Are you getting the information you need? Adjust the template based on what you're actually seeing.
Templates collect the input. Prioritization frameworks help you decide what to build. Use a scoring system like RICE, ICE, or MoSCoW to evaluate the requests your templates capture.
At minimum, include a title, description, and use case. The use case field is the most important because it captures why the user needs the feature. For internal teams, add fields for revenue impact and business case.
Anyone can submit a feature request. Customers, support agents, sales reps, and internal team members all provide valuable input. The key is routing each request into one system so nothing gets lost.
Yes. Tools like ProductLift let users submit feedback naturally without rigid forms. Your team then adds structure (tags, categories, priority scores) on the back end. This reduces friction for users while keeping data organized for your team.
A bug report describes something that is broken or not working as documented. A feature request asks for new functionality or a change to existing behavior. When the line is unclear, use a bug-adjacent template that helps classify the report.
For external users, keep it to 3-5 fields. Longer forms reduce submission rates. For internal stakeholders, you can use more fields (revenue impact, deadline, business case) because they have more context to share.
Use a scoring framework like RICE, ICE, or MoSCoW to evaluate requests. Weight votes by customer revenue using MRR data. Then review the highest-scoring requests during your regular planning cadence.
The right template depends on who is submitting, how much context your team needs, and where you are as an organization. Start with the simplest template that works and add structure as your process matures.
If you want to skip the spreadsheet and template management entirely, ProductLift gives you feedback boards, voting, status tracking, and built-in prioritization. Your team spends less time managing templates and more time building the right features.
Join over 3,051 product managers and see how easy it is to build products people love.
Did you know 80% of software features are rarely or never used? That's a lot of wasted effort.
SaaS software companies spend billions on unused features. In 2025, it was $29.5 billion.
We saw this problem and decided to do something about it. Product teams needed a better way to decide what to build.
That's why we created ProductLift - to put all feedback in one place, helping teams easily see what features matter most.
In the last five years, we've helped over 3,051 product teams (like yours) double feature adoption and halve the costs. I'd love for you to give it a try.
Founder & Digital Consultant
Learn when to promote feature requests to your roadmap, how to merge duplicates, notify voters, and keep credibility through the full lifecycle.
Learn 7 tactful ways to decline feature requests while keeping customers engaged. Includes response templates and expectation management tips.
Learn how to prioritize feature requests using RICE, ICE, MoSCoW, and Impact-Effort. Combine scoring models with revenue data to build what matters.
Learn how to distinguish bugs from feature requests, handle grey areas, and classify edge cases. Includes a decision framework and communication tips.
Learn 10 proven feature voting best practices to collect better feedback, prioritize by revenue impact, and build what customers want.
With bike energy 
from Utrecht 
KVK: 20145923 - BTW: NL001143413B86
