Groupon 的 WordPress 部落格開端#
Groupon 是史上成長最快速的公司之一——但一開始是 20 人買了兩份披薩特價的餐廳優惠券。
- 創辦人 Andrew Mason 原本想做一個「社群行動平台」叫做 The Point。
- 2008 年底，創辦人決定嘗試新方向，用極簡的最簡可行產品（MVP） 測試：
- 用一個 WordPress 部落格改造成 Groupon 網站，每天貼一篇新優惠。
- 第一款 T-shirt 商品：寫著「紅色、尺寸 L；要其他顏色或尺寸？Email 我們。」
- 第二代網站用 FileMaker 做：用 AppleMail 寫腳本把 PDF 優惠券寄出去，一天手工寄出 500 份。
- 如此陽春的手作版本，卻是 Groupon 邁向上市、覆蓋 375+ 城市的起點。
最簡可行產品（MVP）的定義#
MVP 不一定是你能想到「最小的產品」，而是能以最少努力走完一次完整「打造—衡量—學習」迴路的最快路徑。
與傳統產品開發的差別：
- 傳統：需要漫長孵化期以追求「完美」。
- MVP：目標是啟動學習、而非結束開發；不只為了回答技術或設計問題，更是為了檢驗商業的根本假設。
第一個產品不必完美#
IMVU 當年向創投募資時覺得很丟臉：產品品質低、成果規模小（每月收入如同曲棍球棒圖，但僅從每月 $8,000 漲起）。但——
產品要先在早期採用者中成功，才能在主流市場爆發。
早期採用者是一群特殊的顧客：
- 他們接受、甚至偏好 80% 的解決方案。
- 他們用想像力補足產品的不完美。
- 他們希望自己是第一個使用者，好在朋友面前炫耀。
- iPhone 初代缺少複製貼上、3G、企業信箱功能，早期粉絲仍排隊搶購。
- Google 一開始只能回答 Stanford 或 Linux 的問題，卻未阻擋熱情使用者。
給太過完美的產品反而會讓他們起疑：「如果大家都能用，我搶第一有什麼好？」
簡化原則#
當在 MVP 要放哪些功能上陷入掙扎時，直接簡化吧。
例：某服務用「一個月免費試用」導流。價值假設：顧客會為了看到某組功能而註冊試用。商業模式中常寫「預估 10% 看到試用的人會註冊」。
那行字應該用紅色粗體寫：我們假設 10% 的顧客會註冊。
創業者通常先造完整產品、才觀察反應——這其實本末倒置：若最後沒人註冊，所有堆上去的功能都白費。先只實作最少功能、迅速驗證註冊行為是否發生，才是正道。
三種 MVP 技術#
1. Video MVP：Dropbox 案例#
Drew Houston 創辦 Dropbox，用於跨平台檔案同步。
- 技術極具挑戰：需整合 Windows、Mac、iPhone、Android 等系統；更難的是「好用到像魔法」。
- 團隊全是工程師背景，自然假設「做出好產品，結果會自己來」。
障礙：VC 不買單#
Drew 去募資，投資人反問：
- 「你真的試過同類產品嗎？」→「試過。」
- 「它們好用嗎？」→「幾乎都『不好用』。」
投資人仍覺得市場擁擠、沒有明顯痛點。
解法：拍一部影片#
Drew 拍了一段三分鐘影片：
- 自己旁白、螢幕錄影展示產品；
- 內含專給早期採用者的梗（把什麼檔案放進 Dropbox 同步）；
- 影片本身就是 MVP。
效果：一夜間把 beta 等候名單從 5,000 擴大到 75,000。Dropbox 後來估值超過 10 億美元。
這部影片驗證了 Drew 的孤注假設——顧客想要這個產品。他們報名不是因為焦點小組這麼說、不是因為對標其他成功產品，而是真的願意報名。
2. Personal / Concierge MVP：Food on the Table（FotT）案例#
FotT 提供每週菜單與購物清單、根據家庭偏好最佳化當地超市售價。表面上需要一套複雜系統：
- 全美成千上萬家超市的商品資料庫；
- 專業主廚設計的食譜；
- 比對顧客偏好與超市商品的演算法。
但 FotT 從一名顧客開始：
- 創辦人 Manuel Rosso 與產品副總 Steve Sanderson 到當地超市、媽媽社團訪談。
- 多數拒絕（非早期採用者）；只招到一位願意付費。
- 為這一位顧客提供親手專人服務：
- CEO 每週到她家拜訪，帶購物清單與食譜；
- 專人為她挑選食譜；
- 每週親收 9.95 美元。
以傳統效率衡量極其糟糕——CEO 親自服務一位顧客。但以精實新創視角，這是劃時代的進展：他們每週學到更多關於「成功所需」的知識。
累積數位客戶後，才開始投資把流程自動化：
- Email 送食譜清單取代家訪；
- 軟體化商品篩選；
- 最後改用信用卡線上付款。
發展路徑：把已證實有效的活動規模化——而不是把資源投入可能未來成功的想像。
3. Wizard of Oz / 「假裝自動化」MVP：Aardvark 案例#
Max Ventilla 與 Damon Horowitz 想做一種新搜尋引擎，能回答主觀問題（Google 能回答「世界最高山？」，不能回答「看完球賽後哪裡適合喝一杯？」）。
- 他們花 6 個月尋找該做什麼——但不是拉長分析、而是連續嘗試六個有功能的原型：
- Rekkit、Ninjapa、The Webb、Web Macros、Internet Button Company、Aardvark。
- 每個原型用 2–4 週做完，邀 100–200 位朋友試用。前五個都失敗。
Aardvark 是第六個：利用 IM 介面讓使用者提問，Aardvark 在使用者的社群中找朋友回答。
- 測試時用 Wizard of Oz 方法：顧客以為在與真實 AI 互動，其實背後是人在回答。
- 回答關鍵問題：若技術難題都解決了，人們會用嗎？有價值嗎？
- 系統讓 Max 與 Damon 能持續轉向，放棄好聽但不可行的概念。
- 最終，Aardvark 被 Google 以約 5,000 萬美元併購。
品質與設計：MVP 沒說的那一半#
MVP 看似忽略品質，實則不然。但品質的定義取決於「顧客」——而新創最大的不確定，正是不知道顧客是誰。
如果我們不知道顧客是誰，我們就不知道什麼是品質。
低品質 MVP 能孕育出高品質產品#
- Craigslist 初代只是簡陋的 Email 公告板。
- Groupon 的第一張優惠券只是手工 PDF。
- IMVU avatar 案例：受限於技術，avatar 無法在場景裡走動。團隊改用「瞬間傳送」 替代：點選目的地，avatar 消失再出現在新位置——連動畫、音效都做不好，團隊覺得「爛透了」。
- 結果：顧客把傳送評為三大最愛功能之一，並認為比 Sims 更好。
「顧客不在乎你花多少時間做，他們在乎的是有沒有用。」
所以 MVP 也是一種測試假設：如果顧客反應如預期，確認方向；若顧客嫌棄設計，再投資「好設計」也不晚。
例外：若某些品質缺陷會干擾學習本身（例如太多 bug 以致無法衡量留存率），則必須先投資把品質提升。
一條簡單規則#
做 MVP 時：任何無法直接帶來你想要的學習的功能、流程或活動，都可以丟掉。
打造 MVP 的現實障礙#
MVP 不是無風險，真實與想像中的風險都可能阻礙你。最常見的問題有：法律、競爭、品牌、士氣。
法律風險#
- 多國專利申請期會因產品公開而被觸發。
- 如要國際專利保護，可能需更嚴格條件。
- 多數產業，專利主要用於防禦競爭。
- 除非你在需要專利保護的產業（例如生技），否則 MVP 的法律風險通常遠小於學習帶來的好處。
- 建議：找懂你產業的律師確認風險。
對競爭的恐懼#
最常被當成 MVP 藉口的，其實是「怕競爭對手偷點子」。萊斯常給反證：試試看把你的點子寄給大公司的產品經理，看他會不會理你。
- 大公司產品經理多半忙於自家點子。
- 若對手看到你的 MVP 就能做得更好、更快，代表你本來就有比保密更深的問題。
- 唯一的勝出方式：比別人學得更快。
品牌 / 商譽恐懼#
- 在大公司內做創新尤其敏感，擔心傷害母品牌。
- 解法：用不同品牌發佈 MVP。
- 長期商譽只有在「高調發表」失敗時才被傷害。新創反而享有少量顧客、默默無名的優勢——就在被忽略時做實驗，等產品真的能吸引顧客再正式上市。
團隊士氣：MVP 帶來壞消息的心理衝擊#
- MVP 通常揭露不好的事實：多少顧客不買單、哪些假設錯了。
- 傳統產品開發團隊訓練在「做決策不容許太多不確定性」——「瀑布式（waterfall）」開發的核心。
- 若 MVP 失敗，傳統思維是埋葬產品、換個題目。
解法：事前承諾會堅持迭代。成功的創業者在看到問題時不立刻放棄，但也不盲目堅持——他們把韌性與彈性結合在一起。MVP 只是第一步；多輪迭代後，若部分策略確實失敗，就到了轉向（pivot） 的時候。
從 MVP 到創新會計#
MVP 尤其容易讓外部利害關係人（如 CFO、投資人）失去信心——畢竟當初你保證產品會改變世界，結果顧客卻寥寥無幾。
- 傳統管理下，失敗只有兩種原因：執行不力，或計畫不周。兩者都不可原諒。
- 但創業經理人的情境不同：他的計畫本來就充滿不確定，失敗本來就可能帶來有價值的學習。
- CFO 或 VC 如何分辨「這是真實學習」vs「這是藉口」？
精實新創的答案是創新會計（innovation accounting）——一套取代傳統會計、專為新創設計的衡量系統，讓創業者客觀地展示進展與驗證式學習。這是下一章的主題。