The One-Pager
The page that gets a decision made by people who will read one page: the decision you need at the top, the options and their costs next, and everything else below the fold or gone.
The ask, the obvious response, and how it goes wrong
Every lesson starts where the work starts: someone asked for something, and the first response that comes to mind has a problem.
If the reader stops after the first paragraph, do they know what you need from them?
The PM: "Finance and the head of product need to decide on split payments before the Q4 freeze. Can you write something up for Thursday's meeting?"
Write a thorough document: background on how split payments work, the history of customer requests, the technical design, the three providers, the risks. Put the recommendation at the end, where it follows naturally from the analysis.
The head of product reads the first paragraph on their phone between meetings. It is about the history of payment requests. They arrive on Thursday not knowing a decision is being asked of them.
- The head of product reads the first paragraph on their phone between meetings. It is about the history of payment requests. They arrive on Thursday not knowing a decision is being asked of them.
- Finance reads it properly, gets to page four, and finds the recommendation involves a new provider fee. Their first question in the meeting is about the fee, and the meeting spends forty minutes on something the document answered on page five.
- The document is built as an argument, with the conclusion last. Decision-makers do not read arguments; they read conclusions and check the argument only if they doubt it.
- The thoroughness itself becomes the problem: nobody can tell which of the eleven risks actually matter, so the meeting discusses all of them and decides nothing.
What is really going on
- A decision-maker's attention is the scarcest input in the process. They will give you one page, often less, and they will give it in the order you wrote it. Whatever is first is what they know.
- The one-pager is a request, not a report. Its job is to get a specific decision made by specific people by a specific date. Everything that does not serve that job is an appendix or is deleted.
- Putting the decision at the top inverts how engineers are trained to write: context, then analysis, then conclusion. The one-pager goes conclusion, then just enough to trust it, then the costs, then the rest.
- After the meeting, the one-pager becomes raw material for the record. The proposal argued for an option; the record says which option won and why the others lost (Decision Records).
Written for the person who reads one page
The reader of a one-pager is not the engineer next to you. It is the head of product between two meetings, or finance looking for the number that affects them. They will read the top of the page, possibly only the top, and decide how much more to read based on what they find there.
That reader is not lazy. They are making twenty decisions this week and yours is one of them. The one-pager is how you respect their attention and still get the decision you need.
Over the last year, customers have increasingly asked about split payments. This document reviews the history of these requests, evaluates three providers, and proposes a technical approach.
Decision needed from finance and the head of product by Thursday: offer split payments before the Q4 freeze, or after? I recommend after, with a waiting-list page now, because shipping before the freeze leaves two weeks of testing on the busiest checkout path of the year.
After the second version, a reader who stops knows the question, the deadline, the recommendation and the main reason. After the first, they know a document exists.
The skeleton
The structure is fixed so you can spend your effort on the content. Every heading answers a question the decider will otherwise ask in the meeting.
1# Split payments: before or after the Q4 freeze?2 3**Decision needed:** finance + head of product, by Thursday 14:004**Recommendation:** after the freeze, with a waiting-list page now.5**Main cost of that:** we miss Q4 for customers who wanted to split6large baskets; the waiting list tells us how many there are.7 8## Why now9Provider contract renews in November; the freeze starts in three weeks.10 11## Options12| Option | What we get | What it costs |13|---|---|---|14| A. Build before freeze | Split payments for Q4 | 3 weeks; 2 weeks of testing on peak path; new provider fee per order |15| B. Provider-hosted page | Faster, 1 week | Customers leave our checkout; design and support lose control of the page |16| C. After freeze + waiting list (recommended) | Demand data before we build | Q4 customers do without; 1 day for the page |17 18## If we do nothing19Requests keep arriving through support with no answer to give.20 21## How we will know22Waiting-list sign-ups by January; support tickets tagged "split payment".23 24## Open questions25- Does finance accept the provider fee in A/B at our order values?26 27Appendix: provider comparison, technical design (linked)The page answers "what do you need from me?" before "what is split payment?". The table uses the deciders' units — weeks, fees, support load — not endpoints and services.
Asking for the read
The message that carries the one-pager matters almost as much as the page. It should make the ask impossible to miss even for someone who never opens the attachment.
You have finished the one-pager on Tuesday. The meeting is Thursday. Finance and the head of product are both on the invite.
"Hi all, attaching the split payments doc for Thursday. Let me know if you have any questions!"
"For Thursday: we need a yes or no on split payments before the Q4 freeze. I recommend waiting until after, with a waiting-list page now — the main cost is that Q4 customers go without. Finance, the open question for you is whether the provider fee is acceptable at our order values; it is the one thing I cannot answer. The top half of the page is enough to decide."
What happens to it afterwards
A one-pager has a short life. It exists to get the decision made. Once it is made, the useful parts become the decision record: which option won, why the others lost, and what would reopen it. The rest can be archived.
If the meeting ends without a decision, the one-pager has failed at its only job, and the most useful thing is to say why in writing: "We did not decide because the fee question is open; finance will answer by Monday and I will re-send." That keeps the decision alive instead of letting it drift into next quarter (Decision Records).
How to do it
Most important first.
- First line: the decision you need, from whom, by when. "Decision needed from finance and the head of product by Thursday: do we offer split payments before the Q4 freeze?"
- Second block: your recommendation in one sentence, with its main cost named (Naming the Trade-off).
- Then the options, as a small table: what each gets us, what each costs, in the reader's units — money, weeks, support load, risk (Options, Not Answers).
- Then what happens if we do not decide, and how we will know it worked (Picking a Metric That Moves When the Product Gets Better).
- Everything else — technical design, provider comparison detail, history — goes in an appendix or a linked doc. If you are unsure whether something belongs on the page, it does not.
- Send it at least a day before the meeting, and say in the message what you need: "Please read the top half before Thursday; the decision is in the first line."
How to explain the decision
The sentences, the order, and what to lead with — for someone who did not make the call.
- When sending: "The decision we need is in the first line. If you read nothing else, read the top half — it has the recommendation and what it costs."
- Opening the meeting: "We are here to decide one thing: split payments before or after the freeze. I recommend after. The document has three options; I would like to spend most of our time on the cost of option B."
- When someone drifts into the appendix: "That is in the appendix and I am happy to go through it — does it change which option you would pick? If not, can we decide first?"
- Closing: "So the decision is option C, after the freeze, with a waiting list page now. I will write it up as a decision record today and post the link here."
- "This is too important for one page." Then it is too important to risk the decider not reading page four. Put the detail in the appendix; keep the decision where they will see it.
- "I do not want to look like I have already decided." You have a recommendation; hiding it wastes the meeting. Say it is a recommendation and show the options it beat.
What can go wrong
- The one-pager that is four pages in a small font. The constraint is the point; breaking it means you have not yet decided what matters.
- The decision at the top is vague: "We should discuss split payments." That is an agenda item, not a decision. The reader cannot say yes or no to it.
- Options that are really one option and two strawmen, which experienced readers spot immediately and then distrust the whole page.
- Writing it for the most technical reader in the room, so the non-technical decider cannot evaluate the costs and defers to whoever sounds most confident.
- "One page means less rigour." The rigour is in the appendix and in your head. The page is the part of the rigour a decider needs.
- "The recommendation should come last so readers are not biased." Readers are going to look for it anyway. Putting it first lets them read the rest as evidence instead of hunting.
- "A one-pager replaces the design doc." It does not; it is what gets the design doc's conclusion decided. Engineers still need the design (Writing for Stakeholders).
Knowing whether it worked
- The meeting starts with a question about your recommendation, not with "so what are we deciding?"
- Decisions get made in the meeting the one-pager was written for, not in the follow-up meeting after it.
- People forward your one-pager to others without adding an explanation of what it is about.
- The head of product can repeat the decision and its main cost afterwards without looking at the document.
- In a small company the decider is often in the same chat and a one-pager is a long message. As the company grows the decider is further away, busier, and deciding more things; the page becomes the only way your reasoning reaches them intact.
- At 10x decisions per week, the ones that get made are the ones that are easy to make. A clear one-pager is a competitive advantage for your proposal inside your own company.
- Nothing about the format changes with scale, and that is the point: one page is one page whether the decision is a checkout button or a provider migration.
- It is harder to write than a long document. Cutting to one page means deciding what does not matter, which is the actual work.
- Leading with a recommendation makes it easier to reject. A buried recommendation is harder to argue with because it is harder to find — which is exactly why it rarely gets adopted.
- Some nuance is lost. A reader who only reads the top half will miss the caveat on page two; you have to decide which caveats are important enough to earn a place at the top.
Where this applies
Product advice is context-sensitive. These labels say what each claim is specific to, and where a different stage, team or product would differ.
- GENERALAnywhere a decision needs someone who will not read a long document. It flips in cultures built on long-form memos read in silence at the start of the meeting, where six pages are expected — the decision still goes first.
- ROLE-SPECIFICJunior engineers write these for their lead or PM, who may carry them further; senior engineers are expected to write them directly for the decision-maker, including non-technical ones.