Product Requirements Doc (PRD) (Clear Specs, Aligned Teams)
This prompt creates comprehensive PRDs that clearly articulate the problem, user needs, proposed solution, success metrics, and requirements. It balances enough detail for implementation without over-specifying design. Aligns cross-functional teams before development begins.
GPT / Claude / Gemini4 variables
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}Quick brief
Purpose
Define product requirements so engineering, design, and stakeholders build the right thing.
Expected output
A PRD containing: problem statement with user impact, measurable goals and success metrics, detailed user stories and use cases, prioritized functional requirements, non-functional requirements (performance, security, etc.), design principles and constraints, technical considerations, and launch/rollout plan.
Customize before copying
Replace these placeholders with your own context before you run the prompt.
{NAME}{PROBLEM}{USERS}{STAKEHOLDERS}
Works well with
GPT
Claude
Gemini
Variations
Add technical specification section for complex features.
Include competitive feature comparison.
Make it experiment-focused (hypothesis testing).
Add internationalization requirements.
What this prompt helps you do
This prompt creates comprehensive PRDs that clearly articulate the problem, user needs, proposed solution, success metrics, and requirements. It balances enough detail for implementation without over-specifying design. Aligns cross-functional teams before development begins.
When to use it
Use when building new features, launching products, making significant changes to existing functionality, or any time engineering needs clear requirements. Essential for avoiding rework and ensuring alignment.
How it works
The prompt structures PRDs with: problem statement and user impact, goals and success metrics, user stories and use cases, functional and non-functional requirements, design considerations, technical constraints, and launch criteria.
Best practices
Start with the problem, not the solution. Define success metrics upfront. Include user stories to illustrate use cases. Separate must-haves from nice-to-haves. Involve engineering early for feasibility. Keep it updated as requirements evolve. Link to supporting research.
Common mistakes
Solution-first instead of problem-first. Vague requirements that require guessing. Everything is 'must-have' priority. Not defining success metrics. Over-specifying UI before design involvement. Not validating assumptions with users. Writing it alone without team input.
What you should expect back
A PRD containing: problem statement with user impact, measurable goals and success metrics, detailed user stories and use cases, prioritized functional requirements, non-functional requirements (performance, security, etc.), design principles and constraints, technical considerations, and launch/rollout plan.
Limitations
Can't eliminate all ambiguity or change requests. Requires product judgment to scope appropriately. Works best with user research foundation. May need iteration as design and technical constraints emerge. Can't replace ongoing collaboration.
Model notes
Compatible with all major models. GPT creates clear requirement structures. Claude provides thorough user story development. Gemini sometimes suggests edge cases. Works for any product or feature.
Real-world applications
Product managers use this as core deliverable. Engineering teams use it for estimation and planning. Designers use it to inform explorations. QA teams use it to write test plans. Stakeholders use it to understand scope.
How to tell if it worked
Successful PRDs mean fewer mid-development requirement changes, engineering and design understand what to build, stakeholders are aligned on scope, and shipped product solves the stated problem. If teams are confused or build wrong things, PRD was unclear.
Where to go next
Use User Research Synthesis to inform requirements. Pair with Technical Specification for implementation details. Follow with Project Plan for execution timeline.