One-Pager Template

A one-pager is the document you write before the PRD, when the open question is still whether to do the thing at all. Its job is not to describe a feature. Its job is to get a decision out of someone who has eleven other things competing for the same resource.

That makes brevity a feature rather than a courtesy. A reader who has to hunt for the ask will schedule a meeting instead of answering, and the meeting is exactly what the document was supposed to prevent.

When you need one

Write a one-pager when the work is not yet approved and the decision-maker is not in the room every day. It is the right artifact for a new initiative, an unplanned request that arrived mid-quarter, a bet that needs headcount, or anything where the honest first question is should we rather than what exactly.

Skip it when the decision is already made. A one-pager for approved work delays the PRD without adding information. Skip it too when the answer depends on detail a page cannot hold — a migration with fifteen dependencies is not a one-pager problem, it is a planning problem wearing one.

If you get the yes, the Standard PRD template picks up where this leaves off.

The template

# [Initiative name]
Owner: [name] · Date: [date] · Decision needed by: [date]

## The ask
[One sentence naming the decision. "Approve two engineers for six weeks to
build X." Not "align on direction."]

## Problem
[Who is hurting, how much, how often. One piece of evidence with a source —
a number, a quote, a support volume. Not "users find this confusing."]

## Why now
[What changed. A deadline, a competitor move, a cost that compounds, a
window that closes. If nothing changed, say so — "no external forcing
function, this is a compounding cost" is an honest answer.]

## Proposal
[What we would do, in three sentences. Enough shape that a reader can
picture it; not so much that this becomes a spec.]

## Explicitly not doing
[Two or three things a reader might assume are included. This section
prevents the scope argument that otherwise happens after approval.]

## How we will know it worked
[One primary metric, with its baseline and the target. If you cannot state
a baseline, say that you will establish one first.]

## Cost and risk
[Rough size — people, weeks, money. The one risk most likely to sink it,
and what you would do about it.]

## Alternatives considered
[What else you looked at and why you set it aside. Including "do nothing".]

Section by section

The ask

Put it first. Every other section exists to support this one, and a reader who stops after two lines should still know what you want.

Problem

One page gives you roughly three sentences here, which is enough for a real problem and not enough for a vague one. That constraint is doing useful work — a problem you cannot state in three sentences is usually a problem you have not finished diagnosing.

Why now

The most-skipped section and the one that most often decides the outcome. A reader evaluating five proposals is really asking which one cannot wait, and a document with no answer to that question loses to one that has it.

Explicitly not doing

The section people cut for space, and the one that saves the most time later. Approval is granted against an imagined scope, and if you do not draw the boundary the reader will draw a bigger one.

How we will know it worked

Alternatives considered

Worked example

A weak ask and a strong one, same initiative:

Weak. We would like to explore improvements to the invitation flow to better serve growing teams and reduce friction in onboarding.

Nothing to approve. No resource named, no date, no decision.

Strong. Approve one engineer for three weeks to rebuild team invitations. 38% of workspaces that invite a second member never complete it, and support handles ~20 tickets a month about expired links. Decision needed by 22 Aug so this lands before the enterprise pilot.

The second version can be answered in a word. It names the resource, the evidence, the date, and why the date exists.

Common mistakes

Writing a PRD and calling it a one-pager. If the document specifies acceptance criteria and edge cases, the decision was already made and you should be writing the spec instead.

Burying the ask. A reader's attention is highest in the first three lines and falls off a cliff. Spending that budget on background is the most common way a good case loses.

Two pages. The constraint is the whole point. Cutting to one page forces you to decide what actually matters, which is the same work the reader would otherwise have to do for you.

No baseline. A target without a current number is not a measure, it is a wish, and a reviewer who notices will discount everything else in the document by the same amount.

Skipping "why now". A proposal with no forcing function is a proposal that can be deferred indefinitely — and it will be.