Software Feature Request Template: Idea to Spec

A software feature request template is a short spec that turns a raw idea into something an engineer can estimate: the problem, the user, the desired outcome, and the exact UI control the change touches. Use it as a Linear issue, a GitHub issue, or a Slack thread that later becomes both.

Most templates fail because they start with a solution ("add a dropdown") and never pin the screen, so the same idea gets rebuilt as four different widgets.

This post walks one request from a founder Slack ping to a filled spec. If you already have a prose feature request template, treat this as the start-to-finish pass of that same discipline.

What belongs in a software feature request template?

A software feature request template needs six fields: title, problem, user, current behavior, desired outcome, and location. Priority, effort, and attachments come after those six.

Lead with the problem, not the widget. "Add guest checkout" is a solution guess. "First-time buyers abandon after the account form appears" is a problem the team can solve more than one way.

The location field is the one most intake docs skip. Write the screen plus the control, and if you can, the accessibility name: AXButton "Continue to payment" in the cart footer.

That is the same habit that makes a product feature request template usable by an engineer or an AI agent. A template that only stores a screenshot forces someone to re-identify the control later.

Keep the template short enough that a founder will finish it in one sitting. Seven required fields is already too many for a Slack-to-Linear hop.

Software feature request template you can copy

Paste this into Linear, GitHub Issue Forms, or a Notion page. Keep the field names stable so you can search across sources.

Title: [Outcome] for [user] on [screen]
Problem: What can the user not finish, and why does it matter this week?
User: Who has this? How often? Which plan or segment?
Current behavior: What happens today, on which screen, after which click?
Desired outcome: What should be true after we ship? (this is the test)
Location: Screen + named element (role + label if you have it)
Constraints: What we will not change (copy, tokens, APIs, scope)
Priority: P0 / P1 / P2 and one sentence why
Evidence: screenshot, clip, or capture bundle

The outcome line is acceptance criteria. Write it as a testable sentence: "A first-time buyer can pay without creating an account, and the order still has an email for the receipt."

A real example, start to finish

I will use a fake store, Northline Supply, so the names stay concrete. The founder pings in Slack at 9:14.

The raw idea (too early to build). "We should let people check out as a guest. The account wall is killing us."

That is a mood. It is not a spec. I do not open Figma yet.

Step 1 — run the product yourself. I add a $48 clamp to the cart on staging. I click Continue to payment. An account form covers the cart. Email, password, "Create account." There is no guest path.

Step 2 — fill the problem and user before the solution. I write: first-time buyers on mobile cannot pay without inventing a password. Support already has three tickets this month from people who thought they were buying, not joining.

Step 3 — name the location. I do not write "the thing in the middle." I write: Cart /checkout, AXButton "Continue to payment", then the AXTextField "Password" that appears after the click.

On a Mac I hold ⌥⌘A, circle the button, and say the request. A point-and-speak app can resolve the named accessibility element, transcribe on-device, and keep a cropped screenshot of that region.

PinVari is one such app. It binds "this" to the pointer at the instant I said it, reads the window text, and can file the bundle to Linear or GitHub. Transcription stays on-device. Nothing is uploaded by default.

Step 4 — write the outcome as a test. "A first-time buyer who declines an account can still pay, and the order confirmation email still sends." That is the test. "Add a guest checkbox" is not.

Step 5 — write the constraints. No new color tokens. No change to Stripe test keys. Do not remove the account path for returning buyers. Do not invent a new cart page.

Step 6 — file it once, in the tracker the team already uses. I paste the template into Linear as NTH-184. I attach the capture. I do not also paste a different version into Notion and a third into Slack.

That workflow is the same one we use for point-and-speak bug reports in Linear and GitHub. A feature request is a bug report that describes a missing outcome instead of a broken one.

The filled spec (NTH-184)

Title: Guest checkout for first-time buyers on /checkout

Problem: First-time buyers hit an account wall after Continue to payment and abandon. Support has three tickets this month from people who thought they were buying, not joining.

User: First-time mobile buyers, roughly a third of staging traffic this week. Returning buyers already have accounts.

Current behavior: Cart → AXButton "Continue to payment" → account form with AXTextField "Password". There is no skip.

Desired outcome: A first-time buyer can pay without creating an account. The order still has an email for the receipt. Returning buyers still see sign-in.

Location: /checkout · AXButton "Continue to payment" · account sheet · AXTextField "Password"

Constraints: Keep the existing Button component. No new tokens. Stripe test mode only. Do not redesign the cart.

Priority: P1. Same-week because the campaign landing page is live and the wall is new.

Evidence: capture bundle with the named element, crop, and spoken line.

An engineer can estimate this in ten minutes. An AI coding agent can start from the location field instead of guessing which of two similar buttons you meant.

How do I hand this spec to an engineer or an agent?

A software feature request template that dumps into email is a graveyard. Route each filled spec to Linear or GitHub with the field names intact.

Keep Location as its own heading so you can search Location: later. Keep Desired outcome as its own heading so QA can copy it into a test case without rewriting.

If your team ships with Claude Code or Cursor, the location field can become a resolved element path, not a screenshot the model has to guess from. The connector talks to a local MCP server on 127.0.0.1:3402 when PinVari is installed and running.

The agent-facing tools are pinvari_next_instruction (element path, spoken line, crop) and pinvari_mark_done. Mid-task the agent can call pinvari_request_capture and the notch island lights up so you can point again.

I do not paste a 40-turn Slack thread into the agent. I paste NTH-184.

Jam.dev is excellent for browser console logs. It will not name a native control in your Electron checkout. Marker.io is a $39+ / month website annotation product. CleanShot X draws arrows and knows nothing about the AX tree.

Name the control before you debate the widget. The widget is cheap to change. The wrong screen is expensive.

Linear card

Type: issue in the product team project

Capture: template body plus attachments

Resolution: searchable fields, one owner

GitHub issue

Type: repo-adjacent request

Capture: Issue Forms with the same ids

Resolution: good when the change is in that repo

Point-and-speak into the tracker

Type: native Mac overlay plus local MCP

Capture: circled element, crop, window text, URL

Resolution: named control with confidence and provenance

What should I refuse to put in the template?

Do not put a Figma link in place of a problem. A mock is a proposed solution. Keep it under Evidence, not Problem.

Do not put a numeric priority without a sentence. "P0" without "the campaign is live" is a shrug.

Do not put five screens in one request. Split. Guest checkout is one request. "Also redesign the receipt" is another.

Do not invent metrics. If you do not have an abandon rate, write the support tickets you do have.

Do not let the founder rewrite the spec in standup. The filled template is the source. Standup is for blockers.

If you review builds on a Mac and you want the location field filled without typing, the pricing page is the one-time $39 launch licence for PinVari. Team seats exist. There is no subscription for the core app.

FAQ

What is a software feature request template?

It is a fixed field set that turns an idea into a spec: problem, user, current behavior, desired outcome, and location. The template is the same whether the request comes from Slack, a customer form, or a founder standing behind a laptop.

How is this different from a bug report?

A bug report describes a broken outcome. A feature request describes a missing one. Both need a named location. Both fail when the only evidence is "the button on the right."

Can I use this template in Linear and GitHub at the same time?

Use one tracker as the source of record. If GitHub is where the pull request lives, file there. If Linear is where the roadmap lives, file there and link the PR. Do not keep two living copies.

What if I do not know the accessibility name?

Write the screen URL or window title plus the visible label. On a Mac, a point-and-speak capture can resolve role, label, and frame from the Accessibility API, with OCR fallback on canvas or some Electron surfaces.

Should I include a solution sketch?

Yes, under Evidence or Constraints, never as the title. "Guest checkout" can stay as a proposed path. The outcome sentence is what QA tests.

How long should a filled request be?

One screen of text. If you need a design doc, link it. The template is the index card, not the novel.