What Is a PRD? How to Write One for an AI-Built Project

A PRD (Product Requirements Document) is a written plan that describes what you're building, who it's for, and what "done" looks like : before anyone builds anything. It used to be a software-team ritual. Now it's how you brief an AI builder so you get what you actually wanted instead of a confident guess.

What does PRD mean?

PRD means Product Requirements Document : a page or few that pins down the requirements of a thing before it gets built. It came out of software companies, where a product manager wrote one so that engineers, designers, and executives were all building the same product instead of three different ones.

The same planning discipline is useful when an AI coding assistant helps build a tool. A written problem, scope and acceptance test give you something concrete to compare against the output, regardless of who writes the code.

What goes in a PRD?

A working PRD answers six questions, in writing, before any work starts:

1. The problem : what's broken or missing, in one or two sentences. Not the solution. The problem.
2. The user : who exactly this is for. "Our dispatchers" beats "our team." One named person beats both.
3. The outcome : what's true after this exists that isn't true now. Booked jobs, hours back, calls answered.
4. The must-haves : the short list of things it has to do, or it's useless.
5. The won't-haves : what you're deliberately not building this round. This list prevents more blown budgets than any other line on the page.
6. The success measure : the number or test that tells you it worked. "The quote goes out same-day" is a measure. "It's better" isn't.

If you have those six answered honestly, you have a PRD. Everything else is formatting.

Example PRD: a missed-call follow-up tool. Problem: eligible callers wait until the office reopens. User: the office coordinator. Outcome: every eligible missed call enters a visible follow-up queue. Must-haves: check contact consent and status, create one follow-up task, draft an approved message and log the result. Exclusions: no pricing quotes, emergency triage or automatic appointment promises. Acceptance: in a test account, an eligible missed call creates exactly one task; repeat delivery does not duplicate it; opted-out and already-handled contacts receive no message; failures remain visible to the coordinator.

PRD vs. project brief vs. SOW : what's the difference?

A project brief describes the request. A PRD develops requirements and acceptance criteria. An SOW records the agreed scope, responsibilities and commercial terms. Their detail varies, and an SOW can include a detailed specification; the important question is whether the team has an unambiguous, agreed definition of the work.

Plenty of projects have a brief and an SOW and no PRD. That's how you end up with a deliverable that matches the contract and still isn't what you wanted.

Why AI brought PRDs back

An AI builder can produce a plausible implementation before you have resolved the important questions. That makes a written specification useful early: it exposes assumptions about users, permissions, failure handling and success before those assumptions become code. It does not eliminate the need for design, engineering or review.

A vague brief leaves room for the assistant to guess. Some assistants will ask clarifying questions; others may proceed with assumptions you did not intend. Ask it to list unresolved questions and explain its interpretation of the PRD before building. Review that interpretation against the business process, then test the finished behavior against the acceptance criteria.

How do you draft a PRD without a product manager?

Use the following five-step exercise for a first draft. The suggested time boxes help you start; a complex or regulated project will need more investigation and specialist input.

1. Write the problem in two sentences (10 min). If you can't, you're not ready to build : that's the hour doing its job.
2. Name the user and the outcome (10 min). Who uses this, and what number moves when it works.
3. List must-haves : cap it at five (15 min). If everything's a must-have, nothing is.
4. List won't-haves (10 min). Say out loud what version one will not do. This is where scope creep goes to die.
5. Define done (15 min). One test anyone could run: "A missed call gets a text back within 60 seconds." Pass or fail, no debate.

Then hand it to whoever's building : human, AI, or both : and make them repeat it back before anything gets built.

What happens to a PRD after you write it?

A PRD isn't a file you write and frame : it's the input to the build, and the best builds attack it before trusting it. Our own pipeline runs every PRD through an adversarial pass: an AI stress-tests the document for gaps, failure modes, and the questions nobody asked, before a single thing gets built. Cheaper to find the hole in the plan than in the product.

Go deeper: Project Launcher: the Claude Code plugin for research, PRDs, and gap analysis : the full pipeline: it researches your existing files first, interviews you only on what it couldn't find, drafts a 14-section PRD, grills it for weaknesses, then scaffolds the project so an AI can start building from an approved spec.

Not sure what to build first? Book a 30-minute call with us. We'll talk through the workflow, what you need it to do, and whether we can help you define a useful next step. No pitch, no obligation.

Sources and implementation references

Project planning workflow: https://github.com/Rhize-Media/rhize-plugins/blob/main/project-launcher/README.md