What you'll get: 8 copy-paste prompts that build a PRD section by section, a complete PRD template you can take right now, and the /prd-generator skill that automates all of it by reading your product context.
The blank PRD is the worst part of speccing a feature. You know the problem, you know roughly what you want to build, and you still sit there reformatting the same six headings you've reformatted a hundred times before. So PMs reach for AI. They open Claude or ChatGPT, describe the feature, and ask for a PRD.
What comes back gets you about 60% of the way there. The structure is fine. The user stories are plausible. But the missing 40% is the part only you have: your product context. Generic AI doesn't know your personas, your competitive landscape, or what your engineers actually need to estimate. So you spend the time you "saved" injecting that context by hand.
This article fixes the 60% with eight prompts you can paste today, then hands you a template to standardize the output. But the real ending is the third step: a skill that reads your context so you stop pasting it every time. Prompts get you started. The template makes you consistent. The skill makes it disappear into the background.
Blank Doc vs. One-Shot Prompt vs. /prd-generator Skill
There are three ways to write a PRD with AI in the loop. They are not equivalent.
| Blank doc + AI chat | One-shot prompt | /prd-generator skill | |
|---|---|---|---|
| Setup time | 10-15 min re-explaining your product | 2-3 min pasting context into the prompt | 0 min — context is already loaded |
| Context awareness | Whatever you remember to paste | Whatever you paste this time | Reads product.md, personas.md, competitors.md automatically |
| Consistency | Different every time | Depends on the prompt you grabbed | Same framework and structure every run |
| Output | Plausible but generic draft | Good draft, needs context cleanup | Draft that references your real product |
The prompts below live in the middle column. They're the fastest way to get a meaningfully better PRD today. But notice what stays constant across the first two columns: you're still the one carrying the context every single time.
A prompt is a one-shot instruction you re-explain every time. A skill is that instruction plus your product context, applied automatically. Start with the prompts. Graduate to the skill.
The 8 Prompts
Each prompt builds one part of the PRD. Run them in order for a full draft, or grab the one you're missing. Every prompt bakes in a "be specific" instruction — because the difference between a useful PRD and a useless one is whether the AI gave you your reality or a generic one.
Replace the bracketed placeholders before you run each prompt. The more specific your inputs, the less editing you'll do after.
1. Problem Statement
Write the problem statement for a PRD on [feature name].
Who has the problem: [persona / role]
What they're trying to do: [the job they're stuck on]
Evidence it's real: [interview quotes, support tickets, usage data, win/loss notes]
What it costs them today: [time, money, errors, abandoned workflows]
Write 3-4 paragraphs covering: the problem, who has it, evidence it's
real, and why solving it matters now.
Be specific. Don't give me "users want a better experience." Give me
"4 of 6 interviewed admins rebuilt the same report weekly because there's
no saved-view feature." If my evidence is thin, say so — don't paper over it.
2. User Stories + Acceptance Criteria
Based on this feature, write the user stories with acceptance criteria.
Feature: [one-line description]
Primary persona: [role and what they care about]
Core capability: [what the user can do that they couldn't before]
For each story:
- Format: "As a [persona], I want to [action], so that [outcome]"
- 3-5 acceptance criteria in Given/When/Then format
- Flag any story that depends on another story or system
Be specific to this feature. Don't give me "As a user, I want to log in."
Give me stories tied to the actual capability. Generic CRUD stories that
could apply to any product are useless to my engineers.
3. Scope and Out-of-Scope
Define the scope for this PRD.
Feature: [description]
Target ship date / constraint: [timeline or resource limit]
What I think v1 should do: [your rough cut]
Produce two lists:
1. In scope for v1 — the minimum that delivers the core value
2. Explicitly out of scope — what we're deliberately deferring, and why
Be specific about the boundary. For each out-of-scope item, give the
one-line reason it's deferred (not "future enhancement"). I want a
boundary an engineer can hold me to, not a wish list.
4. Success Metrics
Define success metrics for this feature.
What the feature does: [description]
Business goal it supports: [the metric or outcome it should move]
Our current baseline (if known): [number or "unknown"]
Give me:
- 1 primary metric that tells us this worked
- 2-3 leading indicators we'll see before the primary metric moves
- 2-3 guardrail metrics that shouldn't get worse
- For each: definition, target, and where the data comes from
Be specific and measurable. Reject "increase engagement." I want
"X% of admins create at least one saved view within 14 days of release."
Flag any metric that needs new instrumentation we don't have yet.
5. Edge Cases
I'm speccing [feature]. Here's the happy path:
[describe the intended flow, step by step]
Generate 12-18 edge cases I should handle, grouped by:
- Input edge cases (empty states, max limits, special characters)
- State edge cases (concurrent edits, offline, mid-flow interruption)
- Permission edge cases (wrong role, expired access, shared accounts)
- Integration edge cases (third-party failure, API timeout, sync conflict)
For each, note the expected behavior in one line. Be specific to this
feature's actual flow — not a generic checklist. If an edge case is
genuinely unlikely for my use case, skip it rather than padding the list.
6. Dependencies and Risks
Identify the dependencies and risks for this feature.
Feature: [description]
Systems it touches: [data models, services, integrations you know about]
Teams involved: [other teams whose work this depends on]
Produce:
1. Dependencies — what must exist or ship first, and who owns it
2. Risks across four dimensions: technical (can we build it?),
user (will they adopt it?), business (will it move the metric?),
integration (will it break something existing?)
3. For each risk: likelihood, impact, and how we'd detect it early
Be specific. "There may be technical risk" is worthless. Name the actual
system that could break and the signal we'd watch for. Flag the single
risk most likely to derail the timeline.
7. Executive Summary
Write the executive summary for this PRD. The full PRD is below:
[paste the sections you've built so far]
Audience: [who approves this — VP Product, eng lead, exec team]
Write 150-200 words that:
- Open with the "so what" — why this matters to this audience now
- State the problem, the proposed solution, and the expected outcome
- Name the one metric that defines success
- End with the decision or resource you're asking for
Be specific and decision-oriented. No throat-clearing, no "this document
outlines." A reader should know whether to approve this after one read.
Use the language this audience cares about — revenue, capacity, or risk.
8. Full First-Draft PRD
Write a complete first-draft PRD for [feature name]. Assemble it from
the inputs below into one structured document.
Problem: [what user problem this solves]
Persona: [who it's for]
Proposed solution: [what we're building]
Success looks like: [measurable outcome]
Constraints: [timeline, technical, or resource limits]
Related features: [what already exists that this connects to]
Use these sections in order: Executive Summary, Problem Statement,
Goals & Success Metrics, Proposed Solution, User Stories & Acceptance
Criteria, Scope (In / Out), Edge Cases, Dependencies, Risks &
Assumptions, Open Questions.
Be specific throughout. Reference the actual personas and constraints I
gave you — don't invent generic ones. Where you're making an assumption I
should validate, mark it "Assumption:" so I can spot it. This is for the
PM-to-engineering handoff, so favor precise requirements over narrative.
The Free PRD Template
If you'd rather start from structure than from a prompt, copy this. Paste it into your doc, fill the brackets, and you have a PRD skeleton that maps one-to-one to the eight prompts above.
# PRD: [Feature Name]
**Author:** [name] · **Date:** [date] · **Status:** Draft
**Reviewers:** [eng lead, design, stakeholders]
## Executive Summary
[150-200 words: why this matters now, the problem, the solution,
the one success metric, and the ask.]
## Problem Statement
- **Who has the problem:** [persona]
- **The problem:** [what they're stuck on]
- **Evidence:** [quotes, tickets, data — cite the source]
- **Cost of inaction:** [what it costs them / us today]
- **Why now:** [the timing trigger]
## Goals & Success Metrics
- **Primary metric:** [definition, target, data source]
- **Leading indicators:** [2-3 early signals]
- **Guardrail metrics:** [2-3 things that shouldn't get worse]
## Proposed Solution
[What we're building, at a level engineering can estimate.
Link to designs or prototype if available.]
## User Stories & Acceptance Criteria
- **Story 1:** As a [persona], I want to [action], so that [outcome].
- Given [context], when [action], then [result].
- [acceptance criteria 2-5]
- **Story 2:** ...
## Scope
**In scope (v1):**
- [minimum that delivers the core value]
**Out of scope (deferred):**
- [item] — [one-line reason]
## Edge Cases
- **Input:** [empty states, limits, special characters → expected behavior]
- **State:** [concurrent, offline, interrupted → expected behavior]
- **Permission:** [wrong role, expired access → expected behavior]
- **Integration:** [third-party failure, timeout → expected behavior]
## Dependencies
- [what must ship first] — owned by [team]
## Risks & Assumptions
- **Risk:** [description] — likelihood / impact / early-warning signal
- **Assumption:** [what we're betting on, to be validated]
## Open Questions
- [unresolved decisions, with who needs to weigh in]
Related — Claude Prompts for Product Managers: 30 That Actually Work covers 30 prompts across discovery, strategy, specs, analysis, and communication — the full prompt library these eight are drawn from.
Related — Writing PRDs with AI: Frameworks That Actually Work goes deeper on the frameworks underneath a good PRD — Cagan's problem-first approach, risk-weighted specs, and user-story-driven specs — and how /prd-generator encodes them.
From Prompts to a PRD Skill
Here's the ceiling on everything above. A prompt is a one-shot instruction. Even the eight-prompt sequence asks you to paste the same product context, the same personas, the same constraints — over and over, every feature, every sprint. You're doing the AI's homework for it.
The fix is a skill. The /prd-generator skill is the eighth prompt, except it doesn't ask you for context. It reads your context files directly — product.md for what's already built, personas.md for who your users are and how they talk, competitors.md for where you differentiate. Then it applies the Cagan problem-first framework and produces a PRD that references your actual product instead of a hypothetical one. The personas are your personas. The metrics connect to your real KPIs. You go from blank doc to reviewable draft without explaining your company first.
That's the shift the prompts are previewing: from re-explaining your product every time, to a system that already knows it.
Download the PRD Generator free →
PRD generation is one node in a larger system. To see how /prd-generator chains with /feature-decomposition-tool, /user-story-writer, and /technical-spec-writer into a full feature-to-handoff workflow, read AI PM Workflows: Discovery, PRDs, and Roadmaps in Claude. And if you're setting up Claude Code for PM work for the first time, How to Use Claude as a Product Manager is the place to start — it walks through context files, skills, and the workflows they unlock.
Once you've run a few skills against your own context, the full PM Operating System — every skill plus the context files that make them sharp — runs on a 14-day free trial, $39/mo, cancel anytime.
FAQ
Can AI write a full PRD?
It can write a strong first draft. With the eighth prompt above, or the /prd-generator skill, you'll get a complete structured PRD — problem statement, user stories, metrics, edge cases, dependencies. What AI can't do is make the scope trade-offs, sequencing calls, and "is this the right thing to build" judgments. Treat the output as a draft to pressure-test, not a final artifact. The skill removes the blank page and the setup time; you add the judgment.
Best AI for PRDs — Claude or ChatGPT?
Both write a PRD from a good prompt. The eight prompts here work in either. The real difference isn't the model — it's whether the AI has your product context. ChatGPT in a chat window starts cold every session. Claude Code with context files and the /prd-generator skill already knows your product, personas, and competitors, so the output references your reality instead of a generic one. Context awareness beats model choice for PRD quality.
Will it know my product?
Not from a prompt alone — you have to paste the context in every time. That's the gap the /prd-generator skill closes. It reads your context files automatically, so every PRD references your actual personas, your competitive landscape, and your real metrics without you re-explaining them. That's the whole reason a skill beats a prompt: the context is loaded once and reused forever.
Is the PRD generator free?
Yes. The /prd-generator skill is a free download — grab it, drop it into Claude Code, and run it on a feature you're speccing right now. The free skills are the front door. The full PM Operating System, with your context files and the rest of the skill library wired together, is the paid product.
About the Author
Ron Yang is the founder of mySecond — he builds and manages PM Operating Systems for product teams. Prior to mySecond, he led product at Aha! and is a product advisor to 25+ companies.