谷歌和亞馬遜如何做產品

增長的算法：當極致效率成爲新的壟斷權力 “在硅谷的萬神殿中，我們往往膜拜那些靈光一現的創意，卻刻意忽視了支撐這些創意落地的、冷酷而精密的官僚主義骨架。”克里斯·凡·梅伊的《谷歌和亞馬遜如何做產品》撕開了科技巨頭神祕面紗的一角，暴露出一個令人不安卻又極具說服力的真相：那些改變世界的“極致產品”，並非天才在車庫裏的即興揮灑，而是誕生於一套高度結構化、數據驅動且不容置疑的交付流程。這本書不是一本充滿激情的創業雞湯，而是一份冷靜的工程手冊，它揭示了在數字資本主義的巔峯，創新是如何被異化爲一種可預測、可量化的管理科學的。 使命的修辭與策略的算計：產品誕生的政治經濟學 凡·梅伊在開篇就拋出了一個尖銳的邏輯推演：偉大的產品始於“使命”，但僅有使命是危險的浪漫主義。真正的起點在於“策略”——即如何利用公司的獨特優勢，在競爭對手的絞殺下爭取目標用戶的粗略計劃。 這一論述瞬間消解了產品開發中的神祕靈感論，將其還原爲一種赤裸裸的權力博弈。書中詳細闡述了從定義產品到量化反饋的七個階段，這不僅僅是一套操作指南，更是一種企業內部的政治架構。它要求產品經理不僅要懂用戶需求，更要深諳公司內部的資源流動與權力制衡。這種將“用戶體驗”與“組織政治”強行耦合的視角，打破了傳統管理學中對“用戶至上”的天真幻想。閱讀至此，我不禁對那種“爲了技術而技術”的極客神話感到一絲理性的嘲諷——在谷歌和亞馬遜這樣的巨獸體內，任何偏離核心策略的創新，無論多麼精巧，都註定是死路一條。 數據的暴政與直覺的殘存：量化一切的雙重效應 如果說工業革命是用機器替代了肌肉，那麼這本書所描述的“交付卓越產品”的過程，就是試圖用算法替代判斷。書中反覆強調“量化”的重要性：贏在測試、贏在指標、贏在數據反饋。 這種對數據的極致崇拜，構建了一種看似完美的理性閉環。它消除了決策中的噪音，提高了試錯的效率，但也帶來了一種“數據的暴政”。當每一個按鈕的顏色、每一個文案的長短都必須服從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面試之後，對方把我定位爲產品經理方向，於是讀了這本書。有些小開心，因爲其中的經驗和總結確實有與做研究項目相通的地方，是項目管理的理念。 多讀書，受益人還是自己。