You came for a PRD template — the sections, the headings, an outline to paste into a doc and start a product requirements document. It's below; take it, it's a real one. But know what you're getting: a template is a fill-in-the-blanks outline, and the instant you finish filling it in, it begins to drift. A Notion page or a Google Doc has no idea when a goal you wrote stops matching the decision underneath it, so the PRD quietly diverges from what the team is actually building. Draftlize gives you the same nine sections — and makes each one a card an AI agent reads and writes, where everything downstream flags itself stale the moment one decision moves.
This is the whole PRD format. It works in a doc, a wiki, or a markdown file — paste it and fill it in. Use it as-is. The next section is about what changes when each heading stops being prose and becomes a card.
The user pain in one or two sentences — what hurts, for whom, and why it matters now. If you can't name the problem without naming your solution, you don't have a problem statement yet; you have a feature looking for a reason.
What success looks like, stated as outcomes, not features. "Cut time-to-first-draft below five minutes," not "add a templates button." Three at most — a PRD with nine goals has none.
What you are deliberately not doing in this release, written down so it doesn't get re-debated in week three. The most under-used section in any PRD template, and the one that saves the most arguments.
The specific person this is for — role, context, what they're trying to get done. "Solo developers shipping a side project," not "users." Everything downstream, from stories to metrics, anchors to this.
As a [user], I want [capability], so that [outcome]. The bridge from the problem to the requirements — each story is a job the product has to do, in the user's words, not the system's.
The concrete behaviors the product must support, numbered so they're citable. This is the longest section and the one engineering actually builds from. Each requirement should trace back to a story and forward to a metric.
The numbers that tell you the goals were met — activation, retention, the specific funnel step that moves. Decide them before you ship, or you'll rationalize whatever happened into a win after.
The decisions, systems, and other work this PRD assumes are true — pricing, the auth model, an upstream API. In a doc this is a list you'll forget to update. It's the section that decides whether the PRD stays honest.
What you don't know yet, named out loud rather than buried. A PRD that pretends to have every answer is fiction; the open-questions list is where the real work of the next two weeks lives.
That's the template. Below: why filling it in is the moment it starts to drift — and what we do about it.
The nine sections are good — that's roughly the shape every PRD format has converged on. But an outline only captures the product once. It has no idea when a goal stops matching the decision beneath it, because a page of prose can't watch the rest of the project change around it.
You list what the PRD rests on — pricing, the auth model, a decision made last sprint. Then one of those changes, and reconciling the doc is manual archaeology: re-read every requirement to find the ones that assumed the old call. Nobody does it, so the section meant to keep the PRD honest is the first to go stale.
The PRD is most accurate the minute after you finish it, and never that accurate again. By the time engineering is mid-build, a real fraction of it is wrong, and you can't tell which fraction — so the team stops trusting the doc and starts asking in Slack, which is the failure the PRD was supposed to prevent.
In Draftlize the PRD isn't a blank doc — it's a set of typed cards along those exact sections: problem, goals, non-goals, users, stories, requirements, metrics, dependencies, open questions. Structured, addressable by ID, and citable from a spec or a thread instead of buried under a heading three scrolls down.
Because Dependencies is a real link and not a list of nouns, changing a decision turns every card that rested on it stale automatically — the way a build system invalidates everything downstream of a changed file. Change the pricing decision and the requirements and metrics that assumed it light up, instead of silently lying. The promise the template made, the substrate keeps.
Claude Code or Cursor, over MCP, reads every relevant card before it drafts the next requirement and writes new sections back into the same shape. The PRD stops being a document for a reader who skims it once and becomes context that gets read on every turn — pairs naturally with a decision log template for the calls underneath it.
A template tells you what sections to write. It can't tell you when a section stopped matching the decision underneath it.Keep the nine sections. Let the substrate keep them current.
At minimum: problem statement, goals, non-goals, target users, user stories, functional requirements, success metrics, dependencies, and open questions. Those nine sections are the shape most PRD formats have converged on — skip a heading if you don't need it, but answer the underlying question.
A template is the blank outline — the section headings you fill in. An example is a template already filled in for a specific product, so you can see the level of detail expected. Use the template to write; read an example to calibrate.
Yes — an AI writer turns a rough brief into a solid first draft fast. The gap is durability: it drafts the PRD once and has no idea when a decision it assumed later changes. That is the part a template plus an AI writer can't solve, and it's why the sections drift.
A Notion or Docs template is a static outline — the instant you finish filling it in, it starts going stale. Draftlize gives you the same nine sections as typed cards: each is addressable by ID, an AI agent reads and writes them over MCP, and when one decision changes every dependent section auto-flags stale instead of silently lying.
Take the template above, or spin up a project and let the agent draft the product requirements document from a rough brief — then keep every section, and every decision it depends on, current for you.
Start free with $5One click creates a project with these exact sections as typed, linked cards. Answer them with the agent — and when a decision changes later, every dependent section flags stale instead of silently drifting. $5 free credit on signup, no card required.