Product Requirements Doc (PRD) (Clear Specs, Aligned Teams)
Define product requirements so engineering, design, and stakeholders build the right thing.
Prompt
Write a Product Requirements Document for {FEATURE/PRODUCT}.
Input:
- Feature/Product: {NAME}
- Problem being solved: {PROBLEM}
- Target users: {USERS}
- Key stakeholders: {STAKEHOLDERS}
Rules:
- Start with problem and user need
- Define measurable success criteria
- Separate must-haves from nice-to-haves
- Include user stories for clarity
- Specify what, not how (preserve design freedom)
Output format:
OVERVIEW
Feature/Product: [Name]
Owner: [PM name]
Status: [Draft/In Review/Approved]
Target release: [Quarter/Date]
PROBLEM STATEMENT
Current situation: [What's happening now]
User impact: [How this affects users]
Business impact: [Why this matters to business]
How we know this is a problem: [Research/data]
GOALS & SUCCESS METRICS
Primary goal: [What we're trying to achieve]
Success metrics:
- [Metric 1]: Baseline [X] → Target [Y] by [when]
- [Metric 2]: Baseline [X] → Target [Y]
Secondary goals:
- [Additional benefit we expect]
USER STORIES
As a [user type]
I want to [action]
So that [benefit]
Acceptance criteria:
- [Specific condition 1]
- [Specific condition 2]
[Additional user stories...]
USE CASES
Use case 1: [Scenario name]
Actor: [Who is doing this]
Preconditions: [What's true before]
Flow:
1. [Step 1]
2. [Step 2]
3. [Step 3]
Postconditions: [What's true after]
Alternative flows: [Edge cases]
FUNCTIONAL REQUIREMENTS
Must have (P0):
1. [Requirement] - Rationale: [Why this is critical]
2. [Requirement]
Should have (P1):
1. [Requirement] - Rationale: [Why this is valuable]
2. [Requirement]
Nice to have (P2):
1. [Requirement] - Rationale: [Why this is optional]
Out of scope (for this release):
- [What we're explicitly not doing]
NON-FUNCTIONAL REQUIREMENTS
Performance:
- [Load time requirement]
- [Scalability requirement]
Security:
- [Data protection requirement]
- [Access control requirement]
Accessibility:
- [WCAG compliance level]
- [Specific accommodations]
DESIGN CONSIDERATIONS
Key principles:
- [Design principle 1 relevant to this feature]
Constraints:
- [Existing pattern to follow]
- [Platform limitation to respect]
User flows to consider:
- [Critical path users must take]
TECHNICAL CONSIDERATIONS
Dependencies:
- [System or API this relies on]
Constraints:
- [Technical limitation]
Data requirements:
- [What data needs to be stored/accessed]
OPEN QUESTIONS
1. [Question that needs resolution]
Owner: [Who will answer]
2. [Continue...]
LAUNCH PLAN
Rollout strategy: [Percentage rollout, beta, etc.]
Go/no-go criteria: [What must be true to launch]
Monitoring: [What we'll watch closely]
APPENDIX
- Links to research/designs
- Related documents
- Previous discussions
Feature: {NAME}
Problem: {PROBLEM}
Users: {USERS}Variations
• Add technical specification section for complex features.
• Include competitive feature comparison.
• Make it experiment-focused (hypothesis testing).
• Add internationalization requirements.
Works well with
• GPT
• Claude
• Gemini