PowerPoint 之所以受爱用，是因为它替作者隐藏了思路上的空洞——子弹点之间的空白由听众脑补。Bezos 把整间公司的决策机制押在了一个反向赌注上：把会议前 20 分钟用来安静读一份 6 页的叙事备忘录。叙事强迫作者把"动词与因果"补全，思考浅了纸面就稀薄，作者跑不掉。这周四条原则——6-pager、Bezos narrative、1-pager / BLUF、Working Backwards——是「资深 leader 决策杠杆」的核心工具：写一份好的 memo 等于替自己又决策了一次，质量翻倍。
把 6 页叙事备忘录代替 20 页 slides；会议前 20 分钟全员静默阅读，把"汇报表演"换成"集体思考"。读完直接进讨论——没有"我是不是该问这个？"的迟疑。
中译：很多年前，我们禁掉了 PPT。会议开头有一段"自习时间"。写一份 4 页好备忘录比"做"一份 20 页 PPT 更难——因为叙事结构强迫作者更深入地思考，强迫他判断什么重要、什么更重要。
PPT 的问题不在工具，在它的"语法":bullet 之间没有谓语动词，作者可以把"销量下降 30%"和"团队士气低落"并列——读者脑补出"前者导致后者"的因果，但纸面上从未写过。叙事备忘录把这种隐藏的空白逼出来：每个 claim 都必须接一个完整句子的解释，因果由作者负责，不能外包给听众。
Jeff Bezos《2017 Letter to Shareholders》Amazon 2018 — 6-pager 公开声明 · Colin Bryar & Bill Carr《Working Backwards》(2021) Ch. 4 — 前 Amazon 高管详解 6-pager 与 narrative culture · Brad Porter"The Beauty of Amazon's 6-Pager"(LinkedIn, 2015)
习作：找下次你要做的一份决策汇报（不论原计划是 PPT 还是邮件），强行用 6-pager 骨架写出来：Introduction / Tenets / State / Lessons / Priorities / Appendix。限制自己只能写完整句子，禁用 bullet。写完读一遍——找出 3 处"原来 PPT 上一笔带过、现在写出完整句子才发现自己想得不透"的地方。
思考："静默阅读 20 分钟"在中国式会议文化（座次、发言顺序、面子）里能否落地？若不能，是替代以"会前 24 小时邮件预读 + 会议 5 分钟回顾"还是另有路径？
Bullet 是思考的隐身衣——它允许作者并列两个 claim 而不写因果。完整句子（带主谓宾、带"因为/所以"）是思考的体检——逻辑没想清楚的地方，写句子时手会停下来。
中译：当你必须用完整句子、完整段落写出想法时，它逼出更深的清晰。PPT 式的呈现允许你滑过观点、把所有要点压平到同一重要度、忽视它们之间的因果。
类似立场也见 Edward Tufte《The Cognitive Style of PowerPoint》(2003)：bullet 列表破坏了句法的传达力，把多变量关系压平成线性单。
看一组对比就懂了：
读者必须自己脑补：谁导致谁？哪个最重要？是建议还是抱怨？作者在偷懒。
Q3 营收下降 15%，主因是欧洲市场拓展延后了 6 周——欧洲招聘比预期慢，关键 PM 岗位空缺导致新 SKU 推迟。营收差距中 11 点可归因于此延后，剩 4 点为汇率波动。建议：暂停美区一项次要 launch，把人力 reallocate 到欧洲招聘。
同样的事实，因果链明确、责任归属清楚、行动建议浮现。作者的思考体现在纸面。
同一组事实，bullet 让作者不必表态——叙事逼出"哪个是因、哪个是果、所以怎么办"。
项目延期原因： • 上游接口未就绪 • 测试资源紧张 • 春节假期影响 • 新需求插队（四点并列。读者不知主次、不知是否互为因果、不知作者建议怎样应对） 本项目延期 3 周，根因是上游接口在 1 月 15 日才交付（比承诺晚 4 周），下游测试无法启动。春节窗口与新需求插队放大了影响（多吃了 1 周），但并非主因。建议：与上游约定接口的 hard freeze 日，并在该日后拒绝下游测试 schedule 之外的需求。
Why the project slipped: • Upstream API late • QA capacity • Lunar New Year • New feature requests(Four bullets, no causality, no recommendation.) 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.
Edward Tufte《The Cognitive Style of PowerPoint》(Graphics Press, 2003) — bullet 的认知缺陷原典，Tufte 是 evidence-based 论证 · Colin Bryar & Bill Carr《Working Backwards》Ch. 4 — Bezos narrative 文化内部视角 · Patrick McKenzie"Doing Business" series — 关于决策备忘录在科技公司的实战形态
习作：找一份你最近写过的 bullet 列表（邮件、PR description、status update 不限）。把全部 bullet 转写为一段完整叙事——不允许保留任何 bullet 点，每两条 bullet 之间必须用"因为/所以/相对而言/同时"等连接词。写完对比，看哪几处转换时手停了一秒——那一秒就是 bullet 之前替你隐藏的思考漏洞。
思考：母语为英文与母语为中文的写作者，bullet 习惯有何差异？中文短句多、连接词少，是否反而能伪装出"叙事"的样子？真正的检查标准是什么——是看格式（有无 bullet 字符），还是看句子里是否有谓语动词与因果连词？
读者打开一份 memo 的第一个问题是"你要我决定什么？"——不是"背景如何"。BLUF（Bottom Line Up Front，结论先行）就是把这个答案放进开头第一段。1-pager 是 BLUF 的极致：整份决策稿压到一页 A4，没空间藏铺垫。
中译：BLUF 是军用通讯原则——把结论、建议行动、或关键信息放进第一句。之后的内容都是支撑，不是铺垫。
类似立场见 Barbara Minto《The Pyramid Principle》(1987) 第 1 章：先讲答案、再讲论据，这是结构最优的金字塔顶端。
读者读 memo 的注意力曲线是陡降的——第一段全读、第二段读 70%、第三段读 30%、之后扫描。这不是读者懒，是认知负荷的物理规律。把结论放后面，等于赌读者一定能撑到最后——但 leader 桌上一天 30 份 memo，根本撑不到。BLUF 把这个赌注反过来：把回报最高的信息（结论与建议）放在注意力最高的位置。
1-pager 是 BLUF 的强约束版——一页 A4 一约束，铺垫自动死掉。
Kabir Sehgal"How to Write Email with Military Precision" Harvard Business Review 2016 — BLUF 简明引介 · Barbara Minto《The Pyramid Principle》(1987) Ch. 1 — 结论先行的结构论 · Will Larson《An Elegant Puzzle》Ch. 4 — 决策备忘录在工程组织中的杠杆作用
习作：写一份真实的 1-pager——题目自选（升级框架决定 / 招聘 ask / 团队重组 / 战略转向）。强约束："一页 A4、BLUF 在第一段第一句、含 Options 与 Ask 节"。写完打印出来——若超 1 页，砍掉的不是字号是冗余。
思考：BLUF 在东亚高语境文化（含蓄、不直接、给面子）下落地有困难——下属对上级直接说"我要你 6 月 10 日前决定"会显得越界。怎样在保留 BLUF 结构红利的同时调和这种文化阻力？是改语气（"想请您在 6 月 10 日前定夺"），还是改对象（写给同级时用强 BLUF，写给上级时第一句改成 ask 而非建议）？
在写代码之前，先写「这个产品上线那天的新闻稿」与「客户最常问的 5 个问题」。若新闻稿听起来无聊、若 FAQ 答不上来，这个产品就不该做——叙事是最便宜的 prototype。
中译：PM 先写一份"产品上线那天的内部新闻稿"——读者是这个产品的客户。在新闻稿上迭代比在产品本身上迭代便宜得多。
常规产品流程是：构思 → 开发 → 推广。Working Backwards 把后两步颠倒：先写新闻稿和 FAQ，再决定要不要 build。新闻稿强迫团队回答"为什么客户会在乎"——若你写不出有力的新闻稿，意味着 value proposition 还没想清楚，往往是该砍的项目。
Colin Bryar & Bill Carr《Working Backwards》(St. Martin's, 2021) Ch. 5 — PR/FAQ 全流程，前 Amazon 高管详解 · Ian McAllister"What is Amazon's approach to product development?" Quora 2012 — 流程原始描述 · Amazon Leadership Principle"Customer Obsession" — PR/FAQ 是这条原则的写作具现
习作：挑一个你团队正在做或在考虑做的项目。反向写一份 PR/FAQ：(1) 1 页 PR，含标题 / 客户问题 / 我方方案 / 一个模拟客户证言；(2) 8 条 FAQ，含 4 条 hard questions（"差异化在哪？""第一年收入只达预期 30% 怎么办？""依赖的 X 突然涨价 50% 怎么应对？""客户为什么不自己拼凑而要买我们的？"）。写完问自己：客户证言写出来时是来自具体场景的还是空洞的？硬问题答得上来吗？若不能，项目可能值得回到 step 3。
思考：PR/FAQ 流程对"已经 over-promise 给上层"的项目几乎不起作用——因为承诺已经做了，PR 写得多空洞都不会 kill。组织上怎么把 PR/FAQ 放在承诺之前而不是之后？这是流程设计问题还是文化问题？