Dev & Code
Free
v1.1
Write a Product Requirements Document (PRD)
Generate a structured PRD from a rough idea — goals, user stories, edge cases, and success metrics in one shot.
planning
PRD
documentation
product
When to use
Use this before starting any new feature or project to align with stakeholders and clarify scope.
Recommended LLMs
Claude Sonnet
GPT-4o
Plugins / Skills
Projects (Claude)
Custom Instructions (ChatGPT)
When to use
Use this prompt when you have a rough idea and need to turn it into a real document before writing a single line of code. Works great for solo devs pitching to clients, teams aligning before sprints, or freelancers scoping a project before quoting.
Tips for best results
- Replace
{describe your feature here}with a specific, concrete description — the more detail you give, the sharper the output - Include any hard constraints upfront: budget, timeline, tech stack, existing systems
- After getting the output, run a second prompt: "What's missing from this PRD?" to catch blind spots
- Works best in a Project/conversation with system context about your company and stack
Expected output
A well-structured document with numbered sections, clear user stories, and a scoped feature list — ready to paste into Notion, Linear, or share with a client.
The Prompt
Copy it, paste it, use it.
You are a senior product manager. Write a detailed Product Requirements Document (PRD) for the following feature or product idea:
[FEATURE/IDEA]: {describe your feature here}
The PRD must include:
1. **Overview** — what it is and why it matters (2-3 sentences)
2. **Goals & Success Metrics** — 3-5 measurable outcomes (e.g., "reduce onboarding time by 40%")
3. **User Stories** — at least 5, in "As a [user], I want [action] so that [benefit]" format
4. **Functional Requirements** — numbered list of what the system must do
5. **Non-Functional Requirements** — performance, security, scalability considerations
6. **Edge Cases & Constraints** — what could break or cause issues
7. **Out of Scope** — what this feature explicitly does NOT cover
8. **Open Questions** — things that need stakeholder input before development
Write it for a solo developer or small team. Keep it actionable, not corporate fluff. No buzzwords. No vague language.