One-Pager

A single-page document that makes one argument or presents one situation. The page constraint is the discipline - everything that does not fit does not belong.

One-Pager

The one-pager is a format defined entirely by its constraint: one page. That constraint is not aesthetic; it is functional. A one-pager forces the writer to identify the single most important thing they are trying to communicate and cut everything else. The reader - typically a decision-maker or stakeholder with limited time - gets the full picture without needing to extract it from a longer document. The discipline of fitting one page is the work of writing the one-pager; if the content does not fit, the problem is the content, not the page.

One-pagers are used for briefings, proposals, and status updates. In each case, the format signals: here is the situation, here is what matters, here is what I am asking for or recommending. A briefing one-pager gives a decision-maker the context to engage in a meeting. A proposal one-pager makes an argument for a course of action. A status one-pager answers “where are we?” with enough detail to act but no more. The difference between these is the argument structure, not the format.

The failure mode of the one-pager is using the page constraint as a reason to compress rather than to cut. Dense text, small fonts, and packed bullet lists that technically fit on one page have violated the spirit of the format. If the content cannot be written clearly in the white space a readable page affords, there is too much content. The one-pager is a forcing function for clarity, not a target for density.

Canonical template

[Title - the argument or situation in one line]

## Situation / Background
[2-4 sentences establishing context - what the reader needs to understand the rest]

## The Point
[The central argument, recommendation, or finding - 2-5 bullet points or 2-3 sentences]

## Why It Matters / Implications
[1-3 bullet points: consequences, stakes, or reasons this warrants attention]

## Ask / Recommendation / Next Steps
[What you are requesting, recommending, or proposing - specific and actionable]

[Optional: one line of supporting data, contact, or link for follow-up]

When to use

The one-pager belongs in the hands of decision-makers and stakeholders who need the full picture without the full document. Use it to brief an executive before a meeting, to make a proposal that a full document would not earn, to update a stakeholder who needs the situation without the detail, or to distill a longer analysis into something that can circulate on its own.

When not to use

The one-pager is the wrong format when the reader genuinely needs more detail to make a sound decision - when the full context is not optional. It is also wrong for product requirements that govern engineering work, technical decisions requiring the precision of an ADR, reference material people return to repeatedly, or any document where completeness or auditability matters more than brevity.

Pairs well with

executive, product-thinker, executive-summary, candid, matter-of-fact

Often confused with

prd: A PRD defines product requirements with enough precision to govern engineering work - it is complete by design and may span many pages. A one-pager makes a single argument or presents a single situation on a single page - it is a decision-support tool, not a requirements document.

Instruction

Write as a one-pager. The entire document must fit on one printed page. Lead with a title
that states the argument or situation in one line. Use short sections: situation, central
point, implications, and ask or recommendation. Write for a decision-maker who has limited
time - every sentence must earn its place. Cut context that the reader can infer. Cut
supporting detail that does not change the conclusion. End with a specific ask or recommendation,
not an open-ended invitation to discuss.

Template

See the One-Pager template.

Related

Pairs well with

Executive, Product Thinker, Executive Summary, Candid, Matter of Fact

Avoid with

Devotional Reflection, Pastoral, Reverent, Playful

Often confused with

Product Requirements Document

Examples

Should we adopt async-first standups?

Proposal: Async-First Standup Trial

Author: Maya Chen, EM Platform | For: Priya Raman, Head of Engineering | Date: 2026-05-14 | Decision needed by: 2026-05-16

The situation

Platform is 11 engineers across 4 timezones (US Pacific 3, US Eastern 3, UK 2, India 3). The daily 9am Pacific standup is 9:30pm IST. Q1 data:

• Attendance: India 3.2/5, US 4.6/5
• Average length: 14 min; content that changed someone’s behavior: 4 min
• Three documented duplicate-work incidents traced to status that was shared verbally and not searchable later

The meeting is paid for by the people who have the least flexibility in their day, and most of what is said is not actionable.

The proposal

Replace the daily sync standup with an async post in #team-standup by 10am local time, three fields: Shipped, In progress, Blocked or at risk (with @mention). Reclaim the 9am Pacific slot as a 60-minute Thursday working session for discussion that genuinely needs real-time exchange. On-call engineer triages the channel and responds to blockers within 30 minutes during business hours. 30-day trial, day-15 pulse, day-30 go / no-go.

Why now

• New hires in India onboarding next quarter; the current schedule sets a precedent we should not lock in
• Working session is a forcing function for cross-timezone discussion we have been deferring
• Cost of the change is low (pinned template, no new tooling) and reversible

What success looks like

Metric	Today	Day-30 target
Participation rate (posts / engineers / workday)	3.9 / 11	9+ / 11
Avg synchronous time on status per engineer per week	70 min	< 15 min
Blocker time-to-first-response	not measured	< 30 min business hours
Duplicate-work incidents (rolling quarter)	3	0

Trial stops at day 30 if participation is below 7/11 or the team votes against continuing.

Asks

1. Approve the 30-day trial starting Monday May 19.
2. Approve pausing the daily 9am Pacific meeting for the trial duration.
3. 15-min slot in your week of June 22 to review day-30 results and decide whether to make permanent.

No budget, tooling, or headcount requested. The Thursday working session is on the engineering calendar already.

How to start a morning routine

My Morning, on Purpose

A one-page design for the first hour of the day, written for myself.

Why this matters

The first hour sets the register for everything that follows. When I begin the day reactively (phone, Slack, news), I spend the rest of it trying to climb back into a chosen state. When I begin the day deliberately, the workday starts on my terms. Five weeks of evidence suggests the cost of the routine is small and the return is disproportionate.

The design (6:30am - 7:30am, weekdays)

1. Water. 8oz, immediately on rising. The first physical action is one I chose.
2. Light. 10 minutes outside, or at the largest window if weather makes outside hostile.
3. Movement. 15 minutes - walk, stretch, or bodyweight. Nothing that requires changing clothes twice.
4. Planning. 10 minutes, paper notebook, three lines: what matters, what to protect, what to drop.

Phone stays in the kitchen, face down, until 7:30am. No exceptions inside the hour.

What I will not do

• Add a meditation app, a habit tracker, or a fifth module before Q3.
• Renegotiate the routine on a hard morning. Hard mornings are when the routine earns its keep.
• Count travel days as failures. They run a compressed variant (water + planning only).

Signal that this is working

• Arriving at 9am with a written shortlist, not a vague intention.
• Mid-afternoon energy holding through 3pm without a crash.
• Family mornings feel like a transition I lead, not a wave that hits me.

Next step

Hold the design through 2026-06-14. At that point, evaluate adherence (target: >= 80 percent of weekdays) and revisit module order. Do not change the design before then.

How to choose between Postgres and DynamoDB for a new service

Notification Service Datastore: Recommend Postgres, Decision Needed by Friday

Situation / Background

Lattice Notify is building a real-time notification system that needs a new persistent datastore. Launch volume is 500K events/day; the upside scenario is 10x growth in 12 months if the Slack-partnership deal closes. We evaluated two candidates in the Wednesday 2pm architecture meeting: extend our existing Postgres footprint, or adopt DynamoDB as a second datastore.

The Point

• Recommend Postgres, extended with a new schema and a pg_notify-backed job queue.
• The decision turns on operational capacity, not access-pattern fit. We have 8 backend engineers and a 4-person on-call rotation with deep Postgres knowledge and zero production DynamoDB experience.
• DynamoDB is the better technical fit for the access pattern; Marcus made that case correctly. We are accepting a worse pattern fit in exchange for a smaller operational risk surface at our current team size.
• A documented revisit threshold (5M events/day sustained) triggers a new decision review before we scale further on Postgres.

Why It Matters / Implications

• Time to launch: Postgres path ships ~3 weeks faster to first production traffic than the DynamoDB path. Sprint planning Friday assumes this.
• Recovery cost if wrong: Both options are recoverable in 3-6 weeks. Postgres recovery is more predictable because we have done a Postgres migration before; DynamoDB recovery would also require unwinding a partially-learned tool. The asymmetry is small but real.
• On-call burden: Adopting DynamoDB doubles our operational surface (second runbook, second monitoring story, second debugging skillset on every page). At 8 engineers, this is the load-bearing concern.

Ask / Recommendation / Next Steps

• Priya: lock the decision at our 11am Friday sync so I can mark ADR-0023 Accepted before sprint planning at 2pm.
• Marcus: sign off on the 5M events/day revisit threshold language in ADR-0023 by EOD Thursday.
• Ana (me): post the decision to the Friday all-hands engineering update and brief the on-call rotation.

Full reasoning: ADR-0023 (draft, link in #notify-arch). Contact: Ana Rivera, ana@latticenotify.com.