Writing PRDs and Feature Specs

The PRD Nobody Reads

In the previous lesson, we explored user research synthesis and insights. Now let’s build on that foundation. You’ve written PRDs before. Long, detailed documents that took hours to create. Then what happened? Engineering skimmed the first page, asked you a bunch of questions the PRD answered (on page 7), and built something slightly different from what you specified.

The problem isn’t your writing. It’s the format. Most PRDs are structured for the PM’s thinking process, not for the reader’s consumption process.

A great PRD does three things:

Tells the team why this matters (context and motivation)
Defines what success looks like (clear criteria)
Gives enough detail for implementation decisions without over-prescribing how

AI helps you hit all three consistently and fast.

The PRD Structure That Works

After years of iteration across product teams, here’s the structure that engineers, designers, and leadership actually value:

1. Summary (3 sentences -- what and why)
2. Problem Statement (who's affected, how, evidence)
3. Goals and Success Metrics (measurable outcomes)
4. User Stories (as a [user], I want [action] so that [benefit])
5. Requirements (must-have vs. nice-to-have)
6. Acceptance Criteria (testable conditions for "done")
7. Design Considerations (UX requirements, not solutions)
8. Technical Considerations (constraints, dependencies)
9. Out of Scope (what we're explicitly NOT doing)
10. Open Questions (what still needs to be decided)
11. Timeline and Milestones

The key insight: Sections 1-3 are for stakeholders and leadership. Sections 4-8 are for engineering and design. Section 9 prevents scope creep. Section 10 shows intellectual honesty.

Generating Your First Draft

Here’s the prompt that produces a strong first draft:

Generate a PRD for the following feature. I'll refine it after you draft it.

CONTEXT:
Product: [product name and brief description]
Target user: [who this feature is for]
Problem: [the specific problem this solves]
Evidence: [how you know this is a problem -- research, data, feedback]

STRATEGIC FIT:
Why now: [why we're building this now vs. later]
How it fits our roadmap: [connection to larger product strategy]
Key constraint: [timeline, resources, technical limitation]

DESIRED OUTCOME:
Success metric: [how we'll measure if this worked]
Target: [specific number/percentage we're aiming for]

Generate a complete PRD with these sections:
1. Summary (3 sentences max)
2. Problem Statement (with evidence)
3. Goals and Success Metrics
4. User Stories (5-8 covering primary and edge cases)
5. Requirements (separated into must-have and nice-to-have)
6. Acceptance Criteria (specific, testable)
7. Design Considerations
8. Technical Considerations
9. Out of Scope
10. Open Questions
11. Timeline suggestion

Be specific and concrete. Avoid vague requirements like "should be fast"
-- use measurable criteria like "page load under 2 seconds."

Writing Killer User Stories

User stories are often the weakest part of PRDs. They’re either too vague (“As a user, I want a better experience”) or too prescriptive (“As a user, I want a blue button in the top right corner”).

Good user stories capture the user’s goal, not the implementation:

Formula: As a [specific user type], I want to [specific action] so that [specific benefit].

Bad: “As a user, I want notifications.” Good: “As a project lead, I want to receive a notification when a team member completes a deliverable, so that I can review it promptly and keep the project on schedule.”

Use AI to generate comprehensive user stories:

Generate user stories for this feature: [brief description]

Users involved: [list user types]
Core functionality: [what the feature does]

For each user story:
1. Use the standard format: As a [user], I want [action], so that [benefit]
2. Cover the happy path (normal use)
3. Cover edge cases (errors, unusual inputs, permissions)
4. Cover different user types if they interact with this feature differently
5. Include negative user stories (what users should NOT be able to do)

Generate 8-12 stories. Prioritize them as P0 (must-have for launch),
P1 (should-have), P2 (nice-to-have).

Acceptance Criteria That Prevent Arguments

Vague acceptance criteria cause rework. “The search should be fast” means 100ms to engineering and 500ms to PM. “The search should return results in under 200ms for 95% of queries” is unambiguous.

Write acceptance criteria for these user stories:
[paste your user stories]

For each criterion:
1. Use the Given-When-Then format:
   Given [precondition]
   When [action]
   Then [expected result]
2. Include specific numbers where applicable (load time, limits, etc.)
3. Cover success states AND failure states
4. Include edge cases (empty states, maximum limits, permissions)
5. Make each criterion independently testable

A QA engineer should be able to write a test directly from each criterion.

Example of good acceptance criteria:

Given a user with edit permissions
When they modify a document and click "Save"
Then the changes are persisted within 500ms
And a confirmation toast appears for 3 seconds
And the last-modified timestamp updates to the current time

Given a user without edit permissions
When they attempt to modify a document
Then the edit controls are disabled
And a tooltip displays "You don't have permission to edit this document"

The “Out of Scope” Section: Your Best Friend

The most underrated PRD section. Without it, scope creeps. With it, you have a reference point for every “but what about…” conversation.

Based on this PRD: [paste your PRD summary and requirements]

Generate an "Out of Scope" section that:
1. Lists features that are related but NOT included in this release
2. Explains briefly why each is out of scope (future phase, different
   initiative, not enough data yet)
3. Notes which out-of-scope items might be addressed in future iterations
4. Identifies potential scope creep risks -- features stakeholders might
   try to add

Be specific. "Improved performance" is a vague scope risk. "Adding real-time
collaboration, which requires WebSocket infrastructure we haven't built yet"
is specific and defensible.

Quick Check: PRD Quality Assessment

After drafting your PRD, run this quality check:

Review this PRD for completeness and quality:
[paste your PRD]

Check for:
1. CLARITY: Can someone who wasn't in our planning meetings understand
   what we're building and why?
2. SPECIFICITY: Are requirements concrete enough to implement without
   follow-up questions?
3. TESTABILITY: Can every acceptance criterion be verified with a
   yes/no test?
4. COMPLETENESS: Are error states, edge cases, and permissions covered?
5. SCOPE: Is it clear what's in scope and what's not?
6. METRICS: Are success metrics specific and measurable?
7. ASSUMPTIONS: Are hidden assumptions called out?

For each issue found, suggest the specific fix.

Adapting PRDs for Different Audiences

Different stakeholders need different views of the same feature:

I have this PRD: [paste or summarize]

Create three adapted versions:

1. EXECUTIVE SUMMARY (for leadership, 1 paragraph):
   Focus on strategic fit, business impact, and timeline.

2. ENGINEERING BRIEF (for the dev team, 1 page):
   Focus on technical requirements, acceptance criteria, dependencies,
   and open technical questions.

3. DESIGN BRIEF (for UX/design, 1 page):
   Focus on user stories, user flows, design considerations, and
   success metrics related to user experience.

Each version should be self-contained -- the reader shouldn't need to
read the full PRD to understand their piece.

Exercise: Write a Real PRD

Take a feature you’re currently planning or considering. Use the workflow:

Feed your context into the PRD generation prompt
Refine the output with your strategic context and team knowledge
Run the quality check prompt
Create the adapted versions for your stakeholders
Compare the result to PRDs you’ve written before

Most PMs find the AI-generated first draft is 70-80% ready. The refinement step – where you add context, correct assumptions, and sharpen requirements – is where your expertise shines.

Key Takeaways

Great PRDs define what and why, not how – give engineering context to make smart implementation decisions
The structure that works: summary, problem, goals, user stories, requirements, acceptance criteria, out of scope
AI generates strong first drafts that you refine with strategic context and team knowledge
User stories should capture user goals, not implementation details – cover happy paths and edge cases
Acceptance criteria must be specific and testable: “under 200ms for 95% of queries” not “should be fast”
The “Out of Scope” section prevents scope creep – be specific about what you’re NOT building
Adapt the PRD for different audiences: executives need strategy, engineers need specs, designers need user context

Next: Using frameworks and AI to prioritize features and build defensible roadmaps.

Up next: In the next lesson, we’ll dive into Feature Prioritization and Roadmapping.