Principle 01
The Amazon 6-Pager: Silent Reading Instead of Presenting
Replace the Pitch with Collective Thinking
6-Pager · Narrative Memo
Principle & canonical quote
Replace 20 slides with a 6-page narrative memo; spend the first 20 minutes of the meeting reading it in silence. Trade the "reporting performance" for collective thinking. When discussion starts, no one is wondering "should I ask this?" — they've all just read the same thing.
"Many years ago, we outlawed PowerPoint presentations at Amazon. ... We have a 'study hall' at the start of our meeting. The reason writing a good four-page memo is harder than 'writing' a twenty-page PowerPoint is because the narrative structure of a good memo forces better thought and better understanding of what's more important than what."
— Jeff Bezos,《2017 Letter to Shareholders》(Amazon, April 2018)
Why it works
PowerPoint's problem isn't the tool — it's the grammar. Bullets have no predicate, so an author can place "sales down 30%" next to "team morale is low" and let the audience invent the causal link that the page never actually claimed. Narrative forces the gap open: every claim must be followed by a complete sentence of explanation. The author owns the causality; it cannot be outsourced to the listener.
Before / After
A 15-slide "Q3 Strategy" deck: 5 chart pages, 3 roadmap timelines, 6 competitor screenshots, 1 "next steps" page. After 45 minutes the room still asks "so what are you actually proposing?"
6-page memo. P1 opens with one paragraph: "We propose moving 60% of R&D from Product A to Product C in Q3. This memo argues why, what we'd stop doing, and the three risks we'd take on." P2 sets three tenets ("serve paying customers first / don't fight the giants head-on / cut long-tail dilution"). P3-4 carry data: Product A NPS down 18 points; C retention up 22%. P5 says the lesson honestly — last year we underestimated the competitor's release cadence. P6 names the decision and the stop-doing list. Discussion starts at minute 21, not minute 46.
"Q3 Strategy Update" — typical 15-slide deck. Author talks; audience guesses what the ask is; half write parallel emails during the meeting.
6-page memo distributed at meeting start. Twenty minutes of silence. Then the facilitator: "Page 3, anyone?" The author has already done the work; the room has already done the reading; the next 40 minutes are spent on the one or two decisions, not on context-loading.
When to use it / common failures
- ✓ Quarterly strategy reviews · major investment decisions · cross-team priority conflicts · any "easy to forget by Friday" meeting
- ✓ The higher the room, the more it pays off — decision-makers' time is the organization's most expensive resource
- ✗ Not for: pure status updates (use a wiki or 1-pager) · 50-person town halls (use a story + visuals)
- Failure 1: pasting PowerPoint text into Word — bullets never became sentences, you didn't get the narrative dividend
- Failure 2: skipping the silent reading — readers half-read while speaking, thinking is interrupted, the meeting degrades back to PPT mode
- Failure 3: appendix sprawl — a 6-page memo dragging a 40-page appendix means readers are still slogging through a deck
- Failure 4: author checks out during study hall — everyone reads, the author scrolls Slack. Use those 20 minutes to re-read your own memo with adversarial eyes
Key references
Jeff Bezos《2017 Letter to Shareholders》Amazon 2018 — the public-facing statement of the 6-pager · Colin Bryar & Bill Carr《Working Backwards》(2021) Ch. 4 — ex-Amazon executives walk through the 6-pager and narrative culture · Brad Porter"The Beauty of Amazon's 6-Pager" (LinkedIn, 2015)
This week's exercise + reflection
Exercise: Take your next decision-track report — whatever it was going to be (deck or email). Force it into the 6-pager skeleton: Introduction / Tenets / State / Lessons / Priorities / Appendix. Limit yourself to complete sentences; no bullets allowed in the body. After you finish, find three places where you can say "the PPT would have glossed past this in one bullet; writing a full sentence forced me to actually figure it out." Those three places are the dividend.
Reflection: Can the "20 minutes of silent reading" ritual survive in high-context meeting cultures (e.g., East Asian organizations) where seating, speaking order, and saving face matter? If not, what substitute keeps the structural benefit — pre-reading 24 hours in advance, plus a 5-minute meeting recap? Or something else entirely?
Principle 02
Narrative over Bullets: Where Shallow Thinking Hides
The Cognitive Style of Complete Sentences
Narrative · Verbs
Principle & canonical quote
Bullets are an invisibility cloak for thought — they let an author place two claims side by side without writing the causal link. Complete sentences (with subject, verb, object, with "because" and "therefore") are thought's medical exam: where you haven't actually figured it out, your fingers stop at the keyboard.
"When you have to write your ideas out in complete sentences, complete paragraphs, it forces a deeper clarity of thinking. ... PowerPoint-style presentations somehow give permission to gloss over ideas, flatten out any sense of relative importance, and ignore the interconnectedness of ideas."
— Jeff Bezos, on the 6-pager (Forum on Leadership, 2018; quoted in《Working Backwards》Ch. 4)
The same critique appears in Edward Tufte《The Cognitive Style of PowerPoint》(2003): bullet lists destroy syntactic carrying capacity and flatten multivariate relationships into a single linear sequence.
Why it works
Compare the two columns and the point makes itself:
Bullets
- Q3 revenue down 15%
- European market expansion
- Hiring difficulties
- New SKU launch delayed
The reader has to invent causality: who caused what? Which is most important? Is this a recommendation or a complaint? The author has outsourced the thinking.
Narrative
Q3 revenue is down 15%, primarily because European market expansion slipped by 6 weeks — hiring in Europe was slower than planned, and the key PM vacancy delayed the new SKU. Of the 15-point gap, 11 points trace to this slip; the remaining 4 points are FX. We recommend pausing one minor US launch to reallocate headcount toward European hiring.
Same facts. Now causality is explicit, ownership is clear, the recommendation surfaces. The author's thinking is visible on the page.
Same facts. Bullets let the author skip the verb; narrative forces "cause, effect, therefore."
Before / After
Why the project slipped:
• Upstream API late
• QA capacity
• Lunar New Year
• New feature requests
(Four bullets, no causality, no recommendation. The reader can construct any story they like.)
The project slipped 3 weeks. The dominant cause was the upstream API arriving on Jan 15 — four weeks late against its commit, which blocked downstream QA. Lunar New Year and mid-stream feature requests amplified the slip (~1 week) but were not the primary driver. We recommend a hard-freeze date for upstream interface commits, and a moratorium on new feature requests after that date.
Reasons for delay:
• Upstream interface unready
• Testing resources tight
• Lunar New Year impact
• New requirements jumped queue
(Four points in parallel. Reader cannot tell precedence, causal links, or what the author proposes to do.)
This project slipped 3 weeks. The root cause is that the upstream interface was delivered on January 15 — four weeks behind commit, blocking downstream QA. Lunar New Year and queue-jumping requests amplified the impact (an additional week) but are not the primary driver. We propose: lock a hard-freeze date with upstream, and after that date refuse any downstream test-schedule overrides.
When to use it / common failures
- ✓ Any decision-grade writing: memos, BLUF emails, design docs, promo packets, post-mortems
- ✓ The more causality and tradeoffs you carry, the more you must avoid bullets — bullets' grammar is "parallel," not "because/therefore"
- ✗ Exception: pure enumeration (checklists, config items, SKU lists) — bullets are clearer here; forcing narrative is over-correction
- Failure 1: write narrative, then "polish" it into bullets — you just discarded the clarity you bought. Keep narrative in decision drafts; reserve bullets for appendix-style lists
- Failure 2: complete sentences stuffed with nominalizations ("perform an evaluation of," "carry out an analysis on") — verbs castrated, page still empty. Plain verbs do the work, not Latinate nouns
- Failure 3: confusing "longer sentences = deeper thinking" — the dividend is in verbs and causality, not word count. If one sentence carries the meaning, don't stretch it to three
- Failure 4: using narrative for status updates — updates should be bullets. Narrative is for decisions, not for daily syncs
Key references
Edward Tufte《The Cognitive Style of PowerPoint》(Graphics Press, 2003) — the foundational evidence-based critique of bullets · Colin Bryar & Bill Carr《Working Backwards》Ch. 4 — inside view of Bezos's narrative culture · Patrick McKenzie"Doing Business" series — decision memos in modern tech companies
This week's exercise + reflection
Exercise: Take a recent bullet list of your own (email, PR description, status update — any). Rewrite the whole thing as narrative. No bullets allowed; every adjacent pair of bullets must be connected by "because / so / by contrast / meanwhile" or similar. Watch for the places where your fingers pause for a second during the rewrite — that pause is the hole the bullet had been hiding for you.
Reflection: Native-Chinese and native-English writers have different bullet habits. Chinese tends toward short clauses and fewer explicit connectives — can it sometimes look like narrative while still hiding causality? What's the real test — formatting (are there bullet glyphs?), or syntax (does each sentence have a verb and a causal connector)?
Principle 03
The 1-Pager & BLUF: Conclusion in the First Paragraph
Bottom Line Up Front
1-Pager · BLUF
Principle & canonical quote
The first question every reader asks when opening a memo is "what do you want me to decide?" — not "what's the background?" BLUF (Bottom Line Up Front) puts that answer in the first paragraph. The 1-pager is BLUF in extremis: an entire decision memo compressed onto a single page of A4, with no room left for preamble.
"BLUF is a military communications principle: state the conclusion, the recommended action, or the key information in the first sentence. Everything that follows is support, not setup."
— US Army Field Manual, adapted in Kabir Sehgal,《How to Write Email with Military Precision》(Harvard Business Review, 2016)
The same structural argument runs through Barbara Minto《The Pyramid Principle》(1987) Ch. 1: lead with the answer, then the evidence — that's the top of the optimal pyramid.
Why it works
A reader's attention curve through a memo is steeply decaying — paragraph one read in full, paragraph two at 70%, paragraph three at 30%, then scanning. It isn't laziness; it's the physics of cognitive load. Burying the conclusion bets that every reader will hang on to the end — but a leader with 30 memos a day cannot. BLUF reverses the bet: put the highest-value information (the conclusion and the ask) where attention is highest.
The 1-pager is BLUF with hard constraints attached — one page of A4 leaves no oxygen for filler.
TITLE
Proposal: Approve $1.2M Q3 budget for EU launch · 1-pager · author: bc · 2026-05-27
BLUF
Recommend approving the $1.2M EU-launch budget by 2026-06-10. Without approval by that date, we miss the August Frankfurt event, which is our only cost-effective channel for the next 12 months.
CONTEXT
EU pipeline has grown 3.2× in 2 quarters; the current US-only team cannot service it. Frankfurt has a 4-month lead time on sponsorship slots.
OPTIONS
A. Approve $1.2M (recommended). Risks: 2 new hires, EU compliance ramp.
B. Approve $600K, defer event. Saves 50% but kills our main channel.
C. Decline. EU revenue capped; competitor lock-in within 9 months.
RISKS
Hiring timeline (September ramp) · GDPR audit timing · USD/EUR exposure on $400K (hedge planned).
ASK
Decision by 2026-06-10. If approved, hiring posts go live 2026-06-12.
Before / After
"Dear team, I hope this email finds you well. Over the past quarter we've been discussing the EU opportunity, and I wanted to share some thoughts on next steps. As you know, our pipeline has grown substantially, and we've been evaluating various options. After much deliberation, ..." (Two and a half paragraphs of throat-clearing before "we propose $1.2M" appears. The leader has already closed the tab.)
"Proposal: Approve $1.2M Q3 budget for EU launch by 2026-06-10. Without approval by that date we miss the August Frankfurt event — our only cost-effective EU channel for the next 12 months. Three options follow; recommended is A. Context, risks, and ask on this page."
"Following our discussions around expanding into Europe and incorporating the team's feedback over the last three months, after careful evaluation, I'd like to align on Q3 budget allocation —" (Polite preamble; the actual ask doesn't surface until paragraph two. By then the reader is skimming.)
"I'm asking for approval of a $1.2M Q3 EU-launch budget by June 10. Miss that date and we miss the Frankfurt event, our only cost-effective EU channel for the next 12 months. Three options below; A is recommended. Context, risks and ask all fit on this page."
When to use it / common failures
- ✓ Any decision-requiring document — budget approvals, headcount asks, final tech-selection calls, promo nominations
- ✓ Anything going to a CEO / VP — they read 30 a day with no patience for the second paragraph
- ✓ Urgent communications — incidents, PR crises, the first page of a production post-mortem
- ✗ Not for: narrative writing (fiction, brand stories, TED talks) — BLUF kills suspense
- ✗ Not for: open exploration ("should we do X?") — there's no bottom line yet to put up front
- Failure 1: BLUF too soft, "recommend considering an evaluation of..." — the leader cannot find the decision point. BLUF must be verb + object + deadline
- Failure 2: 1-pager actually 1.5 pages, layout squeezed — when the hard limit breaks, preamble sneaks back. One page means one page
- Failure 3: BLUF contradicts the body — BLUF says "recommend A," body argues "but B might also work." Readers who only read BLUF will make the wrong call
- Failure 4: treating BLUF as a writing style — it's a structural rule, not a tone choice
Key references
Kabir Sehgal"How to Write Email with Military Precision" Harvard Business Review 2016 — concise BLUF primer · Barbara Minto《The Pyramid Principle》(1987) Ch. 1 — the structural argument for conclusion-first · Will Larson《An Elegant Puzzle》Ch. 4 — decision memos as leverage in engineering organizations
This week's exercise + reflection
Exercise: Write a real 1-pager. Pick the topic (a leveling-framework decision / a hiring ask / a team reorg / a strategy pivot). Hard rules: one page of A4, BLUF as the first sentence of the first paragraph, an Options section, an Ask section. Print it. If it spills past one page, what to cut isn't the font size — it's the filler.
Reflection: BLUF runs into resistance in high-context cultures (East Asian business norms, indirect speech, face). A junior author writing "I need your decision by June 10" to a senior leader can read as overstepping. How do you keep the structural dividend of BLUF while softening the tone — change the wording ("I'd be grateful for your decision by June 10"), change the framing (write strong BLUF to peers, BLUF-as-ask to leaders), or both?
Principle 04
Working Backwards: Press Release Before Product
Iterate on Paper, Not on Code
PR/FAQ · Working Backwards
Principle & canonical quote
Before writing any code, write "the press release we'd publish the day this ships" and "the five questions customers will ask." If the press release sounds boring, or if the FAQ has no good answers, the product shouldn't exist. Narrative is the cheapest prototype you can buy.
"The product manager typically writes an internal press release announcing the finished product. The target audience for the press release is the new/updated product's customers. ... Iterating on a press release is a lot less expensive than iterating on the product itself."
— Ian McAllister, ex-Amazon GM (Quora answer, 2012; canonical in《Working Backwards》Ch. 5)
Why it works
The default product flow is: ideate → build → market. Working Backwards inverts the back half: write the press release and FAQ first, then decide whether to build. The PR forces the team to answer "why would the customer care?" — and if you cannot write a compelling one, the value proposition isn't there. That's usually the project worth killing.
1
Write the Press Release PR
Imagine the day the product ships. The press release: customer problem / solution / customer quote / call to action. One page, written in customer language — not engineering jargon.
2
Write the FAQ Frequently Asked Questions
Internal FAQ: cost? engineering effort? dependencies? biggest risk? why now? External FAQ: pricing? compatibility? data? privacy? support scope? Questions you can't answer mean you haven't thought it through.
3
Iterate the PR/FAQ On paper, not on code
Small-group review → edit PR → edit FAQ → edit PR. Three to five rounds. Every week here saves three months downstream.
4
Decide whether to build Go / No-Go
PR/FAQ passes review → enter MLP (Minimum Lovable Product) development. Doesn't pass → kill the project. Killing on paper is the cheapest kill there is.
5
Build & Ship Build to the PR
Development tracks the PR — it is the north star. When features start drifting from the PR, either change the PR or cut the feature; "silent drift during build" is not allowed.
Flow inverted: press release and FAQ before code. Amazon has killed countless bad projects at step 3.
Before / After
PM writes a 5-page PRD: features, user stories, technical dependencies, roadmap. Engineering can build from it, but after reading it the executive sponsor still doesn't know why customers will be excited — and neither does the PM, deep down.
PM writes the PR first. Headline: "Acme Launches Real-Time Refund Reconciliation for Fortune 500 Retailers." Customer pain (30-day reconciliation delay) → our solution (real-time API + automation) → mock customer quote → ship date. Then the FAQ: pricing model? why not outsource? engineering effort? biggest risk? Three iteration rounds. They discover the mock customer quote sounds hollow — differentiation isn't sharp enough. Killed at step 3. Saved 6 months of engineering.
"We should build an AI retrospective assistant for engineering managers — it auto-summarizes team status from PRs, JIRA, and email." (Sounds plausible. But why will a customer pay? Competitors are building the same thing; where's the wedge? You only find out 4 months into code: not differentiated.)
Write the PR first: "Acme launches AI Engineering Pulse — a 5-minute team weekly for mid-level leaders. Customer quote: 'I used to spend two weekend hours writing the weekly; now it's ten minutes.'" Writing the quote, you realize it doesn't actually land. Then the FAQ: "How are you different from Tool X?" You can't answer it crisply — just vague "AI is better." Two signals that the value prop hasn't been sharpened. Go back to step 1, or kill it. Two weeks of paper saves six months of code.
When to use it / common failures
- ✓ New product / feature kickoff · strategic pivot · internal platform services (where "customers" are other teams)
- ✓ Strategic narrative — when you need alignment on "where we're going" before the product exists
- ✗ Not for: bug fixes, small iterations, A/B experiments — PR/FAQ overhead exceeds the value
- ✗ Not for: research-mode exploration ("does this path exist?") — there's no "product shape" yet to announce
- Failure 1: PR reads like a feature brochure — listing capabilities instead of customer pain + solution. PR is written for the customer, not for sales
- Failure 2: FAQ skips the hard questions — only "how great is the product?", not "what if revenue hits only 30% of plan in year one?" or "why won't a competitor crush us?" The FAQ's job is to force the devils into daylight
- Failure 3: PR/FAQ written, then archived — never re-read during development. Three months in, shipped product diverges from PR by miles; marketing rewrites the story from scratch
- Failure 4: PR/FAQ outsourced to marketing — loses its entire value as a thinking tool. It must be written by the PM with end-to-end ownership
Key references
Colin Bryar & Bill Carr《Working Backwards》(St. Martin's, 2021) Ch. 5 — full PR/FAQ process from inside Amazon · Ian McAllister"What is Amazon's approach to product development?" Quora 2012 — the original public description · Amazon Leadership Principle"Customer Obsession" — PR/FAQ is the writing instantiation of this principle
This week's exercise + reflection
Exercise: Pick a project your team is doing or considering. Write the PR/FAQ in reverse: (1) a one-page PR with headline, customer problem, our solution, and one mock customer quote; (2) an 8-question FAQ that includes 4 hard questions ("Where's the differentiation?" "What if year-one revenue hits 30% of plan?" "What happens if our key dependency hikes price 50%?" "Why won't customers just stitch it together themselves?"). After you finish, ask: did the customer quote feel grounded in a real scenario, or was it hollow? Can you answer the hard questions? If not, the project may belong back at step 3.
Reflection: The PR/FAQ process barely works once a project has been over-promised upstream — the commitment is already made, no PR is hollow enough to kill it. How does an organization put PR/FAQ before commitment rather than after? Is this a process design problem or a culture problem?