How to Write a PRD with Claude: A PM's End-to-End Workflow

The PRD problem PMs don’t talk about

Most PRDs that get written aren’t great PRDs. They get written under deadline pressure, after the conversation with engineering already happened, with the goal of documenting a decision rather than making one. The PRD shape — problem, user stories, scope, edge cases, open questions — is right. The execution drifts because writing 8 pages from a blank cursor is psychologically expensive.

Claude (Sonnet 4.6 or Opus 4.7 for harder problems) collapses the writing cost to near-zero. What it can’t do is the thinking — the unstated assumption surfacing, the “wait this contradicts a thing we shipped 3 months ago,” the political read on which stakeholder will object. That part stays yours. This guide is the 4-prompt sequence I use to push the writing cost down so the thinking gets all the time it deserves.

The sequence

You will spend ~25 minutes on this. Budget ~5 minutes per prompt for reading and revising Claude’s output. Don’t accept any prompt’s output as-is.

Prompt 1: Force the framing

I'm writing a PRD for [3-sentence brief]. Before I write anything,
help me get the framing right by surfacing the four things that
matter most:

1. What user problem does this actually solve? Be specific about
   the user persona and the moment they hit the problem.
2. What's the simplest version of this feature that would solve
   80% of the problem? (We will probably ship that version.)
3. What's the riskiest assumption embedded in shipping this?
4. What feature, if it exists, would make this PRD obsolete?

Push back if my brief is too vague to answer these. Don't fill
in plausible-sounding details from generic SaaS knowledge.

The “push back” instruction is load-bearing. Without it Claude will confabulate specifics to look helpful. With it, Claude will say “I can’t answer #1 — your brief doesn’t specify which user persona, and the answer differs significantly between an admin and an end user. Which do you mean?”

That question is the most valuable output. Answering it forces you to confront the thing you were going to write around.

Prompt 2: Generate the user-story skeleton

Based on the framing above (user persona: X, MVP scope: Y, risky
assumption: Z), generate 5-8 user stories in this format:

  As a [persona], I want to [action], so that [outcome].
  Acceptance criteria:
    - Specific, testable condition
    - Specific, testable condition

Cover the happy path plus three failure modes:
- The user does the right thing but the system is slow
- The user does something we didn't anticipate
- The user does something malicious

Skip the user stories that would be table-stakes for any
feature (auth, permissions). Focus on what's unique to this feature.

Output quality here is high — user-story format is well-represented in training data and the structure prevents drift. Read each story and cut the ones that don’t survive contact with your knowledge of the codebase. Usually you keep 4-6 of the 8.

Prompt 3: Generate the edge cases and open questions

For each user story above, list:
- One edge case engineering will ask about that I haven't addressed
- One edge case that will only matter at scale (>10k users)
- One data/migration concern if this feature changes existing data

Then list the 5 open questions I should resolve BEFORE the
engineering kickoff. Order them by how expensive they are to
defer.

This is the prompt that earns the $25/seat/month. The output catches the things a junior PM would miss because they haven’t been burned yet. Specifically the “edge case at scale” branch surfaces capacity, indexing, and async-job concerns that bite you 3 sprints after launch when there’s no time to redesign.

Prompt 4: Assemble + critique

Assemble all of the above into a PRD with these sections:
- Problem (2 paragraphs)
- Proposed solution (1 paragraph + bullet list of MVP scope)
- User stories with acceptance criteria
- Edge cases and failure modes
- Open questions (ordered by cost of deferring)
- Non-goals (3-5 items)

After assembling, switch into the role of a skeptical principal
engineer and give me three concerns about this PRD as written.

The “skeptical principal engineer” pivot at the end is the highest-value second pass. It surfaces the “you didn’t think about idempotency” and “this assumes the user is always logged in” gaps that you’d otherwise discover during eng review.

What the workflow doesn’t solve

Political surface area. Claude doesn’t know which VP will block this feature for territorial reasons. Read the room before you send the PRD.

Cross-team coordination. “Does this need a security review?” depends on company process. Claude can guess; your security lead knows.

Numerical claims. Claude will happily write “this feature affects 30% of our user base” if your brief implied a number. Strip every percentage and replace with [TBD: pull from amplitude] until you’ve actually pulled it.

The “do we even want to build this” question. That has to happen before Prompt 1. If you skip it, the PRD will be beautifully structured documentation of a wrong decision.

Why this beats Notion AI for PRDs

Notion AI’s PRD drafts come out coherent but template-y. The same 4-section structure regardless of feature, with the same generic phrasings. Claude (especially Opus 4.7 for harder features) produces output that adapts to the specific feature shape, and the multi-prompt sequence above forces you to do the actual thinking instead of just accepting the template.

If you use Notion as your docs surface, you can run this Claude sequence in claude.ai and paste the final PRD into Notion. The cross-tool friction is ~30 seconds per PRD and worth it for the output quality difference.

A worked example timing

Real PRD I wrote last week for an enterprise SSO config change:

• Prompt 1 (framing): 4 minutes, revealed I had two distinct user personas conflated
• Prompt 2 (user stories): 5 minutes, kept 5 of 7 generated stories
• Prompt 3 (edge cases): 6 minutes, caught a multi-tenancy edge case worth a full sprint to handle
• Prompt 4 (assembly + critique): 8 minutes, principal-engineer critique caught a missing rollback story

Total: 23 minutes to a PRD that engineering approved with zero rounds of “this needs more detail” feedback. Compare to the previous version of this workflow (blank doc → write → revise → send → eng asks for more detail → revise) which usually consumed 90+ minutes spread across 3 days.

The PM job hasn’t changed. The writing tax just got refundable.