QUICK ANSWER
What should a feature request template include?
A feature request template should capture the affected user and context, observed problem, current workaround, desired outcome, source-linked evidence, reach and frequency observations, success signals, constraints, related records, ownership, and a dated human triage decision. It should keep prioritization, implementation requirements, post-baseline change control, roadmap commitments, and delivery timelines in their separate accountable records.
A feature request should preserve one reported problem before anyone commits it to a roadmap. It should identify the affected users and context, observed evidence, current workaround, desired outcome, measurable success signal, reach and frequency evidence, constraints, related records, accountable owners, and an explicit human triage decision.
The downloadable pack includes an editable Markdown template, a completed fictional JSON record, a closed JSON Schema, an exact triage CSV, and a dependency-free validator with mutation tests. It is an intake record, not a prioritized product backlog, implementation-ready user story, product requirements document, post-baseline change request, approval, or delivery promise.
Turn a solution request into a reviewable problem record
The useful unit is not a vote for a named feature. It is a traceable claim about a user problem, the evidence behind it, the outcome worth testing, and the next human decision.
Reframe the requested solution as a user problem
Record who is affected, what they are trying to achieve, where the current journey fails, the workaround they use, and what is explicitly outside the problem. Keep the requested capability as a hypothesis so discovery can still find a simpler content, process, service, or product response.
Sources: [govuk-discovery]
Attach observations instead of unsupported scores
Link interviews, support conversations, analytics, research notes, or other reviewable evidence with dates, owners, and limitations. Record reach and frequency as bounded observations with a measurement window and source IDs. Do not turn a loud request, an anonymous vote count, or an invented score into proof of value.
Sources: [govuk-discovery], [github-issue-forms]
Expose success, inclusion, and risk questions early
Name an observable outcome and measurement plan, then record unresolved accessibility, privacy, security, policy, operational, and technical questions. Accessibility and secure-development work begin before implementation, but an intake form cannot establish conformance, safety, or feasibility.
Sources: [w3c-accessibility-planning], [nist-ssdf]
Record triage without promising a roadmap slot
A named human should mark the exact request revision as needs research, candidate, duplicate, or declined; cite evidence and rationale; and name the next research question. If accepted for further discovery, create downstream backlog, user-story, or PRD records separately when their owners are ready.
Sources: [govuk-discovery], [github-issue-forms]
What this feature request pack owns
Use the pack for one pre-commitment request and one human triage decision. Keep portfolio priority, implementation decomposition, product requirements, and post-baseline change authorization with their separate owners.
Included
- Stable request ID and revision, intake status, title, submission and triage dates, requester, affected segment, problem statement, current workaround, desired outcome, proposed capability hypothesis, and non-goals
- Source-linked observations with evidence type, reference, date, owner, and limitation; bounded frequency and reach observations; one success signal with baseline, target, direction, measurement plan, and owner
- Accessibility, privacy, security, policy, operational, and technical questions plus related request, backlog, user story, PRD, and change-request references without merging those records
- Named human triage decision, rationale, evidence links, next research question, and explicit false delivery, roadmap, timeline, automatic-priority, conformance, and security-approval flags
- Editable Markdown, fictional JSON, closed schema, exact CSV, dependency-free validator, mutation tests, README, and reproducible ZIP
Not included
- The ordered product backlog that compares candidate work across strategy, value, effort, risk, dependencies, and capacity
- The implementation-level user story and acceptance examples for work a team has selected and decomposed
- The product requirements document that owns product behavior, requirements, scope, dependencies, rollout, and release acceptance
- The version-bound change request that reviews a proposed change after a project baseline exists
- Roadmap commitment, delivery date, funding approval, legal decision, accessibility conformance, privacy approval, security assessment, or feasibility proof
- Credentials, private personal data, protected support content, security findings, customer contracts, or other sensitive evidence copied into a public request
DOWNLOADABLE RESOURCE
Download the feature request template pack
The ZIP contains an editable intake template, a completed fictional needs-research example, a closed schema, an exact triage CSV, and the dependency-free validator used to expose missing evidence, broken references, unsafe values, inconsistent decisions, and false commitments.
Evidence-backed feature request template pack
One pre-commitment feature-request record linking a user problem, evidence, outcome, observations, constraints, related records, owners, and explicit human triage.
Format: Markdown, JSON, JSON Schema, CSV, and dependency-free Node.js validator/tests in one ZIP
Locally reproduced August 1, 2026. SHA-256: 4ca8e4b95d0c8e0cbb59a155b894d595e85c19f90bdb9ecff05662e9027f88c7
Included
- Editable ten-section Markdown template with problem, evidence, outcome, observation, constraint, relationship, triage, and boundary prompts
- Completed fictional needs-research JSON plus an exact one-row triage CSV and closed Draft 2020-12 schema
- Dependency-free validator and mutation tests for shape, revisions, dates, roles, evidence chronology, reference integrity, observation windows, success signals, relationships, triage state, unsafe values, and unsupported commitments
Verification boundary
The allowlisted archive was reproduced twice, extracted, byte-compared, and tested locally. This verifies deterministic files and internal contracts, not evidence truth, user value, priority, feasibility, accessibility, privacy, security, authorization, or delivery.
Three feature-request shapes for different evidence states
The template stays the same while evidence and triage change. Preserve uncertainty instead of forcing every request into a candidate backlog item.
Needs-research request
Use when: A requester describes a credible problem and workaround, but the affected segment, frequency, reach, or desired outcome still needs validation.
Keep the requested capability as a hypothesis, link the observations already available, mark unknowns explicitly, and name the next research question and owner before any prioritization discussion.
Structure
- Problem, user context, workaround, desired outcome, and current evidence limitations
- Needs-research human decision with source-linked rationale and one bounded next question
- Null backlog, user-story, PRD, change-request, roadmap, and timeline fields
Watch for: A plausible problem statement is not proof of prevalence, value, feasibility, or the right solution. Do not use a synthetic score to hide missing evidence.
Sources: [govuk-discovery], [github-issue-forms]
Candidate for portfolio review
Use when: Evidence supports a bounded problem, observable outcome, and affected segment well enough to compare the opportunity with other candidates.
Record the evidence window, success signal, constraints, dependencies, and triage rationale, then create a separate backlog item owned by the portfolio process. Candidate does not mean scheduled.
Structure
- Multiple evidence items with owners, limitations, dates, and resolved references
- Observable success signal plus accessibility, privacy, security, policy, operational, and technical questions
- Candidate triage and optional downstream backlog reference without a delivery commitment
Watch for: Evidence for one opportunity does not establish relative priority. Backlog owners still need strategy, value, effort, risk, dependency, and capacity comparison.
Sources: [govuk-discovery], [w3c-accessibility-planning], [nist-ssdf]
Duplicate with new evidence
Use when: The same underlying problem already has a canonical request, but the new submission adds a user segment, context, workaround, or observation.
Preserve the incoming request ID, point it to the canonical request, and transfer only reviewable evidence with provenance and consent. Do not silently discard a new context because the proposed solution sounds similar.
Structure
- Incoming request identity and exact canonical duplicate reference
- New evidence, segment, context, and limitations preserved under the submitting record
- Duplicate human decision with no automatic merge of private or incompatible evidence
Watch for: Matching feature names do not prove matching user problems. Review the job, context, constraints, and desired outcome before marking a duplicate.
Sources: [govuk-discovery], [github-issue-forms]
Choose the next state without implying delivery
The triage decision should expose what is known, what is missing, and who owns the next step. Silence, votes, and validation passes are not approval.
The submission names a feature but not the affected user, problem, context, workaround, or desired outcome.
Choose: Mark it needs research and ask one bounded question that can distinguish the problem from the requested solution.
Tradeoff: Triage takes longer, but the team avoids treating a solution-shaped sentence as validated demand.
The request has observations but frequency, reach, or success claims cannot be traced to dated evidence.
Choose: Preserve the raw observations, remove unsupported scores, and keep the request out of portfolio comparison until the measurement owner closes the gap.
Tradeoff: The record looks less decisive, but reviewers can see uncertainty instead of relying on false precision.
A canonical request owns the same user problem, context, and desired outcome.
Choose: Mark the new request duplicate, link the canonical ID, and preserve any new evidence or segment with provenance and limitations.
Tradeoff: The intake remains auditable without splitting evidence across competing feature-name records.
Evidence supports further comparison, but requirements, acceptance examples, implementation, or post-baseline impact review do not exist.
Choose: Mark the request candidate and hand it to the separate backlog owner. Create user stories, a PRD, or a change request only when those downstream processes actually begin.
Tradeoff: The request can enter portfolio review without pretending it is scheduled or implementation-ready.
FROM EVIDENCE TO A TESTABLE PRODUCT SLICE
Explore the problem before locking the feature
Use the affected user, outcome, constraints, and open questions as the starting brief for a bounded prototype or internal workflow experiment.
Explore internal tool buildingKeep portfolio priority, requirements, security, privacy, accessibility, and delivery decisions with their accountable owners.
Use the user story template after decomposition beginsA user story owns a selected implementation slice and acceptance examples. This feature request owns the earlier evidence and triage record.
Limits to review before using the template
A structured intake can expose missing evidence, broken references, unclear ownership, and false commitments. It cannot determine whether a request is valuable, feasible, safe, lawful, accessible, or worth prioritizing.
- The pack is an editorial intake artifact, not a product backlog, roadmap, user story, PRD, change request, business case, contract, legal decision, security assessment, privacy assessment, or accessibility evaluation.
- A validator pass checks closed shape, IDs, dates, role cardinality, evidence and relationship references, observation windows, decision consistency, CSV parity, and false boundary flags. It does not prove any supplied fact or conclusion.
- The fictional organization, people, request, user segment, evidence, observations, constraints, success signal, relationships, and needs-research decision are examples, not benchmarks or recommended thresholds.
- GOV.UK, GitHub, W3C, and NIST provide general official guidance. None reviewed, approved, certified, or endorsed this Playcode artifact.
- Keep credentials, live personal data, private customer messages, account identifiers, protected analytics, contracts, security findings, legal advice, and regulated records outside a public feature-request file.
- Review downstream work in its actual context. A template, schema, CSV, score, automated check, or triage label cannot establish priority, requirements, conformance, security, privacy, feasibility, funding, scheduling, or delivery.
Primary guidance used for the intake boundary
These current official sources support problem-first discovery, structured input, accessibility planning, and secure-development practices. The field design, example, and validation rules are Playcode editorial work.
[govuk-discovery] GOV.UK Service Manual:How the discovery phase works
Checked August 1, 2026. Supports: Understanding the problem, users, context, constraints, alternatives, value, success measures, and whether further exploration is justified before committing to build.
[github-issue-forms] GitHub Docs:Syntax for GitHub's form schema
Checked August 1, 2026. Supports: Structured issue-intake forms with field types, descriptions, distinct choices, and required-input validation.
[w3c-accessibility-planning] W3C Web Accessibility Initiative:Planning and Managing Web Accessibility
Checked August 1, 2026. Supports: Integrating accessibility goals, responsibilities, resources, early evaluation, monitoring, and continued review throughout production.
[nist-ssdf] National Institute of Standards and Technology:Secure Software Development Framework, SP 800-218
Checked August 1, 2026. Supports: Adding secure-software practices across the development lifecycle, including preparation, protection, verification, and vulnerability response.
Feature request template FAQ
What is the difference between a feature request and a product backlog item?
A feature request is one pre-commitment intake and triage record for a reported problem and its evidence. A product backlog is the separate prioritized collection that compares selected candidates across strategy, value, effort, risk, dependencies, and capacity. A candidate request may link to a backlog item, but it is not the backlog item itself.
Is a feature request the same as a user story?
No. A feature request records an observed problem, evidence, desired outcome, constraints, and triage before implementation commitment. A user story decomposes selected work into an actor, context, outcome, and acceptance examples. Create that downstream story only when a team is ready to define and test an implementation slice.
When does a feature request need a PRD?
Create a separate product requirements document when the opportunity advances far enough to define product behavior, requirements, scope, dependencies, rollout, and release acceptance. Do not inflate every intake into a PRD, and do not treat the feature request as if it already owns implementation requirements.
When should I use a change request instead?
Use a change request when an approved project or product baseline already exists and someone proposes to alter it. That record owns version-bound impact analysis and authorization. A feature request remains the earlier intake record and must not silently amend an approved requirement, schedule, commercial agreement, or release plan.
Should feature requests be scored automatically?
No score should decide automatically. Preserve dated observations and their limitations, then let accountable people compare candidates in the separate portfolio process. A score can summarize declared inputs if its method and uncertainty are visible, but it cannot replace strategy, user research, feasibility, risk, accessibility, privacy, security, dependency, or capacity judgment.
Does accepting a feature request promise delivery?
No. In this pack, candidate means only that evidence supports further portfolio review. It does not mean prioritized, funded, scheduled, specified, approved for implementation, or promised. Delivery, roadmap, and timeline commitment flags are locked to false, and any later commitment belongs to its accountable planning process.
TURN A REVIEWED OPPORTUNITY INTO A BOUNDED EXPERIMENT
Build from the user problem, not the loudest feature name
Describe the affected user, desired outcome, record boundaries, roles, permissions, states, open risks, and evidence you need to learn next.
Build an internal tool with PlaycodeThis informational article does not grant AI signup credits. The linked product page follows its own current eligibility rules.