One-pager

Artifact

A single page that compresses the background and the proposal into one document and asks the reader to make a decision.

Why it exists

Proposing something new happens at every company. The hard part was never the idea but where to put it, and there were usually two options. Neither worked well.

One was to say it out loud. You explain it for five minutes in a meeting and watch the room. The people present follow it roughly, but nothing is written down, so two weeks later the same conversation starts over. In between, five attendees remember five slightly different things. One remembers a decision to do it next quarter. Another remembers a decision to look into it further. The next meeting opens with no agreement on whether a decision happened at all.

The other was to write big from the start. A serious proposal needs a serious document, so somebody produces twenty pages covering screen layouts and error states. It takes four days to write, and the readers get through the first two pages. Worse, nobody has decided whether to do this at all, yet the entire plan for how to build it is already on paper. If the answer turns out to be no, four days vanish, and the person who spent them starts pushing back against the decision. Sunk time bends judgment.

Meetings in that era had a shape. The proposer put the document on screen and read it top to bottom for thirty minutes while everyone else tried to absorb material they were seeing for the first time, which left no room to form a question. Thirty minutes later there were five minutes left, and what came out of those five minutes was usually "sounds good, let's take another look." The following week the same thirty minutes ran again. A room that existed to decide spent all of its time transferring information.

A one-pager is the format built to block both failures at once. It leaves a record where talking leaves none, and it arrives before the twenty-page document rather than after. The only mechanism is the length limit. Cap it at one page and the writer has to decide what to cut before writing anything, while the reader gets through it alone in five minutes before the meeting. The meeting then opens with questions and a decision instead of an explanation.

Its position among product documents follows from that. A specification, written down to the level of screens and behavior an engineer can build from, and a user story, which slices a requirement into one sentence from the user's point of view, both come after the decision to build. A one-pager works in front of that, while building or not building is still open. That is also why it stays inside the company instead of going out to customers.

How this field breaks down

Two terms sit under the one-pager. One is a different format used in the same seat, and one is the way of thinking that produced that format.

Before the branches, the shape of the document itself is worth knowing. The single page in the name is a literal limit, not a figure of speech. One sheet of paper comes to roughly 700 to 900 words. Shrinking the type to eight points or killing the margins to force more in does not count as keeping the limit. If reading takes more than five minutes, the device the single page was there to provide has already failed.

What goes on the page varies in naming from company to company, but it groups into six items.

  1. Background — what is happening right now. Opening with a number is safe. Free-plan users grew by twelve thousand last quarter and 1.8 percent of them converted to paid. Filling this slot with a company introduction or a market overview burns a quarter of the page on things the reader already knows.
  2. Problem — what about that situation is wrong, and who it lands on. A problem reads better as something a person runs into. "Conversion is low" gives the reader nothing; "teams on the free plan stall at the payment screen once they pass ten members, and half of them never come back" produces a picture.
  3. Goal — which number moves, and to what, if this goes well. Attach a figure and a date. Take 1.8 percent to 3 percent within two quarters. Without this line there is no basis six months later for judging whether it worked.
  4. Proposal — what you are asking to do, in one paragraph. This is not the place to descend into screen design. Give teams that stall at the payment screen one ten-day extension: enough for the reader to know what they are agreeing to or objecting to, and no further.
  5. Alternatives considered — the options you weighed and did not pick, with the reason you dropped each one. Two or three lines is enough. Write that cutting the price was dropped because it would also reshape renewal amounts for existing customers, and the reader will not raise it again. Leave this slot empty and you are asking for a yes or no on a single option, which is not a comparison.
  6. Ask — what you want from the reader. Approval to proceed, one engineer for two weeks, objections by next Wednesday: put it in a sentence. This line is what separates a one-pager from a status report.

The two that go missing most often are 5 and 6. Without them, what remains is a description of a situation, and the reader finishes the page without knowing what they were asked to do. Many companies add a risk line as well — what breaks if the proposal is wrong, and how it gets undone.

Who writes it and who reads it is part of the format too. Anyone making a proposal writes one. Product managers write the most of them, but a designer bringing a usability problem or an engineer proposing a structural change uses the same shape. Readers split in two: the person who will make the decision, and the teams the decision lands on. Naming both at the top of the page settles the length and the vocabulary automatically. A page the chief executive reads has to unpack its technical terms; a page the engineering team reads has to explain the revenue structure in a line.

How it gets read is settled as well. Many companies spend the first five minutes of the meeting reading it together and talk only after that. Send it ahead and half the room arrives without having read it, which puts the meeting back to opening with an explanation.

The two sub-terms push this format in different directions.

Under formats there is the PR/FAQ. Same seat, different shape: instead of six items, you write the launch press release for something that does not exist yet and answer the questions customers and colleagues are expected to ask. Because the background and the problem get written in the words a customer would hear rather than internal ones, a dull result shows up immediately in the one sentence a customer would receive. It is harder to write than a one-pager and takes longer.

Under methods there is working backwards. Not a document format but a reversal of order: rather than starting from what can be built, you fix the final shape the customer will see and fill in what is needed from there. The PR/FAQ is that method frozen into a document, which is why the two travel together.

The three form a sequence. The one-pager is the lightest. When the shape a customer would see is still vague, the PR/FAQ raises it a level. Once there is a judgment about what to build, a PRD takes over. Decisions made along the way get recorded separately in a decision record, and anything approved for building enters the product backlog as a candidate. Getting a one-pager through and deciding when the work actually happens are separate events; the second belongs to prioritization.

How it sounds at work

"Can you pull this into a one-pager and share it before Thursday?"

There isn't enough here to judge, so cut it down to what the decision needs.

"I read the one-pager, but the alternatives section is empty. I can't see why it has to be this approach."

With one option on the table you can only ask for a yes or a no, and that isn't a comparison.

"This isn't a one-pager, it's a status update. What are you asking me to do?"

The ask is missing, so the document can't produce a decision.

At Pagedeck the document comes up most often right before quarterly planning. Last quarter Ravi brought a proposal to lower the free plan's member cap from ten to five, on a single page. The background line held the number that only 8 percent of free teams ever pass ten members. The problem line held the observation that those 8 percent produce most of the paid conversions. The ask line held a sentence requesting one quarter to run it as an experiment.

The meeting opened with five minutes of reading together. Grace asked about the alternatives section rather than the proposal: why was the option of holding the price and splitting on features dropped? Ravi answered in two lines and the exchange was over in three minutes. Theo read the risk line and asked what happens to teams already using ten seats. That wasn't in the document, so a condition got attached on the spot to leave existing teams alone. Sofia added that two prospects in active deals were evaluating on free seat counts, and the experiment was narrowed to newly created teams.

A meeting booked for forty-five minutes ended in twenty, and the outcome went into the decision record in three lines. Nobody opened the one-pager again. The lifespan of this document ends the moment the decision lands. What comes after is the PRD's job.

What people get wrong

The most common reading is that a single page means a quick, rough document. Less text looks like less work, and the typing alone really does take thirty minutes. But one page means throw a lot away, not write a little. Everything you know comes to four pages, and the time goes into picking out the three pages that would not change the reader's judgment. To know what to cut you have to know what decides the question, and if you don't, nothing can be cut. Skip that step and you get a thin page whose gaps get filled in verbally during the meeting. The record disappears again, and you are back where you were before writing anything.

Reading it as a procedure for collecting an approval stamp is the other common mistake. It looks that way because a document goes up to a decision-maker and comes back approved, and because objections push the schedule, so the writer starts wanting to write in a way that draws none. What a one-pager is for is drawing those objections early. An objection before the work starts costs one paragraph; an objection after the work is built costs two months. Once this misreading sets in, the alternatives section starts getting filled as a formality — two options nobody ever considered, each with a one-line reason for dropping it. Readers catch that quickly. From the next one-pager on, nobody reads ahead and everybody opens the page for the first time in the room, and the habit of reading in advance falls apart.

Easily confused with

TermWhat it recordsHow it differs
PRDRequirements and completion criteria for something already approvedWritten after the decision to build. A one-pager comes before it to settle whether to build at all, is bound to a single page, and ends with an ask

Where to go next

  • Product

    see where this document sits in the wider product landscape

  • PR/FAQ

    compare it with the other format used in the same seat

Sub-terms

Last updated 2026-09-16