C.1 需求發掘與產品驗證案例#

本附錄收集軟體工程史上的經典案例。與正文不同的是，案例的價值不在於「學會某種技術」，而在於「看見某種模式」——尤其是需求發掘、產品定位與組織決策這些「附屬性困難」之外的本質性困難（見 1.1 節、1.2 節）。本節的四個案例，主角都不是先寫程式碼，而是先「驗證人們是否真的需要」：Dropbox 用一支影片、Nokia 用人類學家、騰訊用內部賽馬、Slack 用一次轉向。

案例一：Dropbox——一支影片當作 MVP#

背景：2007 年左右，創辦人 Drew Houston 常常忘記帶隨身碟。當時的檔案同步工具不是操作複雜，就是同步常出錯。他想做一個「背景自動同步」的軟體，但這類產品技術門檻高、開發成本高，而市場上已有許多檔案傳輸工具，投資人與質疑者認為「需求不明確，使用者根本不懂什麼是同步」。

策略：把「展示影片」當成 MVP。Houston 沒有先投入數百萬元開發完整產品，而是錄了一支三分鐘的產品示範影片，貼到 Hacker News。影片剪得像產品已經完成：把檔案拖進 Dropbox 資料夾，其他裝置立刻出現。事實上後端只有非常初期的原型，甚至連大量使用者都撐不起。他還在影片中藏了 Hacker News 才懂的梗，讓技術社群產生「這是我們自己人」的親切感。

結果：影片病毒式傳播，等待名單在 24 小時內從 5,000 人暴增到 75,000 人。這群「願意留下 Email 排隊下載」的人，向 Y Combinator 等投資人強烈證明了需求是真的，也決定了產品的開發方向。

啟示（連結本書）：這正是 2.2 節「用原型挖需求」的最佳示範——原型不一定是能跑的程式，只要能讓使用者「看到價值」就夠了。它同時說明 AI 時代的趨勢：因為 AI 大幅降低了原型製作成本（2.6 節），「先驗證再開發」會比過去更容易，也更應該做。

graph LR
    A[痛點: 常忘帶隨身碟] --> B[決定做同步軟體]
    B --> C[做出三分鐘展示影片]
    C --> D[貼上 Hacker News]
    D --> E[等待名單 5000 → 75000]
    E --> F[向投資人證明需求]
    F --> G[才正式擴大團隊開發]

案例二：Nokia 的人類學家——田野調查發掘隱形需求#

背景：2000 年代初期，Nokia 聘請設計研究員 Jan Chipchase 穿梭於印度、烏干達、巴西、中國等新興市場。芬蘭總部的工程師從已開發國家的使用習慣出發，設計出的產品往往不符合新興市場的真實生活。Chipchase 用民族誌（Ethnography）的田野調查，走入村莊、住進民宅，觀察使用者一天的生活，發現了坐在辦公室裡永遠想不到的需求。

關鍵發現：

這些設計把 Nokia 推上新興市場數億台的銷量，其中「手電筒」在缺乏電力的村莊裡幾乎是救命功能。

啟示（連結本書）：問卷調查無法取代真實觀察——使用者往往「說不出自己需要什麼」，甚至把不便視為理所當然（2.4 節「邊界條件」的延伸：使用脈絡也是需求的一部分）。功能的價值高度依賴使用情境；同一個功能在芬蘭是花俏，在印度鄉村是剛需。這也呼應 2.5 節「Red Teaming」的精神：最好的需求分析師，是在現場「用眼睛提問」的人。

案例三：微信與 QQ——內部賽馬與自我顛覆#

背景：2010 年左右，手機網路時代來臨。QQ 是 PC 時代的即時通訊霸主，但背負太重：介面複雜、功能臃腫、強調線上/離線狀態。小米推出專為手機設計的「米聊」，迅速瓜分用戶。騰訊創辦人馬化騰決定：與其被別人顛覆，不如自己顛覆自己。他允許內部多個團隊同時開發行動通訊軟體——無線事業部在 QQ 基礎上做行動化改進，廣州研發中心張小龍則請命另起爐灶做全新的行動通訊工具，也就是後來的微信。

關鍵差異：

結果：微信 2011 年上線後憑語音訊息、搖一搖、朋友圈爆發，擊敗米聊，也為騰訊搶下行動時代的「船票」。但 QQ 也未被消滅——微信接管成年人與職場，QQ 退守青少年與個人化社群，形成雙產品並存。

啟示（連結本書）：別讓過去的成功變成創新的包袱；場景決定形態，行動端講究隨時隨地、碎片化、真實身份，就不能沿襲 PC 的邏輯。更值得注意的是組織面：透過「內部賽馬」讓新團隊擺脫舊產品 KPI 的束縛，才能真正做出破局的產品——這正是第 12 章「人機協作流程」裡「要保護自主探索空間」的同一條原理，只是主角從團隊換成了 Agent。

案例四：Slack——從失敗遊戲中轉向#

背景：Stewart Butterfield 帶領團隊開發大型線上遊戲《Glitch》，數年後市場反應平平、商業失敗。但團隊在開發期間為了跨區協作，自己寫了一套內部通訊工具——包含聊天室、檔案傳輸與 IRC 的概念。當遊戲宣布關閉、公司即將解散時，團隊突然意識到：這套內部工具比市面上所有企業通訊軟體都好用。

結果：團隊果斷轉向（Pivot），把這套工具商業化，誕生了 Slack——企業軟體史上成長最快的 SaaS 之一。

啟示（連結本書）：真實需求往往藏在「為了解決自己問題而順手做的小工具」裡。這跟 2.2 節「原型」與「觀察真實行為」一脈相通：不要只盯住原本規劃的目的地，也要留意主要業務之外的副產品。放到 Agent 協作語境，就像 9.4 節「糾正機制」與 12 章講的：失敗的軌跡與意外的副產品，常常是比計畫本身更珍貴的訊號。

想一想#

1. 假如你要驗證「AI 幫學生做考古題筆記」的需求，可以設計哪些比問卷更可靠的驗證方式？（提示：參考 Dropbox 的「行為而非意見」）
2. Nokia 的手電筒功能說明「功能價值高度依賴情境」。你能舉出一個在台灣「意義不大」、換一個情境就「是剛需」的功能嗎？
3. 微信採用了「內部賽馬」。如果放進本書的 AI 開發脈絡，一個人同時跑好幾個 Coding Agent 競爭同一個任務，你覺得是浪費還是必要？為什麼？

本章小結#

需求的難，在於使用者說不出自己要什麼。Dropbox 用影片驗證、Nokia 用田野調查、騰訊用內部競爭、Slack 用轉向——四條路共用同一句話：真正的需求要用真實行為來證明，而不是用想像來宣稱。在 AI 讓原型與驗證變便宜的時代，這個原則不是被淘汰，而是變得更重要。