為什麼「儘早驗證」是高槓桿活動#

在第 4 章我們學到：投資迭代速度讓我們把事情做得更多。 在這一章，我們會看到：儘早並經常驗證想法，能讓我們把對的事情做出來。

書中以兩家公司對照。

Cuil：曾被視為「Google 殺手」的搜尋引擎，2008 年帶著號稱比 Google 大 3 倍、成本只有十分之一的索引上線。但因為怕媒體洩漏，沒有任何 Alpha 測試者試用過。上線當天結果品質差、缺乏拼字修正、結果還比 Google 少，被媒體與用戶撻伐。最終燒掉 3,300 萬美元創投資金、數十年人月，倒閉收場。創辦人 Joshua Levy 學到的最大教訓：儘早驗證產品。

BloomReach：Levy 在下一家公司只用四個月就把一個簡陋但能運作的系統交到 Beta 客戶手上。客戶回饋直接驅動產品優先順序，今日已成為 Neiman Marcus、Crate & Barrel 等品牌的合作夥伴。Levy 的話：「不要拖延……取得回饋。 找出什麼能用——這遠勝過先全部做完，再相信自己每件事都做對了，因為你不可能全對。」

用最小工作量找出可驗證的方式#

Square 工程經理 Zach Brock 常問團隊：「這個專案最可怕的部分是什麼？ 就是未知最多、風險最高的那塊。先做那一塊。」

iteration 的精神就像 MIT 機器人比賽中作者自製的小車：與其衝得遠後才發現走偏，不如「走一小段、檢查、再修正」。每一次小迭代都讓我們有機會重新校正方向，避免錯誤累積成大失誤。

啟發我們在任何專案上反覆自問：能否花 10% 的時間先收集資料，驗證另外 90% 的努力會走在對的路上？

MVP 的真諦：用最小代價驗證假設#

Eric Ries 在《精實創業》定義 最小可行性產品（Minimum Viable Product，MVP）：「能在最少努力下，獲得關於用戶最大化的『被驗證的學習』的產品版本。」

經典案例：以「偽造」進行驗證

• Dropbox：創辦人 Drew Houston 在實作複雜的同步功能前，先製作了一段 4 分鐘的影片，演示檔案在 Mac、Windows、Web 間無縫同步。一夜之間 Beta 等待清單從 5,000 衝到 75,000 人
• 42Floors：辦公空間搜尋引擎，第一次改版花了 3 個月後指標卻完全沒動。第二次他們改用 Photoshop mockup + AdWords 廣告引流到「假頁面」，一次驗證 8 個設計，找到實際有用的版本
• Asana：在猶豫是否要實作 Google 登入時，先放上「假按鈕」，點下去顯示「敬請期待」訊息。等數據確認需求才開始實作

工程師的低成本驗證術#

並非只有新創產品才適用，這原則同樣適用於工程決策：

• 架構遷移驗證：在花數月把 MySQL 換成 NoSQL 之前，先用代表性負載做小範圍 Prototype，衡量效能與程式碼足跡
• 演算法驗證：在投入數週建立生產級系統前，先在「小部分資料集」上測試新的評分演算法
• 介面設計：在寫程式碼之前，用紙筆原型（Paper Prototype）或低保真模型（Low-fidelity Mock）展示概念
• 時程估算：先做一週的初步進度檢查，再判斷 10 週時程是否可行
• Bug 優先級：先看日誌資料確認 Bug 影響的用戶數，再決定是否投入修復

用 A/B 測試持續驗證產品變更#

2012 年 Obama 連任競選時，數位團隊把募款信主旨 “Deadline: Join Michelle and me” 換成 17 個版本進行小規模測試。 最終勝出的 “I will be outspent” 在 440 萬訂閱者中募到 260 萬美元——是表現最差版本的 6 倍。 整個競選期間共發出 400 封郵件、測過 10,000 種變體，貢獻了 Obama 在線募款 6.9 億美元的多數金額。

A/B 測試的價值#

• 隔離變因：透過 Cookie 或 User ID 隨機分組，控制其他流量波動，把指標差異歸因到變更本身
• 量化影響規模：不只是「哪個比較好」，還能知道「好多少」。1% vs. 10% 提升的差距，會直接決定後續投資方向
• 培育迭代文化：Etsy 對商品列表頁的重設計，是用 8 個月跑出一連串 A/B 假設驗證後才打磨而成——成果是當年表現最好的專案

建立自己的測試框架可能令人卻步，市面上有許多現成工具：

• 開源／免費框架：Etsy 的 Feature-flagging API、Vanity、Genetify、Google Content Experiments
• 付費服務：Optimizely、Apptimize、Unbounce、Visual Website Optimizer

注意：時間是你最稀缺的資源。請聚焦於那些具有「高槓桿」且具「實質意義」的差異進行測試。Google 可以為連結藍色色階的 41 種版本做測試（每年差 2 億美元），但對多數公司來說，這種微小差距不值得跑。

警惕「單人團隊」的陷阱#

作者實習時，把整個暑假的成果累積成一份「巨型 Code Review」交給導師。 其他實習生聽完反應極大：「萬一導師找到設計缺陷怎麼辦？萬一根本沒時間 Review？」 雖然最後驚險過關，但這次經驗讓他學到：長時間獨自一人的工作必須額外打造回饋管道。

單人專案的隱性風險#

• 回饋阻力變大：缺乏共享情境的 Reviewer，難給出深入意見
• 低潮更加沮喪：困住、單調工作、難解 Bug，沒人能分擔
• 高潮少了動力：完成里程碑時無人擊掌
• 單點失敗：個人遇阻會直接讓專案停擺

Steve Wozniak 看似獨自設計 Apple I/II 硬體與軟體，但 Steve Jobs 提供了願景平衡與回饋迴圈——他並未真的在真空中工作。

主動建立回饋管道的策略#

1. 心態與溝通#

• 擁抱回饋：不要採取防禦心態，把批評當作學習機會
• 主動找人 sounding board：研究顯示「向他人解釋想法」是釐清盲點最佳方式；只是要尊重對方時間，事先準備好問題與已嘗試的做法

2. 技術執行策略#

• 儘早並頻繁地提交（Commit Early & Often）：用小批次強迫自己拿到回饋
• 找最嚴格的人 Review：如果只想趕快通過，會錯失最有價值的批評
• API 優先：先設計介面與 Client 端的呼叫方式，具體互動會暴露假設錯誤
• 發出設計文件徵求回饋：不必正式，一封詳細郵件也可

3. 結構化合作#

• 建立共享情境：盡量與隊友在同一領域（Focus Area）工作，或輪流攻克同一個專案
• 爭議性功能先取得 Buy-in：在投入大量時間前，先在對話中試探並用 Prototype 說服關鍵利害關係人

為你的決策建立回饋迴圈#

Facebook 工程總監 Nimrod Hoofien：「你所做的任何決定……都應該有一個回饋迴圈。否則，你只是在瞎猜。」

驗證的原則不僅適用於程式碼，更適用於 所有決策：招聘、團隊設計、文化建設、薪酬結構。

Hoofien 在 Ooyala 擔任 Engineering SVP 時，曾把多項組織設計當成可測試的假設：

• 變動團隊規模觀察是否分裂為小圈圈
• 把獎金與「可靠性」等工程指標綁定，看士氣反應
• 試驗 Tech Lead 是否要兼任 Manager（最後決定：是）
• 試驗 SRE、設計師、PM 是否要嵌入開發團隊（PM 是；其餘看情況）

通用的驗證流程#

1. 提出假設：預測什麼方法可能有效
2. 設計實驗：規劃如何測試（不一定要 A/B 測試，思想實驗也可）
3. 定義成敗：清楚知道好的結果與壞的結果長什麼樣
4. 執行並學習：根據結果修正下一步

你不一定能用 A/B 測試的嚴謹度驗證每個想法，但你可以把「靠猜」轉化為「靠資料」做決策。 這就是科學方法的精神。

重點摘要（Key Takeaways）#

• 用迭代方式逼近問題，減少浪費：每一輪都帶來新的驗證機會
• 用小驗證降低大實作的風險：花一點額外工夫，確保 90% 的努力走在對的路上
• 用 A/B 測試持續驗證產品假設：把使用者行為從黑盒變成可採取行動的知識
• 單人專案要主動建立回饋管道：默認行為是孤立，必須刻意打破
• 把所有決策都當成可測試的假設：建立回饋迴圈，否則只是在猜