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