Product Feature Request Template That Ships

A good product feature request template captures four things: the exact element or screen the request touches, the user problem behind it, the proposed change, and how you will know it worked. Below is a free template you can copy, plus the reason most feature requests get misread and the fix that stops it. Most templates optimize for the reviewer's inbox by collecting priority and effort fields, but the field that actually saves a build cycle is the one that pins the request to a specific thing on screen instead of a wall of prose.

Founders and product managers write feedback all day, and prose is the default format. The trouble is that "make the onboarding cleaner" means five different things to five engineers, and the one who guesses wrong ships a clean rewrite of the wrong screen. A product feature request template exists to remove that ambiguity before it reaches the backlog.

What should a product feature request template include?

A product feature request template should include the target, the problem, the proposal, the success signal, and the routing. Miss any one of them and the request either stalls in triage or gets built to the wrong spec.

The target is the element or screen the request is about, named precisely. The problem is the user pain in one sentence, because a request without a why gets deprioritized the moment something louder arrives. The proposal is what you want changed. The success signal is how anyone will know it worked. The routing is where the request lands so it enters a real workflow instead of a chat scroll.

Most templates capture the proposal and skip the target and the success signal, which is exactly backwards. Engineering can infer a reasonable proposal from a clear problem, but it cannot infer which of six similar buttons you meant.

The free product feature request template (copy this)

Here is a compact feature request template you can paste into Linear, a GitHub issue, or a Notion doc. It works as a feature request form for a public board and as an internal software feature request template alike.

Title: [Target element/screen] — [proposed change] so [user outcome]
Target: AXButton "Continue" on the Plan Picker step (native settings window)
User problem: New users stall here because the button stays disabled with no
  reason shown, so they think the app is broken.
Proposal: Enable the button once a plan is selected; if none is selected,
  show inline helper text instead of a dead control.
Success signal: Plan-picker completion rate up; support pings about
  "stuck on plan screen" drop to zero.
Environment: macOS 14.5, App v2.3.1, Apple Silicon
Priority: High  |  Effort: S  |  Requested by: PM
Evidence: cropped screenshot of the plan-picker footer

The header line does the heavy lifting because it forces the target, the change, and the outcome into one sentence a reader parses in three seconds. Keep the body fields short. A feature request template that runs to twenty fields gets half-filled and abandoned; five fields filled every time beats twenty filled sometimes.

For public-facing boards, trim to target, problem, and proposal, and let voting handle priority. For internal use, keep the success signal, because it is the field that lets you close the loop and say the change worked.

Why do prose feature requests get misread?

Prose feature requests get misread because natural language is ambiguous about targets and generous with intent. "Tighten up the dashboard" carries a clear feeling and zero coordinates, so the reader supplies their own.

The fix is to separate what you can point at from what you can only describe. The target should be captured, not written; the intent should be written, not guessed. When both live in the same paragraph, the reader has to reverse-engineer which words are the target and which are the wish.

The table below shows the same request in its vague form and its specific form, and why the difference matters.

The specific column is not more work if the target is captured for you. That is the entire argument for pointing at the thing instead of describing it.

How do you file a feature request straight to Linear, GitHub, or your agent?

You file it by capturing the target on screen and routing the structured result, instead of retyping it into a form. The fastest version of this is point-and-speak: you hold ⌥⌘A, circle the element you want changed, and speak the request out loud.

On macOS, the tool resolves the element under your pointer via AXUIElementCopyElementAtPosition, returning its role, title, value, and frame. It transcribes your speech on-device, binds deictic words like "this" and "here" to where the pointer was at the instant you said them, and produces a named target plus your instruction. That package files to Linear or GitHub as structured fields, or to your AI coding agent over a local MCP server.

Routing to an agent is where the format pays off most, because how AI agents know which UI element you mean depends entirely on whether you handed them a resolved target or a picture to guess against. The same principle governs how to give Claude Code context that it can act on without a clarifying question. A named element is context an agent can execute; a screenshot is context it has to interpret.

A point-and-speak request filed to Linear or GitHub carries the element as a real field, so the developer clicks straight to the code rather than hunting for the control you described.

Product feature request template vs bug report: what is different?

A feature request describes something that should exist; a bug report describes something that already broke. The template fields overlap heavily, but two differ. A feature request needs a user problem and a success signal, while a bug report needs steps to reproduce and expected versus actual behavior.

The shared spine is the named target and the evidence. Both formats fail the same way, by describing the target in prose and forcing the receiver to guess. If your team already uses a feature enhancement request template, adding one field for the named target upgrades it more than any other change.

For founders and PMs who review builds daily and want feedback that points at the exact thing and lands in a real workflow, PinVari captures the named target and files it for a one-time $39, on-device, with no API keys and nothing uploaded by default.

FAQ

What is a product feature request template?

It is a reusable structure for proposing a change to a product, capturing the target, the user problem, the proposal, the success signal, and where the request routes. A good template removes ambiguity so engineering builds what you meant rather than what the prose implied.

What fields should a feature request form have?

At minimum: the named target element or screen, the user problem, and the proposed change. For internal use add a success signal and routing; for a public board, keep it to three fields and let voting handle priority, so people actually fill it out.

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

A feature request proposes something new and needs a user problem and a success signal. A bug report documents something broken and needs reproduction steps and expected-versus-actual behavior. Both should name the exact target rather than describe it in prose.

How do I write a feature request an AI agent can act on?

Give it the named UI element as structured data, the change tied to that element, and a cropped screenshot. An agent connected over a local MCP server can read the element's role, title, and frame, then map it to the codebase instead of interpreting a paragraph.

Can I file feature requests against native macOS apps?

Yes, if the capture tool reads the macOS Accessibility API. That tree exists for native apps and Electron windows, so the tool can resolve the element you point at anywhere on screen. Browser-only tools cannot, because there is no DOM outside the browser.

How long should filing a feature request take?

Typing a full request into a form runs two to three minutes. Pointing at the element and speaking the request, then letting the tool resolve and file it, runs about ten seconds. Cheap filing is what gets the small, high-value requests written down instead of forgotten.