How to Write a PRD for an MVP: Template, Example and the Mistakes to Avoid
A good MVP PRD is short, specific and testable. It tells whoever builds your product, a developer or an AI, exactly what v1 does, what it doesn't, and how you'll know it works. Here's the 8-section structure, with a filled-in example.
Generate my PRD — free · Get help writing it
What an MVP PRD is
A PRD describes what you're building, for whom, and what done means. For an MVP it should fit on 2–4 pages. Not a wish list, not a technical design.
It used to go stale when development started. When AI writes most of the code, the PRD is the instruction it builds from. A vague PRD becomes software that does the wrong thing, fast. A precise one is what you check every output against.
The 8 sections
Write them in this order. Each section should be specific enough that a developer, or an AI, can build from it without guessing the product.
1. Problem statement
Two or three sentences. Who has the problem, what it costs them, and no solution yet. If the problem statement already names the product, you have skipped the problem and started selling the build.
2. Target user
One primary user, described by situation rather than demographics, plus a secondary role such as an admin who approves. Two primary users usually means two products.
3. Goal and success metric
A single assumption, plus one measurable threshold and a date. v1 tests whether that assumption is true. The metric is how you will know, not a list of hopes.
4. Core workflow
Numbered steps from entry to the moment of value. The reader should be able to walk the path without inventing screens you did not describe.
5. v1 scope
Each feature is one line, tied to a workflow step. If a feature does not support a step in section 4, it is not in v1.
6. Non-goals
Name what this release will not do. Non-goals are how the roadmap stays out of the build. Write them even when they feel obvious.
7. Acceptance criteria
Given, when, then. Each criterion is something a person or a test can observe. "Fast and easy" is not a criterion. "One tap, and a notification within 1 minute" is.
8. Constraints, risks, open questions
Constraints are limits you already know. Risks are ways the plan can fail, with a mitigation. Each open question has an owner. An unowned question is a decision the build will make for you.
How this compares to the PRDs product teams use
Two templates show up first when founders search. This 8-section PRD sits between them: shorter than a team document, more specific than a prompt.
Lenny's Product Requirements template (Atlassian/Confluence) is built around one idea: crystallise the problem first (description, problem statement, why, success metrics, audience), then align and keep re-aligning. Sections 1–3 here are the same move. What it leaves to the team, and what an AI builder needs spelled out, is sections 6–7: non-goals and testable acceptance criteria.
Product Requirements Documents: A Modern Guide (Aakash Gupta) makes the case that modern PRDs are shorter than the old ones and more specific: real user data, real metrics, no placeholder language, no half-finished sections presented as done. "The modern PRD doesn't just outline what the team should build, it excites them to build it." That is the reason for the 2–4 page limit.
Design Docs at Google (Malte Ubl) is where "goals and non-goals" as a formal section comes from, and the source for the rule that a PRD says what and why while the design doc (our technical scope) says how. "Our job is not to produce code per se, but rather to solve problems."
Copy the template
Copy the markdown and replace the brackets. There is no email gate, and there is no separate document to duplicate.
MVP PRD template
# [Product name] — MVP PRD
## 1. Problem
[Who] struggles to [job] because [cause]. Today they [workaround], which costs [time/money/risk].
## 2. Target user
Primary: [role, context, trigger moment]
Secondary: [role, e.g. approver or admin]
## 3. Goal and success metric
v1 tests whether [assumption].
Success = [metric] reaches [threshold] by [date].
## 4. Core workflow
1. [User does…]
2. [System responds…]
3. …
5. [Moment of value]
## 5. v1 scope
- [Feature] — supports step [n]
## 6. Non-goals
- Not in v1: […]
## 7. Acceptance criteria
- Given [context], when [action], then [observable result].
## 8. Constraints, risks, open questions
- Constraint: […]
- Risk: […] — mitigation: […]
- Open question: […] — owner: […]
Skip the blank page. Describe your feature and Codalio drafts all 8 sections.
Worked example: ShiftSwap
This is an illustration, not a customer. It continues the ShiftSwap checklist example and is scoped further in the technical scope example.
Problem
Staff at small clinics swap shifts by group text. Managers spend 2–3 hours a week chasing and recording swaps, and swaps get missed.
Target user
Primary: front-desk and nursing staff who need to swap a shift. Secondary: the clinic manager who approves.
Goal
Test whether staff will request swaps in an app instead of texting. Success = 60% of 8 pilot clinics run at least one swap a week through the app by week 4.
Workflow
- Staff post a shift they can't work.
- Eligible colleagues are notified.
- A colleague claims the shift.
- The manager approves or declines in one tap.
- Both staff and the schedule are updated.
Non-goals
No payroll, no native mobile app (mobile web is fine), no multi-location, no in-app chat.
Acceptance criteria
- Given a posted shift, when a colleague without the required role tries to claim it, then the claim is blocked and they see why.
- Given a claimed shift, when the manager approves, then both staff get a notification within 1 minute and the schedule shows the new assignee.
Six mistakes
Features before the problem
A list of features is not a PRD. If section 1 does not say who is stuck and what it costs, the rest of the document is a wish list with headings.
No non-goals
Without a list of what is out, every later conversation adds scope. The non-goals section is the boundary the builder is allowed to defend.
Untestable acceptance criteria
"Fast and easy" cannot fail a review. "The manager approves in one tap and both staff get a notification within 1 minute" can. Write the observable result.
Mixing in technical design
The database, the API, and the hosting choice belong in the technical scope. A PRD that specifies tables is doing two jobs and usually doing the product job worse.
Writing it once and never updating
A PRD that drifts from the product becomes a document nobody trusts. When the decision changes, change the PRD first, then the build.
Too long
Past about 4 pages, people stop reading. An MVP PRD should fit on 2–4 pages: long enough for workflow, scope, non-goals, and acceptance criteria, and short enough that everyone actually reads it.
A PRD is now an instruction, not a memo
When a human team built the product, a weak PRD cost you meetings. When an AI tool builds it, the PRD (or the prompt standing in for one) is the specification the code is generated from. Every gap becomes a guess, and the guesses are made instantly and confidently. Osmani's distinction between vibe coding and AI-assisted engineering turns on exactly this: a spec written before implementation, and requirements you can test the output against.
The open-source tooling has moved the same way. GitHub's Spec Kit makes a written spec, a clarify pass and a requirements checklist the mandatory first steps before any code (see its quickstart). Our weekly open-source coding tools page tracks the rest. The 8-section PRD in this post is the founder-sized version of that discipline: short enough to write in an afternoon, structured enough for a tool to build from.
Codalio Blueprint
/prd-builder in Codalio Blueprint runs this interview for you, passes the answers through a product lens, an architecture lens and a go-to-market lens, and writes one merged PRD into docs/prd/. It is free and MIT-licensed, and it works in Claude Code, Cursor, Codex, Gemini and Antigravity. Codalio takes the same PRD the rest of the way: technical spec, then production-grade code in a repository you own, with the code kept traceable to the requirement it came from. When the code and the PRD disagree, you see it.
Paste this into your coding tool
These work in Claude Code, Cursor, Codex CLI, Gemini CLI and Antigravity. The plain-prompt ones also work in Lovable, Replit and Bolt chat. Snippet 4 needs Blueprint installed.
Snippet 1 — Draft the PRD from a rough idea (any AI tool).
You are a senior product manager. I will describe a product idea in plain English. Before writing anything, ask me the questions a PM would ask at kickoff, one at a time, and propose a sensible default answer for each so I can confirm or correct it. Cover: the user, the painful moment, the single assumption v1 tests, the success metric, the core workflow, non-goals, constraints. Then write an MVP PRD with exactly these 8 sections: 1 Problem, 2 Target user, 3 Goal and success metric, 4 Core workflow (numbered), 5 v1 scope (each feature tied to a workflow step), 6 Non-goals, 7 Acceptance criteria (given/when/then, testable), 8 Constraints, risks, open questions (each with an owner). Keep it under 4 pages. Save it as docs/prd/mvp.md.
My idea: [describe it]
Snippet 2 — Clarify pass on an existing PRD.
Read docs/prd/mvp.md. List every sentence a developer or an AI could interpret two ways, every feature not tied to a workflow step, and every acceptance criterion that cannot be tested. Ask me up to 8 questions to resolve them, then rewrite the affected lines. Do not add features.
Snippet 3 — Turn acceptance criteria into checks.
For each acceptance criterion in docs/prd/mvp.md section 7, write one test case (or, if this project has no test framework, a manual check I can perform in under a minute). Put them in docs/prd/acceptance-checks.md. Flag any criterion you could not turn into a check; that criterion needs rewriting.
Snippet 4 — With Blueprint installed.
/prd-builder
An app that lets staff at small clinics post and claim shift swaps, with a manager approving in one tap. No payroll, no native mobile app in v1.
Snippet 5 — Memory-file rule (CLAUDE.md, AGENTS.md, .cursor/rules, Lovable Project Knowledge):
Project rule: docs/prd/mvp.md is the source of truth. Before implementing a feature, quote the PRD line it satisfies. If a request is not covered by the PRD, propose a PRD change first and wait for approval. After any scope change, update the PRD in the same change.
Frequently asked questions
How long should an MVP PRD be?
2–4 pages. Long enough for workflow, scope, non-goals, and acceptance criteria. Short enough that everyone reads it.
Who should write the PRD, the founder or the developer?
The founder or product owner, because it captures business intent. Developers should review it for gaps and feasibility before the build starts.
What's the difference between a PRD and a technical scope?
The PRD defines what and why. The technical scope defines how: architecture, data model, build order, estimates. Write the PRD first. Technical Scope Template.
Can I use AI to write a PRD?
Yes, as long as it asks the hard questions instead of padding the page. The decisions (user, metric, non-goals) still have to come from you. AI is good at structure, completeness, and acceptance criteria.
Is a PRD still needed with agile?
Yes, a lightweight one. Agile changes how often you update it, not whether you need a shared definition of what you're building.
What should I do before writing a PRD?
Make the core product decisions first. MVP Checklist for Founders.
Related
- MVP Checklist for Founders — make the product decisions before you write the spec.
- Technical Scope Template — turn the PRD into architecture, build order, and risks.
- AI PRD Generator — Codalio drafts the PRD from a feature description.
Draft the eight sections from a feature
You still make the decisions: the user, the metric, and the non-goals. Codalio drafts the PRD so you are not starting from a blank page.