原章：Metrics — Manage Your Inputs, Not Your Outputs
到了 2000 年左右，Amazon 已經是一家年營收數十億美元、極度依賴資料的公司，但規模成長也讓高階主管更難直接理解營運現場。作者描述，那段時間公司仍處在非常緊繃的階段，因此「知道數字」不夠，真正的問題是：哪些數字能讓管理者及早採取行動？
Amazon 逐漸建立 Weekly Business Review（WBR，每週營運檢討），並借用 Define、Measure、Analyze、Improve、Control 的流程來設計指標生命週期。
最具代表性的故事之一，是 Amazon 對「selection（選擇）」的衡量。最早團隊用「新增多少商品詳情頁」當作輸入指標，看起來很合理：商品愈多，選擇應該愈好。但 WBR 很快發現，詳情頁增加並沒有帶來預期銷售。
於是指標一路被修正：從「商品詳情頁數」變成「詳情頁瀏覽」，再加入「有庫存」，最後進一步要求商品能立即提供兩日配送，形成 Fast Track In Stock。指標愈改愈接近顧客實際感受到的「選擇」。
| 故事節點 | 原本以為 | 資料告訴他們 | 新的理解 |
|---|---|---|---|
| 商品選擇 | 詳情頁愈多就是選擇愈多 | 新增頁面不一定帶來銷售 | 顧客必須真的看見並想要商品 |
| 有需求的商品 | 有人看就算提供選擇 | 缺貨商品仍然造成差體驗 | 選擇必須可購買 |
| 可購買商品 | 有庫存就足夠 | 配送速度也是顧客體驗的一部分 | 最後形成 Fast Track In Stock |
| WBR | 數字異常就是找人問責 | 恐懼會讓團隊隱藏問題 | 指標要用來理解系統，而不是先判罪 |
營收、利潤、會員數等結果指標很重要，但它們大多告訴你「已經發生什麼」。管理者真正需要的是那些能被團隊控制、而且會推動結果的輸入指標。
困難在於，輸入指標不可能一次選對。Amazon 的做法不是假裝第一版就是科學真理，而是把「指標也需要反覆迭代」變成日常工作。
WBR 把大量指標放進固定節奏檢討，常同時觀察近期與長期趨勢、實際值與前期比較，並用顧客故事補足純數字無法解釋的情境。作者也描述曾有團隊把 WBR 變成非常痛苦的「災難會議」：參與者愈來愈多，主管用數字當場定罪，最後造成恐懼而不是學習。
這段失敗很重要，因為它提醒：再好的資料機制，如果變成羞辱與究責工具，就會讓人開始保護自己，而不是暴露真實問題。
WBR 成為 Amazon 廣泛使用的營運機制之一。它的精神不是「管理者看很多圖」，而是讓每個重要業務都有可持續觀察、可以採取行動、會隨理解更新的指標系統。
數據文化真正困難的地方不是蒐集更多數字，而是找到能改變行動的數字。而且指標不只衡量組織，也會重新塑造組織行為。