How to Write a PRD with Claude Code: a PM's Step-by-Step Guide

Why a coding agent, not a chatbot?

Every PM has tried writing a PRD in ChatGPT. The result is always the same: a generic template filled with plausible-sounding inventions — metrics you don't track, personas you never defined, a rollout plan for a product it has never seen. You spend more time deleting fiction than you saved on drafting.

The problem isn't the model. It's the medium. A chat window starts from zero on every conversation. A coding agent like Claude Code works inside a folder — it reads the files that are there before it writes anything. That one difference changes everything for PM work:

• Persistent context. Put documents describing your product, users, and metrics in the folder once. Every future PRD is grounded in them automatically.
• Real artifacts. The output is a markdown file you keep, version, diff, and iterate on — not a wall of chat text you copy-paste and lose.
• Reusable instructions. Your PRD structure and quality bar live in a prompt file, so the tenth PRD is as sharp as the first — and so is your teammate's.

The agent is brilliant. It just has no idea what your product is — until you put your product in front of it.

Step 0 — What you need (no, you don't need to code)

You need exactly two things: Claude Code installed (their docs cover it — it's one command), and an empty folder, e.g. pm-workspace. That's it. Everything you do from here is typing plain English. The terminal is just where the conversation happens.

Everything below also works with OpenAI Codex or Google Antigravity — the approach is agent-agnostic, because it's built on plain markdown files.

Step 1 — Give the agent your context, once

This is the step almost everyone skips, and it's the one that separates a grounded PRD from AI slop. Before writing any PRD, create a few short markdown files in your folder:

• context/product.md — what your product does, main features, current focus, key metrics you actually track
• context/users.md — your real personas or segments, their jobs-to-be-done, top pain points
• context/company.md — company stage, how decisions get made, what a "good" spec looks like in your org

You don't have to write these by hand. Open Claude Code in the folder and say: "Interview me to create context files about my product, my users and my company. Ask one question at a time, then write the files." Fifteen minutes of answering questions, done — and every artifact you generate from now on starts from your reality instead of a hallucination.

Step 2 — Ask for the PRD, with structure

Don't just say "write me a PRD." The quality of the output tracks the specificity of the instruction. Here's a starting prompt you can copy — it encodes the two rules that matter most:

Read the files in context/ first.

Write a lean PRD in markdown for the feature I describe below.
Structure: Problem & evidence · Goals and success metrics ·
Target users · Scope and explicit non-goals · Requirements
(written for engineers) · Risks · Open questions.

Two rules:
1. Ground every claim in my context files. If something
   important is missing (a metric, a segment, a constraint),
   ASK me instead of inventing it.
2. Keep it lean. Engineers should read it in 5 minutes.

Feature: [describe your feature in 2-3 sentences]

Rule #1 is the difference between a co-pilot and a fiction generator. A well-instructed agent will come back with questions like "which seller tier is this for?" or "you don't track activation by cohort — what metric should success use?" Those questions are the agent showing you the gaps in your own thinking. Answer them; the PRD gets sharper than what either of you would have written alone.

Step 3 — Review like a PM, not a proofreader

The agent's draft will be structurally complete and well-written. Your job is judgment, not grammar:

• Are the non-goals real? Weak AI PRDs scope everything in. Push back: "cut scope to what one squad ships in six weeks."
• Would you bet on the success metric? If the metric feels generic, say "propose 3 alternative success metrics and argue for one."
• Do the requirements survive engineering contact? Ask the agent: "what would an engineer find ambiguous here?" — it's remarkably good at attacking its own draft.

This iteration loop is fast because the agent edits the file in place. You're having a spec review conversation, except the document updates itself as you talk.

Step 4 — Don't stop at the PRD

A PRD's job is to become work. The same grounded agent can slice the PRD into user stories with testable acceptance criteria, generate QA test scenarios from it, or draft the leadership update announcing it — each artifact feeding the next, all grounded in the same context. That's the actual unlock: not one document faster, but a connected agentic workflow where nothing starts from a blank page.

Common mistakes to avoid

• Skipping context and prompting harder. No prompt engineering compensates for the agent not knowing your product. Context first.
• Accepting invented facts. If you didn't tell the agent your churn rate, it doesn't know it. Instruct it to ask, and check numbers in drafts.
• Treating the draft as done. The agent produces the artifact; you own the decisions in it. Review the bets, not the commas.
• One giant chat session for everything. Start a fresh session per artifact and let the files carry the context — that's what they're for.

FAQ