How AI Changed the Way I Write PRDs (And Made Them Actually Useful)

Oct 22, 2025

I used to spend 8 hours writing PRDs that engineers ignored. Now I write better PRDs in 2 hours using AI. Here's my exact process and the 3 biggest mindset shifts.

How AI Changed the Way I Write PRDs (And Made Them Actually Useful)

I used to spend 8 hours writing PRDs.

Engineers would skim them, ask 20 clarifying questions, then build something different anyway.

Now I write better PRDs in 2 hours using AI. Here's what changed.

The Old Way (That Didn't Work)

My process:

  1. Stare at blank Google Doc for 30 minutes

  2. Write generic sections: "Background," "Goals," "Requirements"

  3. List features without explaining WHY

  4. Add mockups engineers couldn't interpret

  5. Send to team → Get ignored

Time: 8 hours
Result: Confusion, rework, frustration

The New Way (That Actually Works)

Step 1: Brain Dump to AI (15 min)

I tell Claude everything in my head:

I'm building a self-service data export feature. Context: Users currently submit tickets to support. Takes 2-3 days. We get 120 requests/month. Goal: Let users export their own data instantly. Concerns: Security (who can export what?), performance (large datasets), formats (CSV, JSON, Excel?)

Claude organizes my chaos into structured sections.

Step 2: Generate User Stories (20 min)

Instead of writing features, I ask:

"Convert this into user stories with acceptance criteria. Format: As a [user], I want [goal] so that [benefit]."

Claude generates 10-15 stories. I pick the best 5.

What I learned: User stories force me to think about "why," not just "what."

Step 3: Clarify Edge Cases (30 min)

I ask Claude:

"What edge cases am I missing? What could go wrong?"

Claude flags things I never considered:

  • "What if user exports while data is being updated?"

  • "What's the max file size limit?"

  • "How do you handle failed exports?"

This alone saves 2-3 rounds of engineering questions.

Step 4: Write Technical Constraints (15 min)

I paste Claude's output and add:

"Constraints: 2 engineers, 4-week timeline, must work with existing auth system, Snowflake backend."

Claude adjusts requirements to fit reality.

Before AI: I'd write impossible requirements. Engineers would push back.

With AI: Requirements are grounded from day 1.

Step 5: Create Examples, Not Mockups (30 min)

Instead of Figma mockups, I ask Claude:

"Show me 3 examples of what this export feature looks like in real products (Stripe, Retool, etc.)."

I paste screenshots + Claude's analysis into PRD.

Engineers love this. Real examples > abstract wireframes.

Step 6: Engineer Review BEFORE Writing Full PRD (20 min)

I share Claude's outline with 1-2 engineers:

"Does this make sense? What am I missing?"

Get feedback. Refine with Claude. Then write full PRD.

Old way: Write full PRD → Engineers say "this is wrong" → Rewrite

New way: Validate outline → Write PRD once

The 3 Biggest Mindset Shifts

Shift #1: PRDs Are Conversations, Not Specs

Old belief: PRD must have every detail

New belief: PRD starts conversation. Details emerge through discussion.

AI helps me write "conversation starters," not encyclopedias.

Shift #2: Examples > Explanations

Old approach: Explain feature in paragraphs

New approach: Show 3 real-world examples

Claude finds examples. I paste them. Engineers get it instantly.

Shift #3: Constraints First, Requirements Second

Old order:

  1. List all desired features

  2. Engineers say "impossible"

  3. Cut scope

New order:

  1. Give Claude constraints (time, team, tech)

  2. Generate requirements that fit

  3. Engineers say "doable"

My Current PRD Template (AI-Optimized)

Section 1: One-Sentence Goal
Example: "Let users export their data without support tickets."

Section 2: Context (Why Now?)

  • Current pain: 120 support tickets/month

  • Business impact: 40 hours wasted/month

  • Opportunity: Reduce support load 80%

Section 3: User Stories (Top 5)
As a [user], I want [goal] so that [benefit]

Section 4: Real-World Examples
3 screenshots from Stripe, Retool, etc. with analysis

Section 5: Edge Cases & Questions
What could go wrong? What's unclear?

Section 6: Success Metrics
How do we know this worked?

Section 7: Out of Scope
What we're NOT building (prevents scope creep)

Total pages: 2-3 (down from 8-10)

The Results (3 Months of AI-Written PRDs)

Time per PRD: 8 hours → 2 hours (75% faster)

Engineering questions: 20+ per PRD → 5 per PRD (fewer clarifications)

Scope changes mid-build: 60% of projects → 15% of projects (better requirements)

Engineer satisfaction: "PRDs are actually useful now"

Should You Try This?

Use AI for PRDs if:

  • ✅ You spend 4+ hours per PRD

  • ✅ Engineers ask tons of clarifying questions

  • ✅ You struggle organizing your thoughts

  • ✅ Your PRDs feel like busywork

Don't use AI if:

  • ❌ You just want AI to write it for you (you still need to think)

  • ❌ Your team doesn't read PRDs anyway (fix that first)

The Unexpected Benefit

I thought AI would make me write faster.

Real benefit? Made me think clearer.

AI forces me to articulate:

  • What problem am I solving?

  • Why does this matter?

  • What are the constraints?

  • What could go wrong?

That clarity makes me a better PM, whether I use AI or not.