You came for a feature request template — the fields, the headings, something to drop into a form or a doc. It's below; take it. But know the failure mode: a feature request form in a tracker, a spreadsheet, or an intake ticket captures the ask once and then strands it. The request never connects to the product decision it's supposed to inform, so a good idea dies in a backlog and an accepted one loses the thread between "we'll do it" and what actually shipped. Draftlize gives you the same eight fields — and links each request to the decision and spec cards it touches, so it stays traceable from intake all the way to ship.
This is the whole template. It works in a form, a tracker, or a doc — it's the same shape product teams have used for intake forever. Use it as-is. The next section is about what changes when each request stops being a row in a list and starts linking to the decisions it feeds.
The ask in one line, phrased as the outcome — "Let users export a thread to PDF," not "PDF feature." If you can't name the outcome in a sentence, the request isn't shaped yet.
Who asked and when. Not for credit — for the follow-up. When the request resurfaces in triage, this is who you go back to for the detail the form didn't capture.
The underlying need, stated without the solution baked in. What is the user actually trying to get done, and what stops them today. This is the field that survives even when the proposed solution gets thrown out.
How the requester imagines solving it — a starting point, not a commitment. Useful signal, but kept separate from the problem so you can accept the need while rejecting the specific fix.
The concrete situation it shows up in and how often. "Every Monday when I assemble the weekly report" beats "would be nice." Frequency is what separates a paper cut from a one-off.
Who it affects and how badly — how many users, how acute the pain, what it unblocks. The field that lets you compare two requests that both sound reasonable in isolation.
Where it sits against everything else — now, next, later, or won't-do. A priority is a comparison, not a feeling; it only means something relative to the other open requests.
The product decision or spec this request informs or depends on. In a form this is a blank you'll leave empty. It's the field that decides whether the request goes anywhere after intake.
That's the template. Below: why a request form is an island — and how we wire each request into the decisions it should move.
A feature request form is good at one thing: getting the ask out of someone's head and into a field. But the form is a dead end. It lives in a tracker, a spreadsheet, or a typeform export, with no thread connecting it to the product decision it's supposed to inform. Captured is not the same as considered.
You triage a request and say yes. Now what? The decision to build it lives in one place, the spec in another, the original request in a third. By the time it ships, nobody can answer "did we actually solve what was asked?" — because the request and the work were never linked.
You reverse a product decision in week seven. Which feature requests rode on it? The ones you accepted because of the old call, the ones you declined because of it — all silently orphaned. Nothing links them back to the decision, so the reversal happens blind.
In Draftlize a feature request isn't a row in a spreadsheet — it's a typed card with those exact fields: Title, Problem, Proposed solution, Use case, Impact, Priority, and the link. Structured, addressable by ID, and citable from a decision or a spec instead of stranded in an intake tool.
Because the request links to the decision and the spec it informs, accepting it isn't a status change in a vacuum — it's an edge in the graph. You can trace a shipped feature back to the request that asked for it, and answer "did we solve the actual job?" with a link, not a memory.
Because the link is real and not a note, reversing a decision turns every request that rested on it stale automatically — the way a build system invalidates everything downstream of a changed file. And an AI agent reads those requests over MCP before it drafts the next spec, so intake becomes context, not an archive.
A request form tells you what someone wants. It can't tell you whether the decision that would grant it still holds.Keep the eight fields. Let the substrate keep them connected.
A feature request is a structured record of something a user or stakeholder wants the product to do — the problem behind it, the proposed solution, the use case, and the impact. A good one captures the underlying job, not just the asked-for feature, so you can solve the real need rather than the literal request.
Title, problem, proposed solution, use case, impact, priority, and a link to the decision or spec it informs. The problem field matters most: a request that only states a solution ("add a dropdown") hides the job it is trying to do, and the job is what you actually prioritize against.
Score them against a consistent framework — RICE, value versus effort, or weighted scoring — using the problem and impact, not the volume of asks. Ten people requesting the same workaround is one problem, not ten features. Rank by the job to be done, then decide.
Each request is a card linked to the decision and spec it informs, so accepting one is an edge in the graph, not a status change in a vacuum. Reverse a decision later and every request that rested on it flags itself stale automatically — the reversal stops happening blind.
Take the template above, or spin up a project and let the agent file each request as a card — then link every one to the decisions and specs it touches, and keep the whole chain current for you.
Start free with $5