谷歌和亚马逊如何做产品

增长的算法：当极致效率成为新的垄断权力 “在硅谷的万神殿中，我们往往膜拜那些灵光一现的创意，却刻意忽视了支撑这些创意落地的、冷酷而精密的官僚主义骨架。”克里斯·凡·梅伊的《谷歌和亚马逊如何做产品》撕开了科技巨头神秘面纱的一角，暴露出一个令人不安却又极具说服力的真相：那些改变世界的“极致产品”，并非天才在车库里的即兴挥洒，而是诞生于一套高度结构化、数据驱动且不容置疑的交付流程。这本书不是一本充满激情的创业鸡汤，而是一份冷静的工程手册，它揭示了在数字资本主义的巅峰，创新是如何被异化为一种可预测、可量化的管理科学的。 使命的修辞与策略的算计：产品诞生的政治经济学 凡·梅伊在开篇就抛出了一个尖锐的逻辑推演：伟大的产品始于“使命”，但仅有使命是危险的浪漫主义。真正的起点在于“策略”——即如何利用公司的独特优势，在竞争对手的绞杀下争取目标用户的粗略计划。 这一论述瞬间消解了产品开发中的神秘灵感论，将其还原为一种赤裸裸的权力博弈。书中详细阐述了从定义产品到量化反馈的七个阶段，这不仅仅是一套操作指南，更是一种企业内部的政治架构。它要求产品经理不仅要懂用户需求，更要深谙公司内部的资源流动与权力制衡。这种将“用户体验”与“组织政治”强行耦合的视角，打破了传统管理学中对“用户至上”的天真幻想。阅读至此，我不禁对那种“为了技术而技术”的极客神话感到一丝理性的嘲讽——在谷歌和亚马逊这样的巨兽体内，任何偏离核心策略的创新，无论多么精巧，都注定是死路一条。 数据的暴政与直觉的残存：量化一切的双重效应 如果说工业革命是用机器替代了肌肉，那么这本书所描述的“交付卓越产品”的过程，就是试图用算法替代判断。书中反复强调“量化”的重要性：赢在测试、赢在指标、赢在数据反馈。 这种对数据的极致崇拜，构建了一种看似完美的理性闭环。它消除了决策中的噪音，提高了试错的效率，但也带来了一种“数据的暴政”。当每一个按钮的颜色、每一个文案的长短都必须服从A/B测试的结果时，那种基于人类直觉和审美顿悟的颠覆性创新是否还有生存空间？凡·梅伊并没有回避这个问题，他承认数据只能告诉你“是什么”，而不能告诉你“为什么”或“应该是什么”。这种冷峻的自我反思，使得本书超越了普通的技术手册，触及了数字时代创造的本质困境：我们如何在算法的绝对控制下，保留那一丝作为人类的、非理性的火花？ 团队的熵减与沟通的博弈：对抗混乱的组织力学 在第二部分关于“卓越技能”的论述中，作者展示了一种跨界的智慧。他将团队管理视为一种对抗“熵增”的物理过程。项目管理、沟通、决策，这些看似软性的技能，在他的笔下变成了维持组织有序运转的工程问题。 特别是关于“沟通”的章节，揭示了一个常被忽视的真相：在复杂的大型组织中，信息的失真和延迟是创新的最大杀手。作者提出的解决方案并非简单的“多开会”，而是一种基于博弈论的机制设计——如何通过制度安排，迫使不同利益诉求的部门（如工程、市场、销售）在理性的自利驱动下，共同走向产品成功的纳什均衡。这种将社会学与工程学结合的视角，令人拍案叫绝，也让人对大公司内部那种令人窒息的官僚流程产生了一种“理解之同情”。 结语：一份关于数字时代的理性契约 《谷歌和亚马逊如何做产品》的价值，并不在于它提供了多少新奇的“技巧”，而在于它毫不掩饰地展示了现代科技巨头运作的底层逻辑——一种冷酷的、高效的、理性的、甚至是非人性的系统。 它告诉我们，所谓的“极致产品”，实际上是人类创造力与庞大官僚机器妥协的产物。对于那些渴望打破常规的创业者来说，这本书是一剂苦口良药，提醒他们理想主义必须建立在对现实规则的深刻理解之上；对于那些在大公司中感到迷茫的执行者来说，这本书则是一张清晰的地图，帮助他们在复杂的组织迷宫中找到自己的坐标。这是一本关于如何在确定性与混乱之间建立秩序的书，虽然它的语言冷峻得近乎无情，但它却是我们理解这个由代码和数据构建的现代世界不可或缺的一把钥匙。

整本书文章旨在回答一个核心问题：两家科技巨头凭什么持续推出“极致产品”？ 作者以在谷歌、亚马逊任职期间的真实经历，总结出一套从创意到发布的完整方法论，可概括为三大板块、七个关键步骤。 他将十年实战经验浓缩为一套可复制的软件交付方法论，全书分为“交付卓越产品，步步为赢”（第1~7章）和“掌握卓越技能，更胜一筹”（第8~13章）两大部分。 一、两大科技巨头的产品哲学共同点：都强调以用户为中心、数据驱动和快速迭代。 不同点： • 谷歌更看重“相关性”与点击率，决策流程依赖演示文稿与邮件来论证价值。 • 亚马逊以“转化率”为核心，高管围坐阅读产品单页（Single-Page Document），像“高考”一样进行评审。 三、极致产品生产线：从创意到发布的七个关键阶段全书第一部分构建了一条软件交付的完整流水线。本书系统阐述了软件交付的七个阶段：确定正确的产品、尽可能清晰详细地定义产品、设计用户体验、做一些基础的项目管理工作、开始测试、建立一套衡量产品成败的指标、正式发布。每个环节在本书中都有对应的章节，且每个章节都有核心交付物和关键方法论。 阶段一：确定方向：用新闻稿雏形——回答“谁的什么需求、何时需要、为何要做”。 作者开篇就给出一个核心原则：以客户为导向，而不是以竞争对手为导向。卓越的使命需要完全符合三点：能够唤起人们的兴趣、提供言之有物且能指明方向的原则、适合印在T恤上。策略则需要阐明三件事：客户、公司和竞争。团队应该始终积极地去解决客户的问题，而不是紧盯竞争对手，被动地做出反应。值得特别关注的是，作者明确提出了对产品经理的独特忠告：“不要只想着解决简单的问题，越困难的问题越值得去努力。”——这句话不仅定义了谷歌和亚马逊产品哲学的起点，也成为贯穿全书的精神主线。核心交付物：一句话使命宣言和三要素策略。 阶段二：产品定义十步法：——把模糊想法变成可执行蓝图 定义产品的过程分为10步：从撰写新闻稿、创建FAQ文档、绘制线框图或流程图，到撰写产品单页或10分钟演示文稿、添加API文档、撰写功能规格文档，再到邀请设计和工程团队评审、找客户测试产品概念、命名定价及预测收益。完成这10步之后，你就能得到一份定义完整、描述清晰的产品文档。核心交付物：产品单页和10分钟演示文稿。 阶段三：用户体验设计——通过讲故事的方式让所有利益相关方达成共识 将用户体验拆解为四大板块和六个评估问题。四大板块包括明确参与角色及其分工、设计评估的“6个用户体验问题”、高效沟通与需求传递、借助视觉与原型快速验证。这套框架帮助团队把抽象的“好体验”转化为可交付的产品里程碑。核心交付物：线框图、原型和用户故事。 阶段四：工程实现——回答“能否按时交付” 项目管理的本质只有一件事：做软件需要低成本的项目管理，用一张计划表、一套评估习惯、一张Bug燃尽图、一份依赖检查清单，让复杂的产品交付过程变得透明可控。过度管理比管理不足更可怕——复杂的甘特图、繁琐的工时系统、频繁的状态汇报，都会成为团队生产力的隐形杀手。核心交付物：Google电子表格计划表和Bug燃尽图。 阶段五：发布与度量——交付让自己不蒙羞的产品 构建了一套从文化底线（亲友蒙羞测试）到开发流程（TDD+CI）到验证手段（内部试用+找虫总动员+可信测试者）再到质量收敛（Bug标签化管理+新用户视角）的完整测试体系——目标只有一个：让每一次发布都经得起内部、外部乃至“亲友”的审视。核心交付物：测试清单和Bug管理标签体系。 阶段六：运营守护）——用数据而非直觉做决策 “无法测量的东西，注定无法提升。”作者给出五道筛选标准（低成本、可重复、高频、可行动、客户导向）和三类必须跟踪的数据（目标进度、经营绩效、系统性能）。这三类数据构成了一套完整的产品自述系统：目标进度告诉你“要去哪”，经营绩效告诉你“路上有什么坑”，系统性能告诉你“车本身有没有坏”。核心交付物：三类核心指标的仪表盘。 阶段七：发布和复盘——每个版本都进行复盘，关注用户行为、业务结果和团队流程，为下一次迭代积累经验。 明确了发布阶段的八项纪律：对改动说不、开启作战室、营造紧迫感、核查发布清单、撰写博文、灰度发布、亲自验证、危机预案与庆祝。同时要求产品经理在发布后第一时间完成验证，确保产品如预期般运转。发布不仅是技术动作，更是一场考验纪律性、沟通力和危机预案的“收官之战”。核心交付物：发布检查清单和危机预案方案。 这七个阶段不是线性的一次性流程，而是一个循环迭代的飞轮。每一次发布之后，量化数据会告诉你产品哪里出了问题，用户反馈会告诉你哪些需求被遗漏了，团队复盘会告诉你流程哪里可以优化——然后新一轮的“使命→定义→体验→管理→测试→量化→发布（复盘）”重新开始，每一次都比上一次更快、更稳、更精准。交付卓越产品的关键，就在于这条流水线能否被反复激活。 三、贯穿全书的硬核启示：五条不可违背的原则如果把视角从章节结构中抽离，去看贯穿全书的思维脉络，我认为有五条原则构成了这本书真正的底色。这些原则没有单独成章，但每一条都在至少三到五个章节中被反复验证、不断强化。 原则一：以客户为导向，而非以竞争为导向 从第1章开始，这一原则就被反复强调。“团队必须以客户而不是以竞争为导向。”使命的定义、需求的判断、功能优先级的排序，唯一的准绳是“这对客户有什么价值”。如果一个功能是为了对标竞争对手而做的，而不是为了解决客户的真实问题，那从一开始就不应该出现在计划里。这条原则也是应对优先级冲突的终极依据——当多角色决策者意见分歧时，最终落脚点永远是：对客户有什么价值？它会如何解决客户的问题？ 原则二：可交付的软件就是最好的软件 交付才是关键，软件从来没有做完一说。“可交付”并不等同于“功能完备”，而是指满足核心价值的、可被用户感知的可用状态。在最小化可行产品阶段，决策者面临的最大诱惑就是不断往V1里塞功能——多一个“小需求”似乎没什么影响，但每多一个功能，复杂度翻倍，质量曲线会急剧下坠，工期会无限膨胀。“推后请求”的本质不是不做，而是让V1只做那些“没有它产品就无法验证核心价值”的功能。 原则三：简单优于完美 每一个章节都在用不同方式讲同一件事：简单的计划表优于复杂的甘特图，原型图优于长篇需求文档，15分钟的“综述单页”优于1小时的汇报，针对关键场景的穷举式测试优于面面俱到的测试计划。最小化可行产品的意义不仅在于快速获得用户反馈，也在于避免团队为莫须有的客户问题构建完美解决方案而陷入狂欢。简单不是为了偷懒，而是为了把有限的精力花在真正重要的20%上。 原则四：团队主管是仆人，而非老板 这是全书十大交付原则的第一条。主管存在的目的不是为了当老板，而是为了服务工程团队。配合“两个披萨团队”原则——小型且拥有充分自主决策权的团队，能最大程度地减少官僚成本。正确的领导姿态是：把目标讲清楚，把数据拉通，然后让团队自己决定怎么走。你负责扫清他们路上的障碍，而不是替他们走路。 原则五：每个版本都应当进行复盘 每次发布之后，花15~30分钟回顾三个问题：用户行为告诉我们什么？业务结果是否达到了预期？团队流程中哪个环节拖了后腿？复盘的目的不是为了追责，而是为了确保下一次迭代比这一次更好。同时，也需要关注系统数据趋势，在系统达到极限前就做好扩展规划，而不是在崩溃发生后才追悔莫及。 四、贯穿全书的“硬核”工具• 产品单页与 10 分钟演示：用最短时间让利益相关方“看见并相信”产品价值。 • 用户场景与用例：把模糊想法拆解为可验证的交互流程。 • 自动化测试+可信测试者：在速度与质量之间找到可重复的平衡点。 • 数据驱动的发布决策：上线即度量，失败快速回滚，成功持续放大。 五、对每个创业者的核心启示任何伟大的产品都不是灵光一现，而是遵循可复制的流程逐步打磨。 文档和沟通是产品经理的主要产出：一篇好的产品单页或一次精炼的 10 分钟演示，胜过无数场无效会议。 发布只是起点：持续测试、监控和迭代，才能让产品在竞争中保持领先。 用“亲友蒙羞测试”替代一切你养不起的QA流程。 初创公司没有测试团队，没有自动化框架，但你至少有“羞耻心”。 先学会“问对问题”，再学“给出答案”。 初创团队的创始人或产品负责人，最容易掉进的陷阱是“什么都要自己给出答案”——技术方案你要定，设计方向你要定，定价策略你要定。但本书揭示的真相是：产品经理的真正价值不在于“给出所有答案”，而在于“问出正确的问题”

以下是克里斯·凡梅伊（Chris Vander Mey）所著《谷歌和亚马逊如何做产品》（英文原名 Shipping Greatness: Practical Lessons on Building and Launching Outstanding Software, Learned on the Job at Google and Amazon）的核心观念与详细思维导图。该书由刘亦舟翻译，人民邮电出版社2014年出版，属于图灵教育系列 。 --- 一、核心命题 "交付"（Shipping）比"管理"更有价值——成功交付的关键在于快速且充分地满足客户需求，而产品经理的核心使命就是解决客户的问题。 作者克里斯·凡梅伊曾任谷歌和亚马逊高级产品经理，后任Facebook产品经理，他将达特茅斯学院的理论知识与在领先互联网公司十年的工作经验总结于此，从定义产品开始，一步步指导读者完成管理项目、迭代、发布、市场推广等交付全流程 。 --- 二、主要观念详解 1. 十大交付原则（附录1） 这是全书的纲领性框架，浓缩了作者在谷歌、亚马逊、Facebook的实战经验 ： 原则 核心内容 1. 确定用户需求和预期指标 找到正确的需求是交付的起点 2. 以最小成本实现最主要的需求 聚焦核心价值，避免过度设计 3. 发布并获得数据反馈 数据驱动，快速迭代 4. 确定下一个迭代目标 产品交付不是结束，而是新的开始 5. 设定"目标"与"非目标" 告诉别人你要什么，也要告诉别人你不要什么 6. 简化项目管理 低成本管理，电子表格即可出彩 7. 测试驱动开发 质量是内建的，不是事后检验的 8. 量化一切 只采集正确的量化数据，专注于目标 9. 亲自验证软件 产品经理必须深度参与产品验证 10. 再度启航 交付后立即进入下一个迭代 2. 有效交付的七个阶段（第一部分） 全书第一部分以"步步为'赢'"为线索，系统阐述产品从构想到发布的完整流程 ： 阶段一：赢在使命和策略（第1章） - 找到正确的需求：用独特的方法解决很多人都有的大问题 - 构建卓越的使命：言之有物且能指明方向的原则 - 制订正确的策略：在竞争对手压力下，利用公司独特优势争取目标用户的粗略计划 阶段二：赢在产品定义（第2章）——10步产品定义法 这是全书最具操作性的部分，作者提出了清晰的产品定义流程 ： 步骤 内容 目的 第1步 撰写新闻稿（Press Release） 从用户视角描述产品价值 第2步 创建并不断更新FAQ文档 预判用户疑问，统一团队认知 第3步 绘制线框图和流程图 可视化产品结构与用户路径 第4步 撰写产品单页和制作10分钟演示文稿 向上沟通与团队对齐 第5步 在FAQ中增加API文档 明确技术接口与依赖 第6步 撰写功能规格文档 详细定义功能边界 第7步 找出边界情况并得到团队认可 覆盖异常场景 第8步 客户测试 验证假设 第9步 想清楚商业要素——命名、定价和收益 商业可行性 第10步 取得上层的认可 获取资源与授权 阶段三：赢在用户体验（第3章） - 了解各类设计角色：UX、UI、信息架构、视觉设计、用户研究、角色模型 - 学会评估设计：不是凭感觉，而是有标准 - 与设计师有效沟通：借助图画而非文字 - 用户体验需关注的6个问题 阶段四：赢在项目管理（第4章） - 简化是核心：电子表格即可出彩，无需复杂工具 - 创建简单计划表并持续维护 - 拿到评估量（时间估算） - 跟踪Bug并创建Bug燃尽图 - 管理依赖关系 阶段五：赢在测试（第5章） - 坚持测试驱动开发（TDD） - 围绕优秀测试主管组建测试团队 - 亲自评审测试计划和测试用例 - 自动化测试 - 推行内部试用（Dogfooding） - 开展"找虫总动员"（Bug Bash） - 准确且有条理地处理Bug - 发挥可信测试者的作用 - 思想火花：以新用户的方式使用整个产品 阶段六：赢在量化（第6章） - 采集正确的量化数据，且只采集正确的量化数据 - 三类量化数据：目标指标、健康指标、诊断指标 - 专注于目标本身，忽略细枝末节 阶段七：赢在发布（第7章） - 对改动说"不"：冻结需求，锁定范围 - 开启作战室：集中办公，快速响应 - 营造紧迫气氛 - 完成发布清单核查 - 撰写博文 - 发布软件 - 亲自验证软件 - 应对发布带来的各种影响 3. 掌握卓越技能（第二部分） 第二部分从"交付流程"转向"个人能力"，帮助产品经理在软技能上更胜一筹 ： 胜在团队（第8章） - 如何组建一支团队 - 如何收购一家公司 - 如何与远程团队合作 - 如何加入到一个新团队 胜在技术（第9章）——四个S - 服务器（Server）：理解后端架构 - 服务（Service）：理解服务化设计 - 速度（Speed）：性能优化的重要性 - 扩容（Scale）：系统扩展能力 - 如何询问正确的技术问题 胜在沟通（第10章） - 如何写好邮件 - 如何应对五种类型的会议 - 如何组织好会议 - 如何做好演示 胜在决策（第11章） - 推后："我们明天再完"——学会延迟决策 - 谈判："行，再给你10分"——时间管理的艺术 - 处理冲突 胜在从容（第12章） - 平衡交付、质量、影响、团队四者关系 - 应对随机情况 - 在交付过程中管理精力 - 把向上求援当成工具而非托词 - 如何咽下"狗屎三明治"并生存下去——面对批评与压力的心理韧性 再度启航（第13章） - 一个互联网产品的交付上线不是意味着结束，而是意味着刚刚开始 - 尽快从产品交付的喜悦中回来，进入下一个迭代，在迭代中和产品共同成长 --- 三、详细思维导图 ``` 《谷歌和亚马逊如何做产品》——克里斯·凡梅伊 │ ├── 核心命题 │ └── "交付"比"管理"更有价值 │ ├── 前言：交付卓越产品 │ ├── 软件交付的定义：设计、打造、发布符合市场需求的软件 [^163^] │ ├── 作者背景：谷歌→亚马逊→Facebook，十年一线经验 │ └── 达特茅斯学院理论 + 硅谷实战 │ ├── 附录1：十大交付原则 │ ├── 1. 确定用户需求和预期指标 │ ├── 2. 以最小成本实现最主要的需求 │ ├── 3. 发布并获得数据反馈 │ ├── 4. 确定下一个迭代目标 │ ├── 5. 设定"目标"与"非目标" │ ├── 6. 简化项目管理 │ ├── 7. 测试驱动开发 │ ├── 8. 量化一切 │ ├── 9. 亲自验证软件 │ └── 10. 再度启航 │ ├── 第一部分：交付卓越产品，步步为"赢" │ │ │ ├── 第1章：赢在使命和策略 │ │ ├── 1.1 如何找到正确的需求 │ │ │ ├── 用独特方法解决很多人都有的大问题 [^171^] │ │ │ └── 需求验证：不是"我想做什么"，而是"用户需要什么" │ │ ├── 1.2 如何构建卓越的使命 │ │ │ ├── 言之有物 │ │ │ └── 能指明方向 │ │ └── 1.3 如何制订正确的策略 │ │ ├── 竞争对手压力分析 │ │ ├── 公司独特优势识别 │ │ └── 目标用户的粗略计划 [^164^] │ │ │ ├── 第2章：赢在产品定义（10步法） │ │ ├── 第1步：撰写新闻稿 │ │ │ └── 从用户视角描述产品价值 │ │ ├── 第2步：创建并不断更新FAQ文档 │ │ │ └── 预判疑问，统一认知 │ │ ├── 第3步：绘制线框图和流程图 │ │ │ └── 可视化产品结构与用户路径 │ │ ├── 第4步：撰写产品单页和10分钟演示文稿 │ │ │ └── 向上沟通与团队对齐 │ │ ├── 第5步：在FAQ中增加API文档 │ │ │ └── 明确技术接口 │ │ ├── 第6步：撰写功能规格文档 │ │ │ └── 详细定义功能边界 │ │ ├── 第7步：找出边界情况并得到团队认可 │ │ │ └── 覆盖异常场景 │ │ ├── 第8步：客户测试 │ │ │ └── 验证假设 │ │ ├── 第9步：想清楚商业要素——命名、定价和收益 │ │ │ └── 商业可行性 │ │ └── 第10步：取得上层的认可 │ │ └── 获取资源与授权 │ │ └── 结论：产品已经准备就绪，去构建它吧 │ │ │ ├── 第3章：赢在用户体验 │ │ ├── 3.1 了解各类设计角色 │ │ │ ├── 用户体验（UX） │ │ │ ├── 用户界面（UI） │ │ │ ├── 信息架构（IA） │ │ │ ├── 视觉设计 │ │ │ ├── 用户体验研究 │ │ │ └── 角色模型（Persona） │ │ ├── 3.2 了解如何评估设计 │ │ │ └── 有标准，非凭感觉 │ │ ├── 3.3 了解如何与设计师沟通 │ │ │ └── 借助图画而非文字 │ │ └── 3.4 学习如何借助图画进行沟通 │ │ └── 可视化思维 │ │ │ ├── 第4章：赢在项目管理 │ │ ├── 4.1 创建一张简单的计划表并持续维护 │ │ │ └── 电子表格即可出彩 [^170^] │ │ ├── 4.2 如何拿到评估量 │ │ │ └── 时间估算的艺术 │ │ ├── 4.3 跟踪Bug并创建Bug燃尽图 │ │ │ └── 可视化进度 │ │ └── 4.4 管理依赖 │ │ └── 识别并化解阻塞 │ │ │ ├── 第5章：赢在测试 │ │ ├── 5.1 坚持测试驱动开发（TDD） │ │ ├── 5.2 围绕优秀的测试主管组建测试团队 │ │ ├── 5.3 亲自评审测试计划和测试用例 │ │ ├── 5.4 自动化测试 │ │ ├── 5.5 推行内部试用（Dogfooding） │ │ ├── 5.6 如何开展找虫总动员（Bug Bash） │ │ ├── 5.7 准确且有条理地处理Bug │ │ ├── 5.8 发挥可信测试者的作用 │ │ └── 5.9 思想火花：以新用户的方式使用整个产品 │ │ │ ├── 第6章：赢在量化 │ │ ├── 6.1 如何采集正确的量化数据且只采集正确的量化数据 │ │ ├── 6.2 你需要采集的三类量化数据 │ │ │ ├── 目标指标（Goal Metrics） │ │ │ ├── 健康指标（Health Metrics） │ │ │ └── 诊断指标（Diagnostic Metrics） │ │ └── 6.3 专注于目标本身，忽略细枝末节 │ │ │ └── 第7章：赢在发布 │ ├── 7.1 对改动说不——冻结需求 │ ├── 7.2 开启作战室——集中办公 │ ├── 7.3 营造紧迫的气氛 │ ├── 7.4 完成发布清单的核查 │ ├── 7.5 撰写博文 │ ├── 7.6 发布软件 │ ├── 7.7 亲自验证软件 │ └── 7.8 应对发布带来的各种影响 │ ├── 第二部分：掌握卓越技能，更胜一筹 │ │ │ ├── 第8章：胜在团队 │ │ ├── 8.1 如何组建一支团队 │ │ ├── 8.2 如何收购一家公司 │ │ ├── 8.3 如何与远程团队合作 │ │ └── 8.4 如何加入到一个新团队 │ │ │ ├── 第9章：胜在技术（四个S） │ │ ├── 9.1 服务器（Server） │ │ ├── 9.2 服务（Service） │ │ ├── 9.3 速度（Speed） │ │ ├── 9.4 扩容（Scale） │ │ └── 9.5 如何询问正确的技术问题 │ │ │ ├── 第10章：胜在沟通 │ │ ├── 10.1 如何写好邮件 │ │ ├── 10.2 如何应对五种类型的会议 │ │ ├── 10.3 如何组织好会议 │ │ └── 10.4 如何做好演示 │ │ │ ├── 第11章：胜在决策 │ │ ├── 11.1 推后："我们明天再完" │ │ ├── 11.2 谈判："行，再给你10分" │ │ └── 11.3 处理冲突 │ │ │ ├── 第12章：胜在从容 │ │ ├── 12.1 平衡交付、质量、影响、团队四者关系 │ │ ├── 12.2 应对随机情况 │ │ ├── 12.3 在交付过程中管理精力 │ │ ├── 12.4 把向上求援当成工具而非托词 │ │ └── 12.5 如何咽下"狗屎三明治"并生存下去 │ │ │ └── 第13章：再度启航 │ ├── 交付不是结束，而是开始 [^164^] │ ├── 进入下一个迭代 │ └── 在迭代中和产品共同成长 │ └── 附录 ├── 附录1：十大交付原则 ├── 附录2：团队不可或缺的工件 └── 附录3：参考资料及延伸阅读 ``` --- 四、核心概念对照表 概念 定义 在全书中的作用 交付（Shipping） 设计、打造、发布符合市场需求的软件的完整过程 全书核心概念，优于"管理" 新闻稿（Press Release） 产品定义的第一步，从用户视角描述价值 逆向工作法的核心工具 FAQ文档 预判用户疑问、统一团队认知的 living document 产品定义的动态工具 目标/非目标 明确要做什么和不做什么 范围管理的关键 Bug燃尽图 可视化Bug数量随时间变化的趋势图 项目进度跟踪工具 找虫总动员（Bug Bash） 全员参与的集中找Bug活动 质量保障的创新方法 内部试用（Dogfooding） 团队自己使用正在开发的产品 早期发现问题的有效手段 四个S 服务器、服务、速度、扩容 产品经理的技术素养框架 狗屎三明治 面对批评与压力时的心理韧性 产品经理的情绪管理 作战室（War Room） 发布前集中办公、快速响应的工作模式 发布管理的关键机制 --- 五、方法论特色 1. 实战导向 全书没有空洞的理论，所有方法均来自作者在谷歌、亚马逊、Facebook的一线经验。例如： - 项目管理不用复杂工具，电子表格即可出彩 - 功能规格文档不是越长越好，关键是边界清晰 - 产品经理必须亲自验证软件，不能只做"传声筒" 2. 逆向工作法 从"撰写新闻稿"开始产品定义，是典型的亚马逊逆向工作法（Working Backwards）——先定义成功标准，再倒推实现路径 。 3. 量化思维 强调"只采集正确的量化数据"，避免数据过载。三类指标（目标、健康、诊断）的区分体现了谷歌的数据驱动文化 。 4. 迭代哲学 "交付上线不是结束，而是开始"——这一理念贯穿全书，与敏捷开发和精益创业的方法论高度一致 。 --- 六、书籍信息 项目 内容 英文书名 Shipping Greatness: Practical Lessons on Building and Launching Outstanding Software, Learned on the Job at Google and Amazon 中文书名 《谷歌和亚马逊如何做产品》 作者 [美]克里斯·凡梅伊（Chris Vander Mey） 译者 刘亦舟 出版社 人民邮电出版社 出版时间 2014年6月 页数 约208页 字数 约134,000字 定价 49.00元 配套网站 shippinggreatness.com 适用人群 IT行业产品经理、团队主管、对管理感兴趣的人士 --- 七、总结 《谷歌和亚马逊如何做产品》是一部以"交付"为核心、以"实战"为特色的产品经理工具书。它没有高深的理论，而是将谷歌、亚马逊、Facebook三大科技巨头的产品方法论提炼为可操作的步骤和原则。全书的核心贡献在于：将"产品经理"这一角色从"需求文档撰写者"提升为"产品交付的全程负责人"——从使命定义到发布验证，从团队协作到个人成长。对于希望理解世界一流互联网公司如何开发极致产品的读者而言，这是一本"按图索骥"的实战手册 。

对我来说算要点： 1. 新团队的相似之处： 并不清楚该干什么，为什么而干 2. 劳烦别人，寻求帮助 3. 传递清晰具体的信息的同时，向上汇报进展情况 4. 站会要点：昨天干了啥，今天准备做啥，遇到了啥问题 5. 头脑风暴第一原则：no judge 6. 先理解别人，再寻求别人的理解 7. 冲突矛盾原因构成比例：90%沟通不畅，9%目标不对，1%对方脑瘫 8. 当有人击中自己，先稳60秒（希望我那时候记得住这点，肾上腺素需要60秒才会开始被身体吸收 9. manage energy not time 10. 精力花在哪里，怎么优化精力分配，以及如何储备更多精力 11. 减少使用你，我的人称代词。多用数字说话，论事不论人。 7-10 年终总结用语

1. 找到足够大的问题，根据自身优势确定策略，逆向工作法完成文档，持续交付 2. 高中蒙羞测试 3. 找到优秀的指标：1）测量成本低；2）测量可靠；3）可频繁测量，最好实时；4）能指导团队做出改变；5）专注于客户 4. “我在面对面的面试时会抛出一个从麦肯锡公司那里借来的问题：“讲一个你是如何改变某些人想法的经历吧，以及你使用的技巧。”我等着听候选人是如何应对这种不在掌控的情况的。我会注意其中是否有合作决策，是否有基于数据的争论和聪明的向上反馈” 5. 写邮件最主要的目标应该是清晰、简要地传递单个信息。在亚马逊，人们普遍使用“清爽”这个词来定义清晰、简要的信息 6. 管理你的精力，而不是时间 7. 你不可能做完所有工作，所以你应首先做那些只有你能做的工作

一流的人找一流的人，二流的人往往找三流的人，因此，找到好的团队才能事半功倍。 优秀的公司很多都有开会的好习惯，其中一个是站会，这个或许我们一般的场景中比较少看到，在这里再说一下，我觉得挺有意思的。 站会，顾名思义大家站着开会，目的之一是让大家离开电脑，这自然而然就会让大家更加投入其中，使其开会的效率更高；另外，谷歌、亚马逊等公司他们的站会通常会安排会中午饭前开，这样大家也不会过于啰嗦，以至于耽误中午吃饭的时间。一般站会也就15分钟左右，而每个人只需要说三件事。 1、昨天干了什么 2、今天打算干什么 3、目前遇到什么阻碍，或者需要什么支持。

十大交付原则 1．你不是来当老板的——团队主管是仆人，他们存在的目的就是为了伺候工程团队。 2．从用户角度出发。 3．用独特的方法解决很多人都有的大问题。 4．坏的消息就是好的消息。——杰克·韦尔奇 5．先寻求理解，再寻求被理解。——史蒂芬·柯维 6．构建最简洁的可用的产品。 7．交付手中有的，而非脑中想的。 8．无法测量的东西也就无法提升。——开尔文勋爵 9．你不可能做完所有工作，所以你应首先做那些只有你能做的工作。 10．永远走在交付的康庄大道上。

五星评价，书清晰，2020年看的第35本书，谷歌的第7本书，产品的第五本书，谷歌系列看完了。本书逻辑清晰，思路清楚，难得一遇的好书。难能可贵的是，作者是一个对于交付和测试有一定经验和思考的人，本书主要讲了两件简单又复杂的事情，掌握技能，交付产品， 十大交付原则很接地气，你不是来当老板的，从用户角度出发，用独特的方法解决很多人都有的大问题，先寻求理解，再寻求被理解，坏消息就是好消息，构建最简洁的可用产品，交付手中有的而不是脑中想的， 掌握技能，主要是技术，团队，沟通，决策以及平衡与节奏。 交付产品，主要是产品定义，用户体验，项目管理，测试，量化与发布 真是本不错的书，很有启发，收藏，可以再看一次。

第一部分确实值得学习，一个完整的产品构建角度过程，尤其是构建的各个阶段的产物，最惊艳我的是新闻稿和产品宣传单页，以及意见收集清单，演示时准备的视频等文件！（我的补充到我的产品交付流程里，作为日常工作的必要产出物）

从高校到企业，是个非标人物。被猎头推荐到BAT面试之后，对方把我定位为产品经理方向，于是读了这本书。有些小开心，因为其中的经验和总结确实有与做研究项目相通的地方，是项目管理的理念。 多读书，受益人还是自己。