Feature Request Template
A reusable product requirements template with variables for user problem, proposed solution, target users, constraints, acceptance criteria, out-of-scope items, and success metric.
Overview
Poorly scoped feature requests cause more engineering waste than almost anything else in product development. The problem is almost never that people don't care — it's that the request skips from observed symptom straight to proposed solution without establishing the problem, the user, or what done looks like. This template structures the gap between 'someone asked for this' and 'we know what to build, for whom, and how we'll know it's working.'
Workflow
-
Separate the problem from the solution
The most important discipline in filling this template: userProblem should describe what the user experiences, not what they asked for. Proposed solution is where the ask goes.
-
Fill in the template variables
Open in Prompt Template Builder. Variables: userProblem, proposedSolution, targetUsers, priority, constraints, acceptanceCriteria, outOfScope, successMetric.
-
Write acceptance criteria as testable statements
Each criterion should be: 'Given [condition], when [action], then [outcome]'. Vague criteria like 'the feature should be fast' will produce vague output.
-
Review open questions in the output
The AI will identify ambiguities it cannot resolve from the input. These are the questions to answer before handing to engineering — not after.
Why This Works
- Separating userProblem from proposedSolution prevents the spec from being anchored to an assumed solution — the best implementations often come from a better-understood problem
- Requiring explicit out-of-scope boundaries reduces scope creep mid-sprint when edge cases are discovered
- Testable acceptance criteria mean the spec defines when work is complete, not when developers think it's done
- A single success metric forces alignment on what 'working' means before a line of code is written
Best for
- Feature requests that came in as user feedback or support tickets without engineering context
- Cross-functional requests where PM, design, and engineering need a shared starting document
- Scope-sensitive features where 'out of scope' needs to be documented explicitly
- Requests where success is ambiguous and needs a metric before development starts
Not for
- Architectural design — this produces a product spec, not a technical design document
- Bug reports — use the Bug Investigation Template instead
- Fully fleshed-out requests where engineering has already scoped the work
Use cases
- Turning a Slack message feature request into a written spec ready for engineering
- Structuring customer feedback from support tickets into actionable product requirements
- Preparing for a feature kickoff meeting with a pre-filled spec draft
- Documenting what out of scope means for this iteration before the sprint starts