Resource
Agent Task Template
A reusable AI agent task template with variables for objective, context, available tools, constraints, success criteria, failure handling, and output format.
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.'
How to use this resource
-
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
FAQ
How do I keep userProblem and proposedSolution from saying the same thing?
Put the observed symptom in userProblem ('users abandon checkout when the coupon field errors silently') and the requested fix in proposedSolution ('add inline validation'). When both variables echo the same fix, you've anchored to a solution before understanding the problem. Section 1 of the spec collapses userProblem into a one-sentence problem statement when you run the filled template, so keep userProblem strictly symptom-first.
Will this feature request template cover performance and security requirements?
Section 4 (non-functional requirements) is where performance, security, and accessibility land, but only when relevant and only from what your constraints and successMetric variables imply. The template organizes a product spec, not a technical design, so it won't specify architecture or infrastructure. It frames the what a feature needs; the how stays a decision for your engineers.
Where do the open questions in section 7 go once the spec is generated?
Section 7 collects ambiguities the assistant couldn't resolve from your variables, and they're meant to be closed before engineering starts, not after. NewPrompt fills and structures the template; running the filled prompt in Claude, ChatGPT, or Gemini surfaces those gaps, but you decide the answers and whether the spec is ready to hand to a kickoff or sprint.
More resources from Prompt Template Builder
Resource
Blog Post Template
A reusable long-form content template with variables for topic, audience, tone, target keyword, content angle, outline, and call to action.
Resource
Pull Request Review Template
A reusable PR review prompt template with variables for repository, branch, change summary, changed files, review criteria, and risk areas.
Resources that pair well
Resource
Bug Triage Assistant
Convert scattered bug notes, Slack messages, or user complaints into structured engineering tasks with reproduction steps, severity, and root cause hypothesis.
Resource
API Request Variable Builder
Turns a reusable API request prompt into a clean variable set covering endpoint, method, auth, payload, response format, and error handling.
Related tools
Tool
Prompt Template Builder
Build reusable prompt templates with {{variable}} placeholders, live preview, and export.
Guides for this resource
Guide
How to Find Gaps in an AI-Generated Plan Before You Use It
The plan AI hands you reads clean and complete — until you try to execute it and hit the missing rollback, the unnamed owner, the decision nobody made. Here's how to run a separate gap-review pass that surfaces what's missing, risky, or unclear before you act on it.
Guide
How to Turn Requirements Into an AI Execution Plan
Paste a requirement and ask AI for a plan, and you usually get the requirement summarized back or a generic to-do list that can't actually be executed. Here's how to normalize the requirement first, then have AI build a plan with the ordering, dependencies, and checkpoints a summary leaves out.
Guide
How to Write a Product Requirements Document (PRD) With AI
A PRD earns its keep by separating the feature somebody asked for from the problem they actually have — then fixing scope, numbering the requirements, and handing the open questions to the people who own them.
Guide
How to Turn a Feature Into User Stories With AI
A feature arrives as one line — "let users change the pickup location" — and AI splits it the two wrong ways: it restates the spec, or it hands back a task list. Here is how to turn a feature into user stories with AI: sliced by the user's path, each one shippable and checkable on its own.