How to write a PRD with AI (with a free template)

What a PRD is actually for

A PRD has two readers, and it is worth writing for both.

The first is the person building the thing. They need to know what problem it solves, who it is for, what the first release includes and what it deliberately does not. If they have to come back to you with questions every afternoon, the document is not doing its job.

The second reader is the person checking the build afterwards. That might be you, a co-founder, a reviewer, or an auditor before launch. They need to be able to go through the document line by line and say "yes, this is done" or "no, it is not." That is only possible if the requirements are written as statements that can be true or false about the running product.

Most PRD templates serve the first reader. Very few serve the second, which is why so many products ship "what we built" rather than "what we agreed."

The sections that matter

A useful PRD for a first release has about ten short sections:

1. Overview. Name, owner, status, a one-line summary. If you cannot say what it is and who it is for in two lines, keep thinking before you write anything else.
2. Problem. The problem as the user lives it, what they do today instead, and how you know. "Interviews with six clinic managers" is evidence. "Everyone hates this" is not.
3. Target user. One primary user, the trigger that makes them look for something new, and who this is not for.
4. Jobs to be done. Three to five, in the user's words: when this happens, I want to do that, so I can get this outcome.
5. MVP scope. What the first release does, in lines a person could watch working.
6. Requirements. Numbered, checkable statements with acceptance criteria and a priority.
7. Success metrics. What you will measure, where, and the target, or a blank where you do not have one yet.
8. Non-goals. What this release deliberately does not do.
9. Open questions. Each with an owner and a date.
10. Sign-off. Who agreed, when, and how later changes get proposed.

Section six is the one that changes everything, so it gets its own heading below.

Write requirements that can be checked

A requirement is a single statement that can be true or false about the built product. "Authentication" is a topic. "Users can reset their password by email" is a requirement.

Each requirement gets four things:

• A key, such as REQ-001. Keys are permanent. You never renumber or reuse one, because tasks, commits and audits will refer to it.
• Acceptance criteria, describing how someone would check it on the running system. "Request a reset, receive the email within a minute, set a new password, sign in with it." If you cannot write this, the requirement is not finished.
• A priority. MoSCoW is enough for a small team: Must, Should, Could, Won't. Five-point scales invite arguments about a 3 versus a 4 when the only decision that matters is whether the first release ships without it.
• A kind: functional (behaviour), non-functional (speed, uptime, accessibility) or constraint (a regulation, platform or budget).

Two rules keep the list honest. One commitment per row: if a sentence contains two, split it. And a requirement with no acceptance criteria is marked incomplete, not quietly accepted.

Where AI helps, and where it does not

Here is the division of labour that works.

Give the model the context, not the decisions. Paste in what you actually know: the problem in your own words, notes from customer conversations, the constraints you are working under, what you have already ruled out. A model drafting from a one-line prompt will fill every gap with something plausible, and plausible is the enemy here, because it reads as agreed.

Let it draft the structure and the first pass. Models are good at turning messy notes into the ten sections above, at spotting a missing non-goal, and at rewriting "the system should be fast" into something measurable. They are fast at the boring parts.

Keep scope decisions for a person. What is in the first release, what is out, and what "done" means are business decisions. A model will happily invent a requirement because it sounds sensible or standard. That is exactly the scope nobody agreed to, and it tends to surface weeks later as work nobody asked for.

Never let it invent numbers. If a target, a price or a date is not something you know, leave it blank. A made-up success metric in a PRD gets treated as a commitment.

Review what it extracted against what it read. If you use a model to turn a prose document into a requirements table, ask it to quote the sentence each requirement came from. Then you can check forty rows without rereading the whole document, and anything with no source sentence is an invention.

A workflow you can run today

If you are working by hand with a general-purpose assistant:

1. Copy the PRD template into your editor.
2. Write the problem and target user sections yourself. They are short, and they are the part a model is worst at, because only you know who you have talked to.
3. Paste your notes and ask the model to draft jobs to be done, MVP scope and non-goals, using only what the notes say.
4. Ask it to propose requirements as a table with key, statement, acceptance, priority and kind, quoting the source sentence for each.
5. Delete anything without a source. Fill in acceptance criteria that are missing. Decide the priorities yourself.
6. Get sign-off, and freeze that version. From here, changes are proposed and recorded, not edited in silently.

Doing it inside Atrix AI

Atrix AI runs the same workflow inside your workspace, with the guardrails built in.

In Develop mode, the agent reads what your project already holds: its summary, pitch and target customer (including the notes from an idea you promoted into it) and the documents in it. It writes the PRD as a document in the project, with problem, target user, jobs to be done, MVP scope, success metrics and non-goals. Ask again and it updates that one document, keeping the previous text as a version, rather than producing a new copy.

Atrix can then extract the requirements from the PRD as keyed rows with acceptance criteria, a MoSCoW priority and a kind, each quoting the sentence it came from. A row whose quote cannot be found in the document is discarded. Everything else lands as proposed, and nothing counts until a person accepts it. Any requirement without acceptance criteria, other than a Won't, is flagged, and the requirements cannot be frozen until each one has them and nothing is still waiting to be accepted.

Accepted requirements can be broken into backlog issues, each one naming the requirement key it serves, so your project management stays tied to what was agreed. When you hand the build to a coding agent, the handover bundle carries the documents and the requirement keys, and asks for the keys to be referenced in commits.

That is what makes the last step possible. You can freeze the accepted requirements as a baseline, and the requirements audit shows, for each one, whether work exists, is in progress or is done, and which requirements changed or were dropped after sign-off. The report is computed from your records, not from a model's opinion. It does not read your code; it tells you whether the work recorded against each agreed requirement is done.

Extracting requirements and breaking them into issues each use one AI run, so the free plan's five runs a month cover a first PRD comfortably.

A short checklist before you call the PRD done

• Could someone outside the team build the first release from it without asking you?
• Does every Must requirement have acceptance criteria?
• Is every requirement one statement that can be true or false?
• Are the non-goals written down?
• Does every open question have an owner and a date?
• Has someone signed it off, and is that version saved?

If the answer to all six is yes, you have a PRD that serves both of its readers. Start from the free template, or let the agent draft it and spend your time on the decisions.