How to Write a PRD With AI: Claude-Powered Spec Guide for PMs

I used to spend 3-4 hours writing a PRD from scratch. Open a blank document. Stare at it. Write the problem statement. Rewrite the problem statement. Draft user stories. Realise I missed an edge case. Go back to the requirements. Rewrite user stories. Add acceptance criteria. Format the whole thing. Send it to engineering. Get told the technical requirements don't match reality. Rewrite again. That process is dead. Here's what replaced it.

A well-written PRD in 2026 serves two audiences: your team and your AI coding tools. Claude, Cursor, Lovable, and Bolt all produce dramatically better output when given structured requirements. Without a PRD, they guess. With one, they follow instructions faithfully. This guide shows you how to write a PRD with Claude in 20 minutes — including the exact prompts, structure, and editing workflow I use for real product work.

In This Post

Why PRDs still matter in the AI era (more than ever)
The old way vs the new way
My PRD structure: the 10-section template
The 20-minute PRD workflow with Claude
The exact prompts I use
What Claude gets right and what you must edit
Making your PRD AI-coding-tool friendly
Common mistakes PMs make with AI-generated PRDs
The bottom line

Why PRDs Still Matter in the AI Era

There's a popular take floating around product Twitter: "PRDs are dead. Just build." It's wrong. PRDs matter more in 2026 than at any point in software history — and the reason is AI itself.

When a PM hands a vague idea to Claude Code, Cursor, or Lovable, the AI guesses. It hallucinates features. It picks arbitrary tech stacks. It builds the wrong thing with supreme confidence. As PRD Creator puts it: if you didn't write it down, the AI will guess — and it will guess confidently. Every decision you leave implicit is a coin flip.

A PRD is now the bridge between "I have an idea" and "the AI builds it right." It serves two audiences simultaneously:

Your team. Engineers, designers, and stakeholders who need to understand the why and the what before committing resources. This hasn't changed.

Your AI tools. Claude Code, Cursor, Lovable, Bolt, and Figma Make all interpret structured requirements far better than conversational descriptions. A modular PRD with clear sections lets AI tools fetch exactly the section they need — acceptance criteria for testing, technical requirements for architecture, user stories for implementation.

PRD Audience	What They Need From Your PRD
Engineers	Clear acceptance criteria, technical constraints, edge cases
Designers	User flows, persona context, interaction expectations
Stakeholders	Problem statement, success metrics, business justification
AI coding tools	Structured sections, explicit decisions, no ambiguity
Future you	Why you made the decisions you made — context that disappears from memory

The Old Way vs the New Way

Here's what changed:

Dimension	Old Way (2023)	New Way (2026)
Starting point	Blank document	Claude generates structured first draft from context
Time to first draft	2-4 hours	5-10 minutes
Time to final version	4-8 hours	20-40 minutes
User stories	Written manually, often inconsistent	AI-generated, then prioritised and edited by PM
Edge cases	Whatever you remember	Claude identifies edge cases systematically — you add domain-specific ones
Technical requirements	PM guesses, engineer corrects	PM provides stack context, Claude generates appropriate requirements
Review process	Send to engineering, wait for feedback	Use Claude as a multi-perspective reviewer before sending to engineering
Format	Prose-heavy Word document	Structured, scannable sections with bullets and tables
Maintenance	Manually updated (or abandoned)	AI helps incorporate changes quickly

The key insight from Carl Vellotti's Claude Code PM course: AI is most valuable when it helps you think better, not when it does all the thinking for you. The best PRDs combine human judgement with AI's ability to process full context, generate options, and provide diverse perspectives.

The 10-Section Template

This is the template I use for every PRD. It's designed to be readable by both humans and AI coding tools. Each section is clearly labelled so tools like Claude Code can fetch individual sections when needed.

Section	What Goes Here	Who Uses It
1. Problem Statement	One paragraph: who has this problem, what it is, why it matters	Everyone — this is the anchor
2. Goals and Success Metrics	3-5 measurable outcomes with specific numbers	PM, stakeholders, post-launch analysis
3. User Personas	2-3 personas with context, pain points, and goals	Design, engineering, AI tools
4. User Stories	"As a [persona], I want [action] so that [outcome]" with acceptance criteria	Engineering, AI coding tools
5. Functional Requirements	What the system must do — features, behaviours, business rules	Engineering, AI coding tools
6. Non-Functional Requirements	Performance, security, scalability, accessibility constraints	Engineering, DevOps
7. Technical Constraints	Stack, integrations, APIs, database decisions, infrastructure	Engineering, AI coding tools
8. Out of Scope	What this PRD explicitly does NOT cover	Everyone — prevents scope creep
9. Risks and Dependencies	What could go wrong, external dependencies, assumptions	PM, engineering leads
10. Milestones	Phased delivery plan with what ships in each phase	PM, engineering, stakeholders

Why milestones matter for AI tools: Breaking the PRD into phased milestones is critical when using it to generate prototypes. Instead of the AI building everything at once, you can tell Lovable or Bolt to build Phase 1 first, review it, then proceed to Phase 2. This phased approach produces dramatically better output than a single "build the whole thing" prompt.

The 20-Minute PRD Workflow

Here's the exact workflow I follow. Total time: 20 minutes for a standard feature PRD.

Step 1: Context Dump (3 minutes)

Before opening Claude, I gather every piece of relevant context into one place: user interview notes, competitive analysis snippets, existing product documentation, stakeholder requirements, and any previous decisions. I paste all of this into Claude as the first message.

The more context you give Claude upfront, the better the first draft. Most PMs under-invest in this step. They give Claude a one-sentence prompt and get a generic PRD. Give Claude 500 words of real context and you get a PRD that sounds like you wrote it.

Step 2: Structured First Draft (5 minutes)

I use this prompt (adapted to the specific feature):

Based on the context above, write a Product Requirements Document for [feature name].

Use this structure:
1. Problem Statement (1 paragraph — who has this problem, what it is, why it matters)
2. Goals and Success Metrics (3-5 measurable outcomes)
3. User Personas (2-3 personas with pain points and goals)
4. User Stories (5-7 stories in "As a [persona], I want [action] so that [outcome]" format, each with 3-5 acceptance criteria)
5. Functional Requirements (bullet list of what the system must do)
6. Non-Functional Requirements (performance, security, scalability)
7. Technical Constraints (we use Supabase for database, React for frontend, Vercel for deployment)
8. Out of Scope (what this PRD does NOT cover)
9. Risks and Dependencies
10. Milestones (3 phases — MVP, Enhancement, Scale)

Be specific. Use real numbers where possible. Don't hedge with "may" or "could" — state requirements clearly.

Claude produces a complete first draft. It's about 70% right.

Step 3: Socratic Questioning (3 minutes)

This is the step most PMs skip — and it's the most valuable. Instead of immediately editing the draft, I ask Claude to challenge it:

Before I finalise this PRD, ask me 5 questions that would make it stronger. Focus on:
- Assumptions I might be making that could be wrong
- Edge cases the user stories don't cover
- Success metrics that might be misleading
- Technical decisions that need justification
- Scope that might be too ambitious for Phase 1

Claude asks pointed questions. I answer them. Then I ask Claude to update the PRD based on my answers. This Socratic loop — inspired by the Claude Code PM course's methodology — catches gaps before engineering finds them.

Step 4: PM Judgement and Editing (7 minutes)

This is the work only a PM can do. I go through the draft section by section:

Section	What I Edit	Why AI Gets It Wrong
Problem statement	Sharpen based on actual user conversations	AI writes generic pain points; I write the specific one I heard yesterday
Success metrics	Replace with metrics we can actually measure	AI suggests ideal metrics; I know what our analytics can track
User stories	Reprioritise based on pain severity	AI ranks by logical completeness; I rank by user urgency
Acceptance criteria	Add domain-specific edge cases	AI covers common cases; I know the weird thing our enterprise client does
Technical constraints	Adjust for real infrastructure limits	AI assumes ideal stack; I know our Supabase plan's connection limits
Out of scope	Add things stakeholders will definitely ask for	AI doesn't know organisational politics
Milestones	Restructure based on engineering capacity	AI scopes ideally; I scope for my actual team

Step 5: Multi-Perspective Review (2 minutes)

Before sending to the team, I ask Claude to review the PRD from three perspectives:

Review this PRD from three perspectives and give me the top concern from each:
1. As a senior engineer — what's technically unclear or risky?
2. As a designer — what's missing about the user experience?
3. As a stakeholder/CEO — what's the business case weakness?

This simulates a review meeting and catches issues before the real review. I address the valid concerns, note the ones to discuss with the team, and the PRD is ready.

Total time: 20 minutes. Compare that to 3-4 hours of starting from a blank document.

The Exact Prompts I Use

Here are four prompts I use in different situations. Copy and adapt them.

Prompt 1: Full PRD from Scratch

You are helping me write a Product Requirements Document. Here's the context:

[Paste: user interview notes, competitive analysis, stakeholder requirements, existing product context]

Write a complete PRD for [feature] using this 10-section structure:
[Paste the template from Section 3 above]

Technical stack: [Supabase / React / Vercel / etc.]
Target users: [specific user description]
Timeline: [what you're working with]

Be specific and decisive. No hedging language. State requirements clearly.

Prompt 2: PRD from Rough Notes

I have rough notes from a product discussion. Turn these into a structured PRD.

My notes:
[Paste raw notes — messy is fine, Claude handles it]

Follow the 10-section PRD structure. Where my notes are vague, make reasonable assumptions and flag them clearly with [ASSUMPTION: ...] so I can review.

Prompt 3: User Story Expansion

Here are 3 user stories. For each one:
1. Write 5 detailed acceptance criteria
2. Identify 3 edge cases
3. Suggest one technical dependency
4. Rate the complexity as Low / Medium / High

User stories:
[Paste your stories]

Prompt 4: PRD Review and Improvement

Review this PRD and give me:
1. Three things that are missing or unclear
2. Two acceptance criteria that are untestable (and suggest testable alternatives)
3. One scope item that should move to Phase 2
4. Any contradictions between sections

[Paste your PRD]

What Claude Gets Right and What You Must Edit

After writing 50+ PRDs with Claude, here's the honest quality assessment:

Section	Claude Quality	What You Must Edit
Problem statement	Good structure, generic language	Replace generic pain points with specific user quotes and real context
Success metrics	Reasonable but aspirational	Replace with metrics your analytics stack can actually track
Personas	Well-structured, often stereotypical	Add real behavioural details from your actual user interviews
User stories	Technically correct, often generic	Reprioritise by pain severity, add domain-specific stories
Acceptance criteria	Covers 70% of cases well	Add the 30% that requires domain knowledge — the weird edge cases
Functional requirements	Comprehensive	Remove over-scoped items, add business rules Claude doesn't know
Non-functional requirements	Standard best practices	Adjust to your actual infrastructure and traffic expectations
Technical constraints	Reasonable defaults	Replace with your real stack, real limits, real integration points
Risks	Identifies common risks	Add organisational and political risks only you know
Milestones	Logical phasing	Restructure based on actual team capacity and dependencies

The pattern: Claude handles structure and completeness. You handle context, prioritisation, and political reality. Neither of you can do the other's part well.

Making Your PRD AI-Coding-Tool Friendly

If your PRD will be used with Claude Code, Cursor, or any AI coding tool, format it for machine readability:

Use clear section headers. AI tools can fetch individual sections when they're clearly labelled with consistent headings.

Write one requirement per bullet. Avoid long paragraphs with multiple requirements embedded in prose. Claude Code processes bullet points more accurately than paragraphs.

Be explicit about technical decisions. Don't write "use a modern database." Write "use Supabase PostgreSQL with Row-Level Security enabled on all user-facing tables." The more explicit you are, the fewer decisions the AI makes on its own.

Include a CLAUDE.md companion. If you're using Claude Code, create a CLAUDE.md file that defines your coding conventions, file structure, and implementation standards. The PRD defines the "what." CLAUDE.md defines the "how."

Phase your milestones clearly. AI coding tools produce better output when asked to build Phase 1 first, review, then Phase 2. Your milestone section should map to these build phases with clear boundaries.

PRD Format	Human Readability	AI Tool Readability
Prose paragraphs	Good	Poor — AI misses or blends requirements
Bullet points per requirement	Good	Excellent — each requirement is discrete
Tables for comparisons	Excellent	Excellent — structured data is easy to parse
User stories with acceptance criteria	Good	Excellent — clear input/output expectations
Vague language ("should be fast")	Understandable in context	Terrible — AI needs specific numbers
Specific language ("API response < 200ms")	Clear	Excellent — AI implements precisely

Common Mistakes PMs Make With AI-Generated PRDs

1. Treating the First Draft as Final

The AI's first draft is 70% right. The temptation is to ship it because it "looks complete." Don't. The 30% you need to edit is the 30% that determines whether engineering builds the right thing or a technically-correct-but-wrong thing.

2. Not Providing Enough Context

"Write a PRD for a task management app" produces garbage. "Write a PRD for a task management feature inside our school administration platform, where teachers need to track lab equipment maintenance tasks that are assigned by the admin and approved by the principal" produces something useful. Context is the variable that determines output quality.

3. Accepting Generic Success Metrics

Claude loves suggesting "increase user engagement by 20%." That's meaningless unless you define what engagement means, how you measure it, and what the baseline is. Replace every AI-suggested metric with one you can actually track in your analytics stack.

4. Skipping the Socratic Step

The 3 minutes you spend asking Claude to challenge the PRD save 3 days of back-and-forth with engineering later. This is the highest-ROI step in the entire workflow.

5. Not Including Out of Scope

Stakeholders and AI tools both suffer from scope creep. If you don't explicitly state what's out of scope, Claude Code will build features you didn't ask for, and stakeholders will assume features are included because they "seem obvious."

The Bottom Line

Writing a PRD with AI isn't about getting Claude to do your job. It's about restructuring the work so the machine handles the structure and you handle the strategy.

The 3-4 hours you used to spend writing from scratch becomes 20 minutes: 3 minutes of context preparation, 5 minutes of generation, 3 minutes of Socratic review, 7 minutes of PM editing, and 2 minutes of multi-perspective review. The output is better — not despite the AI involvement, but because the AI forces you to be explicit about context, requirements, and decisions that you used to leave implicit.

The best PRD isn't the one with the most elegant prose. It's the one that leaves the least room for misinterpretation — by humans or by machines.