User-centered scope
Start from the people affected by the feature and the problem they need solved.
Product requirements document template
Free PRD Template Generator
A PRD template generator turns a product idea into a structured product requirements document with users, goals, requirements, acceptance criteria, risks, metrics, and launch notes.
Define scope
Clarify users, problem, goal, and out-of-scope work.
Align delivery
Write requirements and acceptance criteria teams can test.
Plan launch
Capture metrics, dependencies, risks, and milestones.
PRD inputs
Replace the examples with your feature context.
Copy-ready PRD
Paste into docs, Jira, Linear, Notion, or sprint notes.
# Duplicate request merge workflow PRD ## 1. Overview - Product: FeatureVote - Feature: Duplicate request merge workflow - Owner: Product team ## 2. Target users Product managers, customer success managers, and admins who moderate customer feedback boards. ## 3. Problem statement Customers often submit similar feature requests with different wording, which splits votes and makes demand harder to interpret. ## 4. Goal Let admins merge duplicate requests into a canonical item while preserving votes, comments, subscribers, and audit history. ## 5. User stories - As a product manager, I want to merge duplicate requests so that roadmap demand is easier to measure. - As a customer success manager, I want subscribers moved to the canonical request so that customers still receive updates. - As an admin, I want a merge audit trail so that moderation decisions are transparent. ## 6. Functional requirements 1. Admins can select two or more duplicate requests from the board. 2. The admin chooses one canonical request before confirming the merge. 3. Votes, comments, subscribers, and labels move to the canonical request. 4. Old request URLs redirect to the canonical request after merge. 5. The audit log records who merged the requests and when. ## 7. Acceptance criteria 1. Given an admin selects duplicate requests, when they confirm a canonical request, then all votes and comments are preserved on the canonical request. 2. Given a merged request URL is visited, when the request has a canonical destination, then the page redirects to the canonical request. 3. Given subscribers existed on duplicate requests, when the merge completes, then each subscriber appears only once on the canonical request. ## 8. Out of scope - Customer-facing duplicate suggestions - Automatic semantic duplicate detection - Bulk merge across multiple boards ## 9. Success metrics - Reduce duplicate open requests by 40% in 30 days. - Keep merge-related support tickets below five per month. - Maintain zero vote-loss incidents during pilot. ## 10. Dependencies - Request moderation permissions - Audit log event schema - Subscriber notification dedupe ## 11. Risks and mitigations - Accidental merges may damage customer trust. - Duplicate subscribers may receive repeated notifications if dedupe fails. - Legacy links may break if redirects are not covered. ## 12. Timeline - Design review: June 5 - Engineering build: June 6-12 - Internal QA: June 13 - Pilot release: June 17 ## 13. Launch notes Pilot with internal FeatureVote board admins first. Add a clear undo path or support recovery process before broad rollout.
Buildable requirements
Convert strategy into functional requirements, dependencies, and testable criteria.
Stakeholder alignment
Make tradeoffs visible with metrics, risks, launch notes, and out-of-scope boundaries.
PRD template questions
Quick answers for teams turning product ideas into requirements.
What is a PRD template?
A PRD template is a structured product requirements document format that captures the problem, goals, users, requirements, success metrics, risks, and acceptance criteria for a product or feature.
What should a product requirements document include?
A strong PRD includes product context, target users, problem statement, goals, user stories, functional requirements, acceptance criteria, dependencies, risks, timeline, and launch notes.
Who writes the PRD?
A product manager usually owns the PRD, but the best PRDs are reviewed with design, engineering, customer success, sales, support, and any stakeholder who depends on the product decision.
How detailed should a PRD be?
A PRD should be detailed enough for engineering and design to estimate and build from, but concise enough that stakeholders can review the goals, scope, risks, and success criteria quickly.
Can I use this PRD generator for agile teams?
Yes. The generated PRD includes user stories and acceptance criteria, so agile teams can paste the output into planning docs, tickets, or sprint refinement notes.
Related tools
Use these with your PRD to prioritize and plan delivery.
Collect feedback before the PRD locks.
FeatureVote helps product teams collect feature requests, validate demand, and keep users updated when roadmap items ship.