How Amazon Works

非常好，主要是作为高管/内部人士，非常详尽介绍了amazon内部的best practices。当中的取舍、错误都说得很细，并不是leadership principle的简单罗列. 而且较为系统.

适用对象/读者

- 非常适用于大公司（因为面对的各类问题相近，比如如何解决资源分配和团队自主性的问题、怎么解决创新问题、高层怎么高效沟通不讲空话、高层怎么监控业务运转），甚至我觉得也部分适用于政府/国企. 主要适用重资源的项目. 因此主要适合在大厂工作的人.

- 完全不适用于pre p/m fit的创业小团队. 因为主要讲的是企业的管理方法. 创业团队的第一要务是验证市场需求、跑通模式，资源也非常少. 而且讲究非常快的速度 (无论是市场环境还是执行速度)

类似读物

如果喜欢

- creativity inc

- principles

- how google works, no rule rules (这两本我没读过)

应该也会喜欢这本书，都是成功企业的管理经验介绍，来自于亲历人自己的介绍.

价值

各家公司的管理方法完全不同. 但amazon的方法应该是相当有含金量的，因为其面对的复杂性远高于其他（电商涉及环节多、链条长，而且amazon也打造了众多独立的产品，比如aws, echo, kindle）. 像google, facebook本质更接近产品公司，只要做好最主要的业务（搜索、社交产品）就可以了 ，所以他们的方法论也远比amazon简单

这本书的信息量较大，需要1-2周才能读完，建议选感兴趣的专题逐个阅读，否则可能读不下去

笔记如下

1. 6-pager, Chap. 4

问题

- PPT不适用于信息密度很大的讨论. 尤其是级别较高、影响大、做决策的会议

- PPT的线性演讲不适合复杂内容. 人们经常提问题、引入别的讨论

解决方案

6-pager. 这个实际是tufte一篇文章中提出来的

示例: 见书

要点

- 结构灵活多变. 长度也是可变的 (1h会议 - 6页; 30min会议 - 3页)

- 文档的准备需要花时间，通常团队合作完成，可能需要修改很多次

- 需要老板拍板全公司才能采用这个流程，否则推不动. amazon就是bezos下的命令. 而且即便下了初期也有疑问. 实际是试行（比如1个季度后），管理层再决定是否继续采用

- 文档的tenet是一个重点（具体见附录）. 即对于一些关键问题的取舍, 战略考量. 让各高层有一个统一的输出, 便于后续继续执行 (否则总是争执不休). 比如 "通过帮助顾客做购买决策赚钱，而不是通过卖东西赚钱"，所以愿意展示商品的负面评价 (否则会影响销量、或者需要量化分析)

- 会议流程: 1/3时间集体阅读、写笔记; 阅读完毕不再做walkthrough, 直接进入讨论环节 (2/3的时间). 期间须有专人做笔记

我觉得本质在于，"怎么让一群人思考/讨论/贡献想法?" (对于写和看的人都是), 而不是简单给yes/no的回答. 写文档会是比做ppt更有效的方式，主要是

- 文档要求作者做足够多的准备、把问题想清楚

- 开头的强制阅读时间要求读者花时间思考. 也给了时间读. (如果提前给的话，很多人可能还是没有时间读)

因此投入同样多的时间，信息密度更高、会议讨论、决策质量更高.

*国内自媒体经常把互联网团队论拔高到很高的位置（各类战争、战斗、战略），但开会都是PPT; 但拿我们了解的高阶决策（比如解放战争时期我D的决策研究），绝对不是靠PPT的. 不用PPT并不是一个稀奇的方法，只是大家忘源了.

2. PR+FAQ, Chap. 5

问题

- 管理层参与产品讨论时，效率低（因为产品很多, 又涉及各类细节，如TAM, PNL, mock-up等）

- 复杂/高成本产品立项时需要尽可能详尽的计划、否则可能浪费资源

解决方案

- PR. < 1页. 包括标题/副标题, 问题, 解决方案.

- FAQ. < 5页. 包括内/外的FAQ. 内部考虑TAM，成本和PNL, 外部依赖, 可行性等

示例: 见书

也可以参考 https://svpg.com/example-prfaq/

要点

- 专注. Amazon以前试用过user manual, api手册, mock-up等各种方法，但都效率太低. 写的PR + FAQ发现是效率比较高的做法. 从PR开始也能更聚焦在用户好处（"为什么选择你"）, 不用过多量化市场需求, 考虑视觉效果等

- 高迭代. 最开始可能是PM写. 但通常要经过很多轮讨论、评审. 当中各方都会参与进来给建议，不断修改、打磨想法、考虑可能的问题. 采用这种形式利于反复修改、高层给建议 (比给mock-up建议简单、有效得多)

- 大部分proposal都不会通过. 一方面是市场机会没那么多、另一方面也是资源有限. 企业必须要足够聚焦. 但也因此才要求文档有足够的粒度, 才能全面评估各类产品想法

- 如果做新产品需要解决很难的问题（可能当时都没解决的），但如果市场机会足够大，管理团队会下决心去做，给资源去解决相关的挑战. 这样也避免了只在现有能力圈里做产品.

总的来说，就是通过一套标准的文档流程，让整个团队思考、准备细致的计划，一方面考虑用户的实际好处（并且团队上下对齐）、另一方面从各方面可能的问题考虑.

3. WBR, Chap. 6

WBR (Weekly Business Review) 即高管级别的每周业务分析会，看各类指标、数据的. 国内一般叫“经营分析会”. 主要目的

- 设计团队关注什么样的指标最有效

- 例行了解业务是否运作正常、是否有异常

原则

(1) 关注输入指标，而不是输出指标 (input >> out put)

- 关注可控制的输入指标（如商品的种类、覆盖程度、价格便宜程度），而不是输出指标（比如订单量、交易量、利润等）. 因为输入指标是可控制的，关注这些，则会逐渐提升这些. 比如不断提升商品的种类等

- 要求团队知道什么是对业务增长重要的东西. 比如上述，则是已经战略层设定了amazon的flywheel (下图)

于是所有的指标都围绕这些内容来. 从经验来说，这些指标通常是以用户导向的（比如用户关注、提升了才会提高商业指标），而不是商业导向（比如公司赚了多少钱等）

(2) DMAIC 流程 (define, measure, analyze, improve, control)

即指标的工作流程

- 逐步进行, 不要跳步. (比如没有在define弄明白什么指标关键，就开始考虑怎么improve). 指标本身也是不断迭代的. 比如内部关注selection的指标，从最开始的"商品详情页创建数量"，逐渐迭代到了"fast track in stock". 即多少访问的商品处在可以立即发货的状态. 因为很多长尾商品用户不看是没意义的、看了不能买也是没意义的。这样也才有可操作性，即团队可以对着这个指标逐步改进

- 足够的资源投入. 指标可以在不同的技术口径上实现，成本各有高低. 通常因为分析并非主营业务，所以可能会选择简单的实现. 但随着指标影响范围越来越大、战略层面的重要性越来越高，是需要作出足够的资源投入，去实现更准确的指标口径的.

- 注意验证/审计. 即随着对数据越来越熟悉，团队更关注指标反映出的异常事件. 也通过这些异常事件的分析，来验证数据的有效性（而不是反复看没问题的常规发展）

WBR 会议实践

(1) the deck (即图表为主的材料/内容)

示例如下

- 内容全面, end-to-end (即从用户角度，完整流程展现业务进展)

- 图表信息密度较高. 展现层面多维度对比（如过去6w, 12m, 和去年同期对比等），考虑各类趋势. 需要熟悉数据、区分波动是正常波动还是异常问题导致

- 和实际案例、异常结合. 比如客服团队会总结一些定性的用户案例上报；输出最亏钱的商品，看有什么问题（negative contribution profit produt list）

(2) 会议

- 面向CEO/CFO汇报; 各指标由各bu负责人解读，提前评审过; 财务团队负责收集

- 会议属于运营/执行级别，而不是战略级别的 (会有其他会议负责). 因此讨论也主要是业务发展是否符合预期，是否有异常. 整体都是在关注异常. 如果正常就可以快速略过 (而不是每个团队吹业绩)

- 讨论着眼点是"发生了什么"，而不是互相攻击谁犯了错. 否则很容易就变成互相指责、甩锅的大会. 允许团队犯错误.

对于本书的方法论，我关注到的要点如下

- 怎么让团队更有效地思考/讨论? 采用6-pager而不是ppt，并且让双方（作者/读者）都花时间准备，才有质量

- 怎么讨论复杂/高成本的产品想法? 采用PR+FAQ的文档. 以用户体验/好处为起点，再考虑各类问题，思路会更简洁/清晰. 需要全团队参与、仔细讨论. 对问题/挑战/机会有足够认识，再做行动. 大部分想法是会被拒绝的.

- 怎么监控经营情况? 关注输入指标而非输出指标; 每周和团队一起看数据、异常案例，并且在友好的环境下讨论（否则就变成互相甩锅了）

这些方法，本质都是让团队主动思考、深入细节，而不是仅仅唯上做执行. 如果只做执行，CEO的方向/想法可能是对的，但是面对复杂的产品/环境，细节方面考虑不到位，一样会失败. 本质原因是科技行业面对的环境是复杂多变的，也在不断创新. 并不是传统销售之类确定性很高的行业. 所以需要整个团队、熟悉细节的方方面面的人一起思考.

落到我自己的流程/方法上，就是产品团队常用的BRD，可以进一步分为6-pager + PR/FAQ，更完善一些.