Blog

Product Teams Can Copy 4 Feature Request Templates

Product Teams Can Copy 4 Feature Request Templates

Sketches of request cards and voting marks

A feature request template is a short, repeatable form that makes people describe a need the same way every time, so product teams can judge it fast. At minimum, collect a title, the problem, a proposed solution, the impact, and a contact for updates. Copy this one-liner: "Title: [outcome]. Problem: [what happens today]. Idea: [what could help]. Impact: [who, how often]. Contact: [email]."

TL;DR:

  • Keep public intake brief with a title, problem, why it matters, and contact; collect deeper details conditionally or during internal triage.
  • Ask for the workaround, affected users, frequency, and a measurable success signal; describe the problem before suggesting a solution, and keep that suggestion a sketch.
  • Use RICE to compare reach, impact, confidence, and engineering effort, estimated during triage; a candidate status does not promise delivery.
  • Merge duplicates under the clearest, best supported, or earliest request, preserving votes, comments, files, and contacts; compare problem statements before combining similar titles.
  • Treat votes as evidence of reach, not a verdict, and send honest status updates; planned or under review labels are not delivery dates.

Table of Contents

Which feature request form template should you copy?

Several templates can suit different intake channels. Pick the one that matches who is submitting, then trim fields you will not use.

  • Template A, minimal public request: title, a brief description of the problem, why it matters to you, and an email for updates. A compact form can work with just five questions and conditional logic, so most people only see four fields, as FormSnapp's template shows.
  • Template B, detailed product-team intake: problem, current workaround, proposed solution, affected users, frequency, success metric, attachments, and a priority hint.
  • Template C, bug-adjacent or technical: steps to reproduce, environment, expected versus actual behavior, logs, and a proposed mitigation.
  • Template D, sales or enterprise-driven: account name, revenue at stake, legal or contractual constraints, and the success metric the customer cares about.

Here is Template B filled in, so you can see the expected level of detail:

  1. Title: Let me export the roadmap as a CSV file.
  2. Problem: I share roadmap updates with my leadership team every Monday. I copy items into a spreadsheet by hand, which takes time.
  3. Current workaround: Manual copy and paste, plus screenshots when the list is long.
  4. Proposed solution: An export button on the roadmap page. Non-goal: scheduled exports.
  5. Impact: Our product managers use it regularly. Success means the Monday prep takes less time.
  6. Contact: [email protected]

Notice how the example stays concrete without turning into a specification.

What should each field capture, and how do you write it well?

Good requests arrive triage-ready when every field has a clear job. Practitioner guides agree that a request should describe the workflow and the problem to solve before any behavior is proposed, as this guide to writing good feature requests explains.

  • Title: a concise, outcome-focused one-liner. "Export roadmap to CSV" beats "Export problem."
  • Problem statement: what you observe, the context, the steps you take, and why today's behavior falls short.
  • Current workaround: what people do instead and what it costs them. This is often the truest signal of impact.
  • Proposed solution: a sketch, not a spec. Add non-goals so scope does not creep.
  • Impact: who is affected, how often, and one measurable success signal with a direction (for example, "prep time goes down").
  • Attachments and links: screenshots, logs, sample data, related tickets.
  • Metadata: requester name and role, product area, environment, date.

Advice from Feature requests that don't suck points the same way: focus on the problem, the observed evidence, and the desired outcome rather than prematurely specifying implementation.

Pro Tip: Ask for the workaround and its cost. Someone who regularly spends time on a hack tells you more than someone who writes "this would be nice."

How do you triage and prioritize feature requests with RICE?

Treat a feature request as a pre-commitment triage record, separate from backlog and implementation artifacts. ProjectManager's RICE guide describes keeping triage apart from delivery commitments, so you never promise a build before you have decided to make one.

RICE scores Reach, Impact, Confidence, and Effort. It cuts emotion out of comparisons because every request gets the same four questions. Your template fields map straight onto the inputs:

  1. Reach: affected users and frequency from the Impact field.
  2. Impact: how much the success metric would move.
  3. Confidence: how much evidence came with the request: attachments, repeat reports, a described workaround.
  4. Effort: an engineering estimate, added during triage.

A score is (200 × 2 × 0.8) ÷ 4 = 80. Compare that against another request scoring 30, and the order is clear.

Teams that follow a template built for triage include a lifecycle status field, review the backlog monthly, and close stale requests.

Use clear states such as duplicate, needs research, candidate, backlog item, and closed. A candidate is not a delivery promise. A triage group can include product, engineering, and support or sales representatives.

Where should you collect requests, and how do you set up structured intake?

Each channel trades off transparency, friction, and completeness:

  • Public feedback board: best for transparency, since others can see and vote on ideas.
  • Embedded in-app form: low friction for active users. We cover this approach in our guide to feedback inside your app.
  • Internal form or email: captures what sales and operations hear. Our ready replies for support teams help here.
  • GitHub issue forms: developer-centric and strict about fields.

Conditional fields keep forms short. Typeform-style forms use one field per screen and tailor follow-up questions to the submitter's role.

For developer intake, a feature_request.yml issue form defines fields such as title, problem, proposed solution, impact, and additional context, so contributors cannot skip them. Organization-wide setups store these files in .github/ISSUE_TEMPLATE.

Route submissions into your backlog tool with webhooks or Zapier, and tag the source so triage can weigh it. Collect only the personal data you need. When a form is embedded for signed-in users, prefill hidden fields such as email, as Formcrafts supports.

How do you raise submission quality and keep requesters in the loop?

A few small changes can pay off quickly:

  • Make core fields required and deeper ones optional or conditional.
  • Show a completed example as inline help so people know how much detail to give.
  • Put your most common template first in the chooser. For .github templates, filename order controls this.
  • Automate status updates by email or roadmap status, so reporters see progress and stop resubmitting.

Pro Tip: Seed your form with the example from Template B. People copy the level of detail they see.

How do you handle duplicate requests and merge feedback?

Duplicates are a sign your idea is popular, not a mess to delete. The goal is to keep one canonical request and preserve every voice that joined it.

Pick the canonical request using three rules: choose the one with the clearest problem statement, the most evidence, or the earliest date, in that order. Then merge the rest into it: move votes, comments, and attached files across, and keep each requester's contact so they receive updates later. Never delete the duplicates outright. Close each as "duplicate of" with a link to the canonical one, so the original submitter can see where their idea went.

Canonical request merge and duplicate closure flow

Watch for requests that look alike but describe different problems. Two people asking for "better export" may want a CSV file in one case and a scheduled report in the other. Compare the problem statements, not the titles. If the problems differ, link the requests as related instead of merging them.

Run a duplicate check as the first step of every triage session. Searching the board by keyword before a request enters scoring keeps reach numbers honest, because otherwise the same need gets counted twice or split into several weak scores.

A public board helps here too. When submitters can search before posting, many will vote on an existing idea instead of creating a new one. Make the search box prominent and prompt people to look before they write.

How should you communicate request status updates and feedback?

Silence is the main reason people resubmit. Tell requesters what happened, even when the answer is "not now."

Match the channel to the moment:

  • Automatic emails when status changes, such as under review, plan, in progress, or shipped.
  • A public roadmap for people who want the big picture. Our look at public product roadmap formats compares different ways to present one.
  • A short personal reply for high-value accounts or when you need more detail.
  • Release notes or a changelog that credit the request when something ships.

Keep your wording honest about commitment. "Under review" and "planned" are not delivery dates, and the separation between triage and implementation described earlier applies to the messages you send, too. If you decline a request, say why in a sentence or two: it conflicts with the product direction, it affects too few people right now, or it needs more evidence. People accept a clear no far better than no answer at all.

Close the loop at the end, too. When a feature ships, notify everyone who voted or commented, and ask whether it solved their problem. That reply doubles as validation of your success metric. For keeping the roadmap and the backlog consistent while you do this, our playbook on roadmap and backlog drift offers a practical routine.

How do you encourage engagement and voting on feature requests?

Voting only works when people see the board and understand it. Start with visibility: link to it from your app, your help center, and your support replies.

Lower the effort to participate. Let people vote with one click, and keep the submission form short using the minimal Template A. Ask for detail only from those who add a new idea.

Show that votes matter. When you ship something from the board, say so publicly and thank the people who asked. Status labels also reward participation, because a voter can see an idea move from under review to planned.

Moderate with a light hand. Pin a short guide at the top: search first, describe the problem, vote on existing ideas. Merge duplicates quickly so vote counts concentrate on one request instead of scattering.

Invite voting at the right moments, such as after a support conversation or inside the app next to a related feature. Our overview of always-on feedback channels and a weekly probe covers how to keep those prompts steady without nagging.

Finally, treat votes as one input, not the verdict. Vote counts show reach and enthusiasm, but your RICE scoring still weighs impact, confidence, and effort.

How do you categorize and tag feature requests for better management?

Tags turn a pile of requests into something you can filter, count, and act on. Keep the system small enough that people will use it.

Start with three tag types:

  • Product area: billing, onboarding, reporting, integrations, and so on. This tells you which team owns the request.
  • Request type: new feature, improvement to an existing feature, integration, or bug-adjacent.
  • Source: public board, in-app form, sales, support, or GitHub. Source matters because a request from a paying account may call for a different response than an anonymous idea.

Capture product area and source from the form's metadata fields so triage does not have to guess. Add user segment or plan tier as a fourth tag if your product has distinct audiences, as Responsly's SaaS template does by asking for user segment and role.

Limit the list. A small set of well-defined tags beats a sprawling set of overlapping ones, and every tag needs a clear definition that triagers can check. Review the tag list regularly: merge near-synonyms, retire unused tags, and rename any that confuse people.

Tags also make reporting practical. Filter by product area before a planning meeting to see which problems keep coming up, or filter by source to compare what customers ask for with what your sales team hears. Combined with RICE scores, that gives you an objective view of where to invest.

How do feature request templates work with a public feedback board like Petĩra?

A template defines what you ask for, and a board gives people a place to submit and see it. In our product, a public feedback board lets users post ideas and vote on them, so requests that would otherwise sit in email and chat land in one place.

Here is how we recommend wiring a template into it:

  1. Use Template A as the public form. Title, problem, why it matters, and an email for updates keep posting easy.
  2. Pin an example request at the top of the board so people see the expected detail.
  3. Move deeper fields to triage. Your team adds workaround, affected users, and effort notes after submission, using Template B as an internal checklist.
  4. Use statuses such as under review, planned, in progress, and shipped to carry each request through the states described earlier.
  5. Route sources into one place. We support imports from Canny, Fider, or CSV, plus Slack, Discord, and GitHub integrations, so older requests and developer issues can sit alongside new ones. We also offer custom domains and an embeddable widget for in-app submission.

For GitHub-heavy teams, keep the .yml issue form for contributors and mirror accepted ideas to the board so non-developers can vote. Tag each entry by source so triage knows where it came from.

What changes when feature requests all look the same?

Triage gets faster and more honest the moment every request answers the same questions. Reviewers stop chasing missing context, scoring becomes comparable, and arguments move from opinions to evidence. We built our board around that idea: capture ideas from every channel in one place, let users vote, and keep prioritization visible. Compare your current process against the templates above, and see which fields you are missing.

— Aron

Try a hosted feedback board that takes your templates

We built Petĩra for teams that want a public board, status tracking, and imports in one place. You can paste Template A into your board, bring existing requests over by CSV, and connect Slack, Discord, or GitHub. Your first steps:

  • Start on the free plan at €0 per month, or compare Pro at €19 per month and Team at €49 per month on the same page.
  • Import your current requests, pin an example, and publish your roadmap.

Petira

See what is included at Petira, then start with the pricing page.

FAQ

How do you write a feature request?

State the problem first, then the idea. Describe what happens today, who is affected, what they do instead, and what a good outcome looks like. Keep the proposed solution as a sketch and add contact details so the team can follow up.

What is a feature request?

A feature request is a record of something a user or teammate wants a product to do. It works best as a triage record that keeps the evidence and a decision, separate from backlog items or delivery commitments, as ProjectManager's RICE guide describes.

What do open-source feature request templates ask?

They keep it simple. OpenSearch's template asks whether the request relates to a problem, what solution you would like, what alternatives you have considered, and for any additional context.

How do you create a feature request form with required fields?

Choose a form tool or a GitHub issue form, make the title and problem required, and keep the rest optional or conditional. A Cognito Forms template shows fields for account email, feature priority, feature type, and business use case.

Sources

Recommended

Product Teams Can Copy 4 Feature Request Templates · Petĩra