Feature Request Template: 5 Formats That Ship

A good feature request template captures the problem, the user who has it, the desired outcome, and the exact place in the product it touches, in that order. The five formats below cover a quick idea, a full product feature request, an enhancement to something that already exists, an intake form for outside requesters, and a spec dense enough to hand an engineer or an AI agent. Most feature request templates fail because they lead with a solution ("add a dropdown here") instead of the problem, so the team builds the requester's guess rather than the real need.

Founders and PMs live this problem. You review a build, you have a clear idea of what should change, and by the time it reaches a developer it has been paraphrased twice and lands as the wrong thing. A template fixes the structure, but structure alone does not tell the developer where the change goes, which is why the strongest requests also name the element they touch.

What goes in a good feature request template?

A good feature request template has five fields: the problem, the affected user, the current behavior, the desired outcome, and the specific location in the product. The location is the field most templates omit, and it is the one that decides whether the request lands in the right place.

Lead with the problem, not the solution. "Users abandon checkout because they cannot tell shipping is free" is a problem the team can solve many ways. "Add a green banner" is one guess at a solution, and locking to it early throws away better options.

Tie the request to a real user and a real outcome. "As a first-time buyer, I want to know shipping is free before I enter my card, so I do not abandon" carries the who, the what, and the why in one line. The outcome is the acceptance criteria in disguise, so writing it well makes the request testable.

The feature request template, ready to copy

Here is the base template. It is deliberately short, because a template people will not fill in is worse than none.

Title: [Outcome] for [user] on [screen/element]
Problem: What is the user unable to do, and why does it matter?
User: Who has this problem? How often?
Current behavior: What happens today, on which screen/element?
Desired outcome: What should happen instead? (this is the acceptance test)
Location: Screen + named element, e.g. AXButton "Checkout" in AXGroup "Cart Footer"
Priority: P0 / P1 / P2 and the reason

The Location line is the upgrade most teams miss. Writing "AXButton 'Checkout' in the Cart Footer" instead of "the checkout button" means the developer, or an AI agent, knows exactly which control the request touches and can find it in the code by its label. The same discipline that makes a good bug report example actionable makes a feature request actionable: name the element, do not describe its position.

Which feature request template format fits your team?

Different situations need different depth. Here are five formats built on the same fields, from lightest to heaviest.

The product feature request template is your default for roadmap candidates: full fields, a priority, and a reason. The feature enhancement request template is a variant tuned for changes to something that already ships, where the "current behavior" and "desired outcome" fields carry most of the weight because the requester is describing a delta.

The feature request form and feature request form template are for people who are not on your team. Strip the jargon, guide them through the fields, and translate their submission into the software format internally. The software feature request template is the densest: it adds an explicit acceptance test and a named element so an engineer or an AI coding agent can start immediately.

How is a feature request template different from a bug report?

A feature request describes something that should exist but does not, while a bug report describes something that exists but behaves wrong. The templates share fields, environment, location, expected behavior, but the framing differs: a bug's "actual result" is a defect, and a feature's "current behavior" is simply the absence of the thing you want.

They converge on one requirement. Both need the exact location, named by its element, not its pixels. A bug that says "the button is broken" and a feature that says "add a button here" both leave the developer guessing which control and where, and both are fixed the same way: name the element.

This is also why the same capture tool can serve both. If you can point at a control and speak, you can file a bug against it or request a change to it with the same motion, and the receiver gets the named element either way.

How do you point a feature request at the exact UI element?

You anchor a feature request to a UI element by capturing the element's accessibility identity, its role, label, frame, and parent chain, rather than describing where it sits on screen. On macOS the operating system already exposes this. Understanding what the macOS Accessibility API is used for shows why: the OS maintains a named tree of every control for VoiceOver and keyboard navigation, and any tool can query the element under a point with AXUIElementCopyElementAtPosition.

That is the same reason machines can act on a named request. How AI agents know which UI element you mean comes down to whether you gave them the resolved element or a picture to guess against. A request that carries AXButton "Checkout" lets an agent search the code for that label; a request that says "the button at the bottom" makes it OCR a screenshot and hope.

The capture is push-to-talk. You hold ⌥⌘A, circle or point at the element the request touches, and speak the change, for example "make this show the free-shipping threshold before checkout." The tool resolves the named element with a confidence score, transcribes on-device, crops the screenshot, and files the request to Linear or GitHub as a structured field, or hands it to your AI agent over a local MCP server. A point-and-speak request to Linear and GitHub lands with the element attached, so the developer clicks straight to the code.

For product teams that want feature requests to land as named, actionable items instead of prose someone reinterprets, PinVari ships this at a one-time $39 launch price with on-device capture, no API keys, and nothing uploaded by default. Point at the element, speak the change, and the request files itself against the exact control it touches.

FAQ

What should a feature request template include?

A feature request template should include the problem, the affected user, the current behavior, the desired outcome, the specific location in the product, and a priority. The location, named by its UI element rather than its position, is the field most templates skip and the one that keeps the request from being reinterpreted.

What is the difference between a product feature request template and a feature enhancement request template?

A product feature request template is for new capabilities and covers all fields plus priority for roadmap ranking. A feature enhancement request template is tuned for improving something that already ships, so its "current behavior" and "desired outcome" fields carry the most weight because you are describing a change to existing UI.

How do I create a feature request form for non-technical requesters?

Use a feature request form template that guides requesters through plain-language versions of the same fields: what is the problem, who has it, and what would you like to happen. Translate their submission into your internal software feature request template, adding the named element and acceptance test before it reaches an engineer.

How is a feature request different from a bug report?

A feature request asks for something that should exist but does not; a bug report documents something that exists but behaves incorrectly. They share most fields and both require the exact named element as the location, so the developer or agent knows precisely where the change or fix belongs.

Can an AI agent build directly from a feature request template?

Yes, if the request includes the named element and an explicit acceptance test. An agent can consume a software feature request template over MCP, look up the element label in the codebase, and scaffold the change. A prose request with a full-window screenshot forces the agent to guess the target.

Where should feature requests live so they get built?

Wherever your team already works: Linear, GitHub, or Jira for internal requests, and a form tool like Canny or Notion for external ones. What matters more than the location is that each request carries the named element and outcome, so it stays actionable when a developer or agent picks it up weeks later.