One-Pager or PRD: Which Does This Decision Need?

These are not competing formats and choosing between them as a house style is the mistake. They answer different questions, in sequence, and most work that matters needs both.

The two questions

One-pager: should we do this? The reader is deciding whether to spend the team's time. They want the problem, the evidence, the cost, and a specific ask.

PRD: what exactly gets built? The decision is made. The reader is going to implement it, and they want the states, the boundaries and the conditions that decide whether it is correct.

Side by side

	One-pager	PRD
Reader	Whoever can approve it	Whoever builds it
Question	Is this worth doing?	What must be true for this to be right?
Length	One page	As long as the decisions require
Must contain	Problem, evidence, ask, cost, exclusions	States, limits, criteria, edge cases
Done when	A decision is made	An engineer could build it without you
Failure	It gets discussed instead of decided	It gets built differently than intended

The test

One question resolves almost every case:

Could this still be rejected?

If somebody could reasonably say no and that would be the end of it, you are writing a one-pager. Your job is to make saying yes or no possible.

If the decision is made and no is not on the table, you are writing a PRD. Your job is to remove every remaining decision from the sprint.

Two corollaries fall out of that, and both are diagnostic:

A one-pager nobody could reject is a status update. If there is no version of the answer that is "no," you are not asking for a decision, you are informing people. That is a fine thing to do and it should not cost you a page of argument.

A PRD whose premise could still be rejected is premature. Specifying acceptance criteria for something that might not happen is the expensive way to discover it is not happening.

What each one is bad at

A one-pager is bad at being built from. It has no states, no error handling, no limits — by design, because those would bury the ask. Hand it to an engineer and everything it omits gets decided during implementation.

A PRD is bad at getting a decision. Detail reads as commitment. A reader who opens a twelve-page spec assumes the argument is settled, because nobody writes twelve pages about something they are still deciding. The ask disappears into the structure, and the response you get is feedback on your edge cases rather than a yes or a no.

This is why the failure modes are asymmetric. Using a PRD to ask for a decision gets you a slow maybe. Using a one-pager as a spec gets you a shipped product nobody specified.

The sequence, and what carries over

The normal path is one-pager, decision, PRD. Three things should survive that transition:

The problem statement, close to verbatim. If it changes between the two documents, one of them was wrong, and it is worth knowing which.

The success metric and its baseline. The number you promised when asking for approval is the number you are accountable to. Re-deriving it in the PRD is how targets quietly drift toward what turned out to be achievable.

The exclusions. This is the one teams lose, and the loss is expensive. The out-of-scope list in a one-pager was agreed at the exact moment the decision was made — when everyone was paying attention and the trade was explicit. Rebuilding that agreement three weeks later, from memory, during a sprint, is not the same thing.

Everything else gets rebuilt. The proposal in a one-pager is deliberately three sentences; it is a sketch to support a decision, not a draft of the requirements.

The failure worth naming

A team writes a good one-pager. It gets approved. Everyone is pleased with how lightweight the process was. Then the work starts from that document.

What happens next is predictable: the limit, the empty state, the permission rule, the failure behaviour — none of which the one-pager contained — get decided in the sprint by whoever reaches them first, under time pressure, with no review. The team experiences this as normal friction rather than as a missing document, because nothing announces itself as absent.

The tell is the question volume. If the same five kinds of question arrive every time a one-pager goes to build, you are not running a lightweight process. You are running the decisions verbally and calling it lean.

When you can skip one

Skip the one-pager when the decision is already made — an obvious fix, a committed roadmap item, a contractual obligation. Asking for approval you already have is theatre.

Skip the PRD when there are no decisions in the work. A chore, a bug, a copy change. Here the spec is the wrong document and a ticket carries it.

Skip both rarely, and only when the work is small and reversible. "Small" is doing more work in that sentence than people think — small in decisions, not in effort.

If you are starting from scratch, the One-Pager template and the Standard PRD template are built to hand off to each other: the one-pager's problem, metric and exclusions map onto the sections that open the spec.

FAQ

What is the difference? A one-pager gets a decision; a PRD makes a build correct. Sequential, not competing.

Which do I write? Ask whether it could still be rejected. If yes, one-pager. If no, PRD.

What carries over? Problem, metric with baseline, and the exclusions — which are the ones most often lost.

Can the one-pager be the spec? No. It contains no states or criteria by design, so all of those get decided mid-sprint instead.