How to Write a PRD (Product Requirements Document) + Template

A product requirements document (PRD) describes what you're going to build, who it's for, and how you'll know it's done — written before the building starts. In big companies it's a formal document. For a solo founder or small team, it can be a page.

With AI tools writing more of the code, the PRD matters more, not less. An AI coding agent will build exactly what you describe — so the quality of the description sets the ceiling on the result. (Spec-driven development)

What goes in a PRD

1. The problem

Who has what problem, and why it matters. One paragraph.

Freelance designers lose track of which invoices are unpaid. They chase clients from memory and miss late payments.

2. Who it's for

The specific user. "Freelance designers with 5–20 clients" beats "small businesses".

3. Goals — and non-goals

What success looks like, and what you are deliberately not doing.

Goal: a freelancer can see every unpaid invoice and send a reminder in two clicks. Non-goals: accounting, tax, multi-currency, teams.

Non-goals prevent the scope from quietly growing — with humans and with AI.

4. User stories or flows

The key things a user does, step by step. (User stories explained)

As a freelancer, I want to mark an invoice as paid, so my overdue list is accurate.

5. Requirements

Specific behaviour, including edge cases:

Invoices are overdue the day after their due date.
Reminder emails can be sent at most once every 3 days per invoice.
Deleting a client archives their invoices; it doesn't delete them.

6. What it looks like

Sketches or wireframes, even rough ones. (What is a wireframe?)

7. How you'll know it works

Acceptance criteria and a metric. "A new user can add a client and an invoice in under two minutes." "30% of trial users send a reminder in week one."

8. Open questions

Things you haven't decided yet. Writing them down stops them being decided by accident.

A short template

# [Feature / product name]

## Problem
## Users
## Goals
## Non-goals
## User stories
## Requirements (incl. edge cases)
## Design notes / sketches
## Success criteria
## Open questions

Keep it to one or two pages for an MVP. (What is an MVP?)

Using AI to write it

AI is genuinely useful here — not to invent your product, but to interrogate it.

Draft from your notes:

Here are my rough notes about an invoice-chasing tool for freelance designers. Turn them into a PRD using this template. Mark anything you had to assume as [ASSUMPTION].

Have it interview you:

Ask me questions one at a time until you understand this product well enough to write a PRD. Focus on users, edge cases and what's out of scope.

Pressure-test it:

Act as a sceptical engineer. List the ambiguities, missing edge cases and contradictions in this PRD.

The assumptions it flags are where the real decisions are.

From PRD to code

A PRD makes a much better prompt than "build me an invoicing app". With a coding agent like Claude Code, you can:

Save the PRD in your repo (docs/PRD.md).
Ask the agent to read it and propose a technical plan — in plan mode, so nothing changes yet. (Claude Code plan mode)
Build one user story at a time, checking each against the acceptance criteria. (How to plan your first app)

Common mistakes

Describing the solution, not the problem. "Add a dashboard" — for what?
No non-goals, so everything creeps in.
No edge cases — they're where bugs and support tickets live.
Writing it once and never updating it. It's a living document while you build.

EasySpawn gives your project a persistent workspace where the PRD, the code and the running app live together — and Claude Code can build from the spec while you're away. See how it works or join the waitlist.

How to Write a Product Requirements Document (PRD) — With AI's Help