I spent three hours once iterating on a prototype before I stopped and asked what I was actually trying to solve. I didn’t have an answer. The problem wasn’t the prototype. I’d skipped the thinking that should have come before it.
That’s the trap with AI and PRDs. A model can produce a clean, confident, well-formatted requirements document in under a minute. If the thinking behind it is vague, you get a polished document that’s wrong, and polished wrong is more dangerous than messy wrong because people believe it.
So the question isn’t whether AI can write your PRD. It can. The question is which parts it should write and which parts have to come from you. Here’s the workflow I use.
What a PRD is actually for
A PRD isn’t paperwork. It’s the thing that forces a half-formed idea to answer hard questions before it consumes engineering time:
- What problem are we solving, and for whom?
- How will we know it worked?
- What are we explicitly not building?
The value is in answering those questions, not in the document. AI is very good at the document. The answers are still your job. I wrote about why the PRD isn’t dead, even with fast prototyping tools, in Is the PRD dead?.
Step 1: Bring the raw material first
The quality of an AI-drafted PRD is set before you write a prompt. Before I open Claude, I gather:
- The problem, with evidence. Reviews, support tickets, funnel data, a quote from a customer. Not “users want X.” Proof that something is failing.
- Who it’s for, specifically. “Guests ordering in the drive-thru lane” beats “users.”
- The metric it should move, and roughly by how much.
- Constraints: timeline, platforms, what the team can and can’t touch.
- What’s out of scope. This is the section people skip and the one that saves the most arguments later.
If I can’t fill these in, I’m not ready for a PRD. I’m ready for more discovery.
Step 2: Talk it through before you ask for a document
My first prompt is never “write a PRD for X.” It’s a conversation. I describe the idea the way I would to a colleague, and I ask Claude to interview me: what’s unclear, what’s missing, what would an engineer or a skeptical stakeholder ask?
This is where most of the value is. Answering those questions sharpens the idea far more than reading a draft would. Vague concepts become real when you have to articulate them.
Step 3: Give it a fixed structure
Once the thinking is solid, ask for the PRD against a structure you choose, not whatever the model invents. Mine looks like this:
- Problem and evidence
- Who it’s for
- Goals and success metrics
- User stories and key flows
- Requirements (what, not how)
- Out of scope
- Open questions and risks
Better still, don’t retype it every time. Save the structure, your tone and your guardrails as reusable instructions. In Claude that’s a skill or a project. It turned the tool from something I prompt into something that already knows how I work. More on that in I stopped using Claude as a tool.
Step 4: Edit it like a junior PM’s first draft
Treat the output as a draft from a smart colleague who’s new to your business. Read it critically:
- Did it invent anything? Numbers, user research, constraints you never gave it. Delete or verify.
- Did it drift into “how”? Models love proposing architecture. Requirements should say what the product must do; engineers decide how.
- Is it confidently vague? “Improve the user experience” isn’t a requirement. Push until every requirement is testable.
- Is the out-of-scope list real? If it’s empty, the scope isn’t defined yet.
Give that feedback back to the model and iterate, the way you would with a person.
Step 5: Use the PRD as the prompt for what comes next
This is where it compounds. A well-structured PRD is the best possible brief for the next step. I hand mine straight back to Claude as the prompt for a working prototype, and because the requirements are clear, the prototype comes out close to right on the first pass. I walk through that in From PRD to prototype with AI.
Where AI helps most in writing a PRD
The biggest win isn’t that experienced PMs write PRDs faster, though they do. It’s that the barrier to writing a good one drops for everyone else.
The people closest to a problem, in operations, marketing or a franchise, often have the best observations and no way to turn them into something engineering can act on. A workflow that asks them the right questions and holds the structure lets them produce a usable first draft. That’s the experiment I’ve been running: one place where an idea goes in and a stakeholder interview, a PRD, a prioritization score and a prototype come out. I wrote about why in The PRD isn’t the problem.
The short version
- Gather the evidence before you prompt.
- Have AI interview you before it writes.
- Give it your structure, and save it as a reusable instruction.
- Edit hard: no invented facts, no architecture, nothing untestable.
- Feed the finished PRD into the prototype.
AI compresses the time it takes to write a PRD. It doesn’t replace the judgment about what’s worth building. That part was always the job.