How to Write a Product Requirements Doc with AI (Free Template)
How to write a product requirements doc with AI: what a PRD needs, prompts that draft each section, a fill-in template, and how to check what the AI wrote.
Mythex Team · · 7 min read
A product requirements document (PRD) is a short, plain-language description of what you are building, who it is for, what it must do, and how you will know it works. AI makes writing one much faster: you give it rough notes and it turns them into structured sections, user stories and edge cases. Your job is to supply the decisions the AI can't make — the goal, the scope and what gets left out — and to check what it adds.
This guide covers what belongs in a PRD, a step-by-step way to draft one with any AI assistant, prompts for each section, and a fill-in template you can copy.
What a PRD is for (and what it isn't)
A PRD answers four questions:
- Why are we building this? What problem, for whom?
- What must it do in the first version?
- What won't it do yet?
- How will we know it worked?
It is not a technical design. It doesn't say which database or framework to use — that belongs in a separate technical spec, if you need one at all. It is also not a marketing brief or a business plan. Keeping the PRD to the product's behaviour is what makes it useful to everyone who reads it: a designer, a developer, a stakeholder signing off, or an AI app builder turning it into code.
Who needs one
- Solo founders who want to stop scope creep before it starts.
- Small teams that need one place where "what we agreed" lives.
- Anyone hiring a freelancer or agency, because a clear PRD gets clearer quotes. See hire a developer or build with AI.
- Anyone building with AI, because a PRD's user stories and data list make better prompts than an unstructured wish list.
What AI is good at — and what it isn't
| Task | AI does well | You still own it |
|---|---|---|
| Turning messy notes into sections | Yes | Checking nothing was invented |
| Writing user stories in a consistent format | Yes | Deciding which stories are in version one |
| Listing edge cases (empty states, errors, permissions) | Yes, often better than a tired human | Deciding which ones matter |
| Suggesting success metrics | Gives reasonable options | Choosing ones you can actually measure |
| Knowing your users, market or budget | No | All of it |
| Deciding what to leave out | No — it tends to add, not cut | All of it |
The most common failure is the second-to-last row turned upside down: the AI confidently fills gaps with plausible guesses about your users. Treat anything it writes about users, market size or behaviour as a question to verify, not a fact.
Step 1: Dump what you know
Before you prompt anything, write rough notes. Bullet points are fine. Cover:
- The problem, in one or two sentences, from the user's point of view.
- Who has it. Be specific: "freelance bookkeepers with 10–40 clients", not "small businesses".
- What they do today instead (a spreadsheet, email, a tool they dislike).
- The one outcome that would make version one a success.
- Anything you already know you won't do.
- Hard constraints: deadline, budget, must work on phones, must integrate with a tool you already use.
If you haven't talked to anyone who has the problem, do that first. How to validate an app idea has a practical way to do it. A PRD built on guesses is a well-formatted guess.
Step 2: Ask the AI for a first draft
Paste your notes and ask for a draft in a fixed structure. A prompt that works well:
Here are my notes on a product. Turn them into a product requirements document using exactly these sections: Summary, Problem, Users, Goals and success metrics, Scope (in / out), User stories with acceptance criteria, Data, Permissions, Edge cases, Open questions. Keep it under two pages. Do not invent facts about users or the market — where my notes don't say, write the question under Open questions instead.
The last instruction matters. Telling the AI to route unknowns into "Open questions" instead of filling them in produces a far more honest draft.
Step 3: Tighten each section
Go through the draft section by section. These follow-up prompts help:
Problem and users
Rewrite the problem statement in one or two sentences from the user's point of view. No solution words.
If the problem statement mentions your product, it is describing a solution, not a problem.
Goals and success metrics
Suggest three success metrics for version one that I could measure in the first month with a small number of users. For each, say how I'd measure it.
Pick one or two. "Twenty bookkeepers use it weekly for a month" is measurable. "Improve productivity" is not.
Scope
List everything in this PRD that could be moved to a later version without breaking the core flow.
AI tools tend to add features. This prompt makes them do the opposite. Be ruthless: most version-one PRDs are too big. What is an MVP explains why small first versions teach you more.
User stories and acceptance criteria
Write each requirement as a user story ("As a [user], I want [action] so that [outcome]") with two to four acceptance criteria in Given / When / Then form.
Acceptance criteria are the checklist you will test against later. "Given a booked slot, when another client views the calendar, then the slot is not shown" is testable. "Booking works well" isn't.
Edge cases and permissions
For each user story, list what happens with empty data, invalid input, a slow or failed network request, and a user who shouldn't have access.
This is where AI earns its keep. It is quick at spotting the empty states and permission gaps people forget.
Step 4: Review it like a skeptic
Read the whole thing once more and check:
- Every claim about users came from you or from research, not from the AI.
- Scope "out" is at least as long as scope "in".
- Each user story has acceptance criteria someone could test without asking you.
- The data section lists every kind of record the app keeps and who can see it.
- Open questions have an owner and a date.
- Nothing technical snuck in unless it's a real constraint ("must work offline" is a requirement; "use Redis" is not).
Then share it with one person who will use or build the product and ask what's unclear. Their questions are the gaps.
Fill-in PRD template
Copy this into a doc and replace the brackets. Delete any section that genuinely doesn't apply.
Product name: [name] Owner: [person responsible for decisions] Status: [draft / in review / agreed] — Last updated: [date]
1. Summary
[Two or three sentences: what this is, for whom, and the main outcome.]
2. Problem
[The problem from the user's point of view. What they do today and why it hurts.]
3. Users
| User type | What they need | How often they'll use it |
|---|---|---|
| [e.g. Owner] | [need] | [daily / weekly] |
| [e.g. Client] | [need] | [occasionally] |
4. Goals and success metrics
- Goal: [the outcome version one must achieve]
- Metric: [how you'll measure it, and the target]
- Non-goal: [something people might assume, that this version is not trying to do]
5. Scope
In version one:
- [feature]
- [feature]
Not in version one:
- [feature, and why it can wait]
- [feature, and why it can wait]
6. User stories
Story 1: As a [user], I want to [action] so that [outcome].
- Given [context], when [action], then [result].
- Given [context], when [action], then [result].
Story 2: As a [user], I want to [action] so that [outcome].
- Given [context], when [action], then [result].
7. Data
| Record | Key fields | Who can create | Who can see |
|---|---|---|---|
| [e.g. Booking] | [date, time, client, service] | [client] | [owner, that client] |
8. Permissions
[Who can log in, what roles exist, and what each role can see and change.]
9. Edge cases
- [Empty state: what shows when there's no data yet]
- [Invalid input: what happens with a wrong email or missing field]
- [Access: what happens when someone opens a page they shouldn't]
10. Integrations and constraints
[Payments, email, existing tools, deadlines, budget, devices it must work on.]
11. Open questions
| Question | Owner | Decide by |
|---|---|---|
| [question] | [name] | [date] |
From PRD to prompts
A good PRD converts almost directly into prompts for an AI app builder:
- The summary, users and data table become your first prompt.
- Each user story becomes one follow-up prompt.
- Each acceptance criterion becomes something you test in the preview.
- The "not in version one" list is what you refuse to ask for yet.
Building one story at a time and checking its acceptance criteria before moving on is far more reliable than pasting the whole PRD and asking for everything. How to write prompts for AI app builders covers the prompting side in more detail.
Common mistakes
- Writing the solution as the problem. "Users need a dashboard" is a solution. "Owners can't see which invoices are overdue without opening each one" is a problem.
- No "out of scope" section. Without it, every conversation reopens the scope.
- Letting the AI invent users. Personas the AI made up feel real and aren't.
- Metrics you can't measure. If you have no way to count it, it isn't a metric.
- Never updating it. A PRD that no longer matches what you're building is worse than none. Keep a "last updated" date and change it when decisions change.
Using a PRD with Mythex
If you build in Mythex, you can paste your PRD straight into chat. Starting in Plan mode is a good fit for a PRD: the agent reads it, proposes an approach and a step checklist you can review in a plan tab, and only starts changing files when you press Build. You can also save the parts that should always apply — audience, brand, rules — as project knowledge so you don't repeat them in every chat. The chat docs explain Build, Plan and Ask modes, and the templates are a quick way to see how a first version might look before you write the full document.
Questions
What is a product requirements document?
A PRD is a short document that says what a product or feature should do, who it is for, and how you will know it works. It describes the problem and the expected behaviour, not the code, so designers, developers and AI tools can all build from it.
Can AI write a PRD for me?
AI is good at turning your notes into a structured draft, spotting missing sections and suggesting edge cases. It cannot know your users, your constraints or your priorities, so you still decide the goal, the scope and what is left out, and you check every requirement it adds.
How long should a PRD be?
As short as it can be while still answering who, what, why and how you will measure it. For a first version of an app, one to three pages is usually enough. Long documents tend to go unread and hide the few decisions that matter.
Do I need a PRD if I build with an AI app builder?
You don't need a formal one, but a short PRD makes AI builders far more reliable. The user stories and data list in a PRD translate almost directly into good prompts, and the scope section stops you from asking for everything at once.