One-Page PRD
/ Template.
An anti-bloat PRD format. Fits on one screen. Cuts the 12-page Confluence doc no one reads.
PM: ______
Date: ______
Why one page
Long PRDs are read once on the day of kickoff and scrolled past forever. The goal of a PRD is not thoroughness — it’s alignment. The rest is implementation detail that lives in tickets, design files, and engineering notes. If your team needs 12 pages to align, you don’t have a PRD problem; you have an unclear-thinking problem. Force the doc to one page and the unclear thinking has nowhere to hide.
The structure (8 fields)
A worked example
The “Why now?” probe
There are exactly three acceptable answers to Why now? Anything else is a wish, not a priority.
- Customer signal threshold met — you can name the count, the channels, and the time window.
- OKR dependency — the metric you committed to depends on this shipping in this quarter.
- Competitive gap — a named competitor shipped this and you have lost-deal evidence.
If you can’t pick one, the PRD isn’t ready. Send it back to discovery. This is the cheapest filter you have.
Success metrics: two only
One leading, one lagging. Leading metrics move in days, give you fast feedback, and tell you if the mechanism works. Lagging metrics move in weeks or months and tell you if it mattered. If you list five metrics, you have none. The team won’t orient around a list.
- Good: Leading — search-to-action 38% → 55%. Lagging — activation 25% → 32%.
- Bad: “Improve user experience.” Not a metric. “Reduce churn.” Too lagging to act on. “NPS goes up.” Untrackable to the change.
Out of scope is a feature
The trap is leaving this section blank because everything feels in scope. Empty out-of-scope = scope creep guaranteed. Naming what you’re not doing is how you protect the team from the mid-sprint “while we’re in there…” expansion. Write 3–5 things. Make them specific. “Saved searches” beats “advanced features.” This single section will save you a sprint per quarter.
Living PRD vs static PRD
A static PRD is true on the day of kickoff and wrong by week two. A living PRD updates when the inputs change — every signal-threshold change, every dependency change, every kickoff. In practice this means the PRD is connected to the data, not stapled to it. MindBacklog generates living PRDs that auto-update from new signals, so the “evidence” section reflects today’s reality, not last month’s. Whether you use that or not, the rule stands: if the signal count drops by half, your PRD needs a re-read.
The 6 questions to ask before writing
- Hypothesis — what do we believe will happen if we ship this, in one sentence?
- Target user — who specifically — what segment, what job, what trigger?
- Riskiest assumption — what has to be true for this to work? What if it isn’t?
- Evidence source — what signals, calls, or data convinced us?
- Success measure — what does “it worked” look like in numbers, not vibes?
- Kill criteria — under what observed outcome do we stop or roll back?
A second example (smaller scope)
Same structure, different scope. The format scales down to a 2-week fix and up to a 2-quarter platform play. If a feature can’t fit this template, the feature isn’t scoped — not the template’s fault.
The PRD anti-checklist (5 things NOT to put in)
- Implementation details. Endpoints, schema choices, library picks. Live in tickets and design docs. Specifying them in the PRD locks engineering into your guess.
- Mock screenshots that lock design. A wireframe to communicate intent is fine; a polished mock will be argued about for a week.
- Marketing copy. “Reimagining how teams collaborate.” — not what the engineer needs. PRD is a build doc, not a launch doc.
- Every edge case. The 12-page versions are 90% edge cases. Capture known critical edge cases; let the rest surface in QA and bug triage.
- Multiple priorities. One PRD = one feature. If you’re writing “and also…”, you have two PRDs.