Three templates, the prompts that fill them, and a section near the end arguing that you might not want a PRD at all. Take the templates and skip the rest if that is all you came for; they are the useful part.
What goes in a modern PRD
A PRD is not a requirements document thrown over a wall at engineers. That version died for good reasons. The modern one is a collaborative planning artifact, and the sections that earn their place are:
- Context. The user, the problem, and what their workflow looks like today without you.
- Goals and non-goals. What this release delivers, and what it explicitly does not.
- Target users. Named personas with pains, goals, and quotes.
- User stories. INVEST format, tied to personas and features.
- Acceptance criteria. Given/When/Then per story, categorised by happy path, edge case, and failure state.
- Non-functional requirements. Performance, security, compliance, accessibility, scale.
- Success metrics. The measurable outcomes that confirm this shipped correctly.
- Dependencies and open questions. What this relies on, and what is still undecided.
Older templates also bundled UI mocks, technical architecture, and test plans. Those are better off in sibling artifacts now, a page inventory and a schema and a scenario set, because keeping them separate means each can be updated without republishing the whole document. That separation is most of what has changed about PRDs in the last decade.
Why one big PRD prompt disappoints
Paste your idea into ChatGPT, ask for a PRD, and you get a plausible 2,000-word document. Three problems appear the moment you try to use it.
Personas and stories drift apart. The persona section names "Sarah the marketer." The stories section says "the user." An engineer who wants to filter stories by persona cannot, because the link was never made.
Non-functional requirements go missing. The model gravitates to features and skips security, rate limiting, and accessibility unless you demand them by name. These are also the requirements whose absence is least visible on a read-through.
Nothing persists. Regenerate tomorrow and you get different sections. Reconciliation is manual, so in practice it does not happen.
These are structural limits of asking for everything at once, not prompt-quality problems. The fix is to run the work in stages with each output feeding the next, which is what the seven-stage pipeline covers.
Template 1: lean PRD
Use when you are a solo PM, indie hacker, or technical founder, and the audience is your future self or a contractor you are about to brief.
# [Product Name]: Lean PRD
## One-line description
[Who is this for and what does it do, in one sentence?]
## Problem
[The user's current pain in 2-3 sentences. Include one concrete scenario.]
## Goal
[The outcome this release delivers. Measurable.]
## Non-goals
- [Explicitly NOT in scope]
- [Explicitly NOT in scope]
## Target user
- Role: [persona name, role]
- Context: [current tools, team size]
- Pain: [the specific frustration this addresses]
## Must-have features (MoSCoW: Must)
1. [Feature]: [1-line rationale]
2. [Feature]: [1-line rationale]
3. [Feature]: [1-line rationale]
## Core user stories (INVEST)
- As a [persona], I want [action], so that [outcome].
(AC: happy path, edge case, failure state)
## Success metric
- [Measurable target with a date.]
## Open questions
- [ ] [Question] (owner, due date)
The prompt:
Fill in this PRD template for the following product idea:
<PASTE IDEA>
Rules:
- Keep it to one page. No filler.
- Maximum 5 Must-have features.
- Maximum 8 INVEST stories, each tied to a named persona.
- Every acceptance criterion in Given/When/Then format.
- Include explicit non-goals. If you cannot think of two, ask me
rather than inventing them.
That last clause is worth keeping in all three prompts. Non-goals are the section models are worst at, because inventing a plausible non-goal requires knowing what you were tempted to build, and it has no way to know that.
Template 2: standard PRD
Use when you have a team of two to ten and the PRD is the handoff between product and engineering.
# [Product Name]: PRD v[x.y]
## Executive summary
[150 words: problem, solution, target user, success metric, timeline.]
## Context
### Problem
[3-5 sentences. Include a day-in-the-life scenario showing current pain.]
### Current state
[What users do today without this. Name specific tools and friction points.]
### Opportunity
[Why now? What changed in the market, tech, or user behaviour?]
## Goals
### In scope
- [Primary outcome]
- [Secondary outcome]
### Non-goals
- [Explicitly NOT in scope, with rationale]
## Personas
### [Persona Name]
- Role: [job title, company size]
- Daily tools: [list]
- Goals: [top 3]
- Pains: [top 3]
- Quote: "[something they would actually say]"
- Why they matter: [1 line]
[Repeat for 2-3 personas]
## Features (prioritized)
| Feature | Description | Persona | MoSCoW | T-shirt |
|---|---|---|---|---|
| [Name] | [1 line] | [name] | Must | M |
## User stories with acceptance criteria
### Feature: [Name]
**Story 1:** As [persona], I want [action], so that [outcome].
- Happy path: Given [...] When [...] Then [...]
- Edge case: Given [...] When [...] Then [...]
- Failure state: Given [...] When [...] Then [...]
## Non-functional requirements
### Performance
- [Target latency, throughput, availability]
### Security
- [Auth flow, data protection, rate limits]
### Compliance
- [GDPR / HIPAA / SOC2 considerations, if any]
### Accessibility
- [WCAG level, specific requirements]
## Data model
[Reference to the schema doc, or an inline summary]
## Page and component inventory
[Reference to the UX doc, or an inline page list]
## Success metrics
- [Primary metric with target and measurement window]
- [Secondary metrics]
## Dependencies
- [External service / team / decision]
## Open questions
- [ ] [Question] (@owner, due [date])
## Release plan
- [Phase 1: dates + scope]
- [Phase 2: dates + scope]
## Version history
- v1.0 / [date] / [author] / initial draft
The prompt:
Generate a full standard PRD for this product using this template:
<PASTE TEMPLATE ABOVE>
Product idea:
<PASTE IDEA>
Rules:
- Every story references a named persona and a named feature.
- Every acceptance criterion is Gherkin, tagged happyPath /
edgeCase / failureState.
- Non-functional requirements: at least 2 specific, measurable
items per subsection. Never leave one empty.
- If you lack the context to fill a subsection, write
[OPEN: <question>] rather than inventing content.
Free resource
Free: the Notion spec kit + printable checklist AI coding tools can actually follow.
Template 3: agency PRD
Use when the PRD doubles as a client proposal. Everything in template 2, plus a cost estimate broken out by MoSCoW priority, a risk register with the top five risks scored by likelihood and impact, expanded assumptions, persona quotes pulled out as design-ready blocks, and a competitive landscape appendix.
Worth saying plainly: this is the variant AI generators handle worst. The cost estimate, the risk register, and the competitive positioning all need real inputs, and a model asked for them will produce confident generic content that reads as researched. Generate the structural sections with AI, then do these three with actual client conversations and an actual competitive scan.
When a PRD is the wrong unit of work
A PRD is a document, and documents have one specific failure mode: they go stale the moment a feature, persona, or constraint changes.
For a product that ships once and never evolves, that is fine. For anything that iterates, which is every SaaS product, the PRD becomes outdated faster than anyone updates it. Usually around sprint two, and usually nobody announces it. It just quietly stops being true, and people stop reading it, and then it is a 2,000-word artifact that exists to make the project feel organised.
The alternative is a linked set of artifacts. Personas, features, stories, criteria, schema, and pages stored separately and referencing each other by identity rather than by prose. When a persona's goal changes, the stories depending on it get flagged. When a criterion is updated, the scenario checking it updates too.
I would not claim this is universally better. A single document is easier to email, easier to read end to end, and easier to get a stakeholder to actually look at, and those are real advantages. The linked model wins specifically when the spec has to survive contact with an evolving product, which is most of the time but not all of it. If you are writing a PRD to get a decision made in a meeting next week, write the document.
VibeMap is the linked-artifact version, if that is the trade-off you want.
The checklist before you share it
Run any AI-generated PRD through this before it reaches another human.
- Does every story name a specific persona, not "the user"? If not, the story has no owner.
- Does every feature have at least one Must-have story? If not, the feature is not essential. Downgrade it or cut it.
- Does every acceptance criterion include a failure state? Models skip these by default, so their absence means nobody checked.
- Are non-functional requirements specific and measurable? "Must be fast" is not a requirement. "P95 latency under 200ms at 1,000 rps" is.
- Are open questions marked explicitly? A PRD that reads as if everything is decided is a PRD where the model filled the gaps for you.
- Are success metrics measurable and dated? "Improve engagement" is not a metric. "15% increase in weekly active users within 60 days of launch" is.
Point 5 is the one I would not skip. A generated document with no open questions is not a complete document, it is a document whose uncertainty got laundered into confident prose.
Related reading
- How to generate an app spec from a prompt, the staged pipeline that avoids the single-prompt problems above.
- Writing user stories with INVEST, for the stories section.
- AI acceptance criteria, for the criteria section.
- AI persona generator for product teams, for the personas section.
- VibeMap vs ChatGPT for product planning, an honest comparison.
If you want to fill the stories section without starting from a blank page, the User Story Generator produces INVEST-format stories with paired acceptance criteria. Free, no signup.
Sources and further reading
- Marty Cagan, INSPIRED: modern PRD philosophy and scope.
- Atlassian, How to write a PRD: industry-standard template reference.
- Mike Cohn, User Stories Applied: the INVEST criteria.
- Agile Business Consortium, MoSCoW Prioritisation: the canonical definition.
