How to Write a PRD with AI: A Step-by-Step Guide
Short answer: to write a PRD with AI, give Claude or ChatGPT the raw material first (the idea, notes, customer requests, constraints, the deadline), ask it to list what’s missing before it writes, then have it fill a fixed set of sections: problem, users, goals and non-goals, success metrics, prioritized requirements with acceptance criteria, user flows, edge cases and open questions. Forbid it from inventing research or numbers, and review the draft with the people who will build it. The model drafts; the decisions stay yours.
This guide walks through the six steps, gives you a prompt you can paste today, and shows what to check before the document goes to your team.
What is a PRD, and what can AI do for it?
A product requirements document (PRD) says what you’re building, for whom, why, and how you’ll know it worked. It’s the page the team reads before building, and the page you come back to when someone asks “is this in scope?”.
AI is good at the parts that take time and little judgment:
- Turning messy notes and call transcripts into clean sections.
- Spotting gaps: a requirement with no acceptance criteria, a flow with no error state.
- Writing the edge cases and questions engineers would ask in review.
- Reformatting the same content as a one-pager, user stories or tickets.
AI is bad at the parts that need you: knowing what users actually said, choosing what to cut, setting the target for a metric, and knowing the technical limits of your codebase. A model that doesn’t have those facts will guess, and a guessed PRD is worse than none.
How do you write a PRD with AI, step by step?
1. Collect the raw material before you open the chat
Put everything in one place: the idea in two sentences, customer emails or interview notes, the request from sales, screenshots, the deadline, the team size, and anything you already know you won’t do. The quality of the PRD depends on this step more than on the model, because the model can only reorganize what you give it.
2. Ask the model what’s missing first
Don’t ask for the document yet. Paste the material and ask: “Before you write anything, list the questions whose answers would change the scope.” Answer the ones you can. Mark the rest as open questions; they belong in the PRD too. This step matters because a model that writes first fills every gap with a plausible guess, and guesses read exactly like facts.
3. Give it a fixed structure
Tell the model exactly which sections you want, in order. A structure you can start from and adjust:
| Section | What it answers |
|---|---|
| Problem | What’s broken, for whom, and how you know |
| Users and jobs | Who uses this and what they’re trying to get done |
| Goals and non-goals | What this release must do, and what it won’t |
| Success metrics | How you’ll know it worked, with the baseline if you have one |
| Requirements | Must / should / could, each with acceptance criteria |
| User flows | Step by step, including errors and empty states |
| Edge cases | The odd inputs, limits and permissions |
| Out of scope | What was discussed and left out |
| Open questions and risks | What’s undecided, and who decides |
4. Forbid invented facts
Add this line to every PRD prompt. Tell the model: “Don’t invent user research, metric baselines or technical constraints. Where a fact is missing, write [ASSUMPTION: …] and say who should confirm it.” You’ll get a draft full of brackets, and that’s the point: each bracket is a decision you still owe the team.
5. Make every requirement testable
Ask for acceptance criteria on each requirement, written so QA can check them with a yes or a no. The reason: a requirement nobody can test is a requirement nobody can call done. “The export is fast” becomes “the export of 1,000 rows finishes in under [X] seconds”. You fill in X.
6. Review it with the people who build it
Read the draft out loud with an engineer and a designer. Cut what nobody would miss. Move anything argued about into open questions. Then ask the model for the version each audience needs: a one-page summary for leadership, user stories for the backlog, tickets for the sprint.
What prompt should you use to write a PRD with AI?
Paste this into Claude or ChatGPT, then add your material below it:
You are helping me write a product requirements document for [product or feature]. The readers are [engineering, design, QA]. First, list the questions whose answers would change the scope, and wait for my answers. Then write the PRD in Markdown with these sections: problem, users and jobs, goals and non-goals, success metrics, requirements (must / should / could, each with acceptance criteria), user flows, edge cases, out of scope, open questions and risks. Use only the facts I give you. Don’t invent user research, metrics or technical constraints: write [ASSUMPTION: …] and who should confirm it. Keep each section short.
The AI Prompt Generator in the Nexin library builds prompts like this for other documents too.
Claude or ChatGPT: which is better for writing a PRD?
Both can draft a PRD from the same prompt, and you should check either one’s draft the same way. The difference is in how you reuse the method. In Claude, you can install the method once as a skill, so you only say “write a PRD for this” next time; what are Claude skills explains how that works. In ChatGPT, you’d keep the prompt in a custom GPT or paste it each time. Claude vs ChatGPT for content creation compares the two in more detail.
What should you check before you share an AI-written PRD?
- Every number has a source. If a metric target or a user count came from the model, it’s a guess. Replace it or mark it.
- Non-goals are written down. The scope arguments you don’t settle now come back mid-sprint.
- Acceptance criteria are testable. Each one can be checked with a yes or a no.
- Open questions have owners. A question with no name next to it stays open.
- It reads like your team wrote it. Cut the filler the model adds; humanize AI text lists the patterns to remove.
FAQ
Can AI write a whole PRD by itself?
It can write the whole document, but not the decisions in it. Give it your notes and constraints, and expect to answer its questions and fix its assumptions.
How long should a PRD be?
As short as the team can build from. A single feature rarely needs more than a few pages. Ask the model for a one-page version once the full draft is agreed.
What’s the difference between a PRD and user stories?
A PRD explains the problem, the goals and the scope. User stories break the requirements into pieces the team can build one at a time. You can ask the model to turn the finished PRD into stories.
Is it safe to paste internal notes into an AI chat?
Check your company’s AI policy first. Remove customer names and anything confidential you don’t need for the document.
A PRD method you install once in Claude. The PRD Writer skill in the Nexin library follows the steps above: it asks the questions that change the scope, writes every section with must, should and could requirements and acceptance criteria, and labels each assumption instead of inventing facts. Install it once (how to install a skill in Claude) and say “write a PRD for this”. It comes with Nexin Lite ($14 once, 7-day money-back guarantee) or Nexin Pro ($19 a month, 7 days free). Either plan opens the whole library. See pricing.