原章：The Crystal Ball
Ken 加入 Apple 前，曾在 Eazel 做 Linux 桌面軟體。那家公司有很多聰明人與雄心，但多個技術工作彼此整合得不好；產品有缺陷、協作失靈，資金最後耗盡。這段經驗讓 Ken 對「聰明人加好點子自然會變成好產品」失去幻想。
2001 年他與 Don Melton 進入 Apple 後，被交付一個重要任務：Apple 想掌握自己的瀏覽器命運。團隊最初研究 Mozilla，面對約一百五十萬行龐大程式碼，六週左右仍然沒有找到令人信服的方向。
Richard Williamson 加入後，很快注意到另一個開放原始碼瀏覽器 Konqueror。他沒有先寫一份完整評估報告，而是把程式碼抓下來，用一些臨時方法與捷徑，幾天內拼出一個能在 Mac 上跑的粗糙 Demo。
這個 Demo 並不是可出貨產品。它比較像電影片場的背板：只要從正確角度看，就足以讓人想像完整世界。正因為它夠快、夠具體，團隊突然可以回答之前六週都回答不了的問題：這條技術路線有沒有值得繼續走的潛力？
| 故事節點 | 團隊原本怎麼做 | Richard 怎麼做 | 得到的啟發 |
|---|---|---|---|
| Mozilla 調查 | 深入理解龐大程式碼與整合問題 | 不再只研究既有路線 | 研究時間增加不一定會自然帶來方向感 |
| Konqueror | 若照正式產品標準，移植工作非常大 | 允許暫時捷徑，只求跑出核心體驗 | 早期 Demo 可以刻意不完整 |
| 幾天後的 Demo | 原本只有抽象評估 | 直接把瀏覽器放到 Mac 上操作 | 可操作成果比更多推演更容易形成共同判斷 |
| 看完之後 | 團隊仍不知道最終要多久 | 但知道值得往哪裡投入 | Demo 像「水晶球」，讓團隊看到可能的未來 |
專業工程師很容易認為「不完整就是不專業」。Richard 的做法卻反過來：在最早期，若目標是回答方向問題，把所有邊角都做完整反而可能浪費時間。
團隊接受 Konqueror 路線，並開始把一個為展示而拼出的 Demo 轉成真正可以在 Mac 上工作的瀏覽器基礎。Richard 也示範了一種 Ken 後來不斷沿用的習慣：不把已投入的時間當成繼續走錯方向的理由。 如果某條路不 promising，就放下，快速做下一個可以驗證的版本。
這條路最後成為 Safari 與 WebKit 的技術起點。對 Ken 個人而言，更重要的是工作方式的轉變：他不再把「先寫出完整計畫」視為必要起點，而更相信快速、具體、可操作的 Demo 能帶動下一輪更好的判斷。
Demo 的價值不是預言未來會成功，而是把未來的一小部分提早帶到今天，讓團隊可以用眼睛、手與判斷去檢驗。