原章：Convergence
Giggly Demo 證明自動校正方向有潛力，但「看見潛力」和「可以出貨」之間仍隔著很長距離。Ken 必須把字典、按鍵位置、詞頻與觸控誤差變成一套穩定演算法，同時整個 Purple 團隊也在修正瀏覽器、觸控、App 與硬體的細節。
Ken 最後形成 pattern skew 演算法：比較實際觸控形成的幾何圖形與字典中理想字形模式需要「移動多少」才能吻合，再結合字詞使用頻率選出最可能的結果。即使演算法定型後，他仍花了數月持續調整。
到了 2006 年秋天，軟體開始進入真正的出貨收斂期。Ken 第一次摸到接近正式工業設計、真正可以獨立運作的 Purple 手機時，在 Notes 裡打字，自動校正已經能順利工作。這一刻讓他清楚感到：手機終於開始像一個可以賣給人的產品。
但越接近發表日期，壓力越大。團隊以 Radar 追蹤錯誤，每天看 bug 數量能否朝出貨日期下降。Ken 也寫到同事因壓力爆發、Kim Vorrath 甚至把辦公室門摔到門把壞掉，被困在裡面，最後由 Scott Forstall 用鋁棒把她救出來。
| 故事節點 | 正在收斂的東西 | 工具／做法 | 真正的作用 |
|---|---|---|---|
| 自動校正 | 觸控誤差與候選字 | pattern skew＋使用頻率 | 把人的近似動作轉成合理意圖 |
| Purple 整體 | 硬體、App、手勢與系統 | 實機生活使用＋持續回饋 | 確認各部分能一起形成產品 |
| 出貨階段 | 大量已知錯誤 | Radar 與每天的 bug 趨勢 | 判斷團隊是否真的朝可出貨狀態前進 |
| 日常設計 | 每一輪 Demo 的好壞選擇 | Demo → feedback → next demo | 形成作者所稱的 creative selection |
「Convergence」很容易被誤解成產品成功的秘密：只要把 bug 修到接近零就能做出好產品。Ken 明確否定這個想法。所有成熟軟體團隊都會除錯、趕出貨；這只能幫助一個產品變得可靠，不能把一個平庸概念修成偉大產品。
作者回頭看 Apple 的真正做法，發現團隊其實從專案很早就一直在「小型收斂」：每次 Demo 都迫使大家判斷什麼留下、什麼修改、什麼刪掉，再把回饋做進下一個 Demo。
他把這個循環命名為 creative selection：像人工選擇一樣，不斷製造變異，再依共同品味與產品目標保留較好的部分。它不是 Apple 當時正式使用的詞，而是作者事後為自己經歷的工作方式取的名字。
到 2007 年 1 月，Apple 正式發表 iPhone；Ken 在發表隔天還把「iPhone」這個新產品名稱加入自動校正字典。產品發表不是「工作完成」，而只是多年 Demo 與修正第一次被外界看見。
偉大產品不是最後靠一場品質衝刺產生，而是在此前數百個小選擇中逐步形成。真正要管理的是每一輪變異與選擇的品質。