先做一個小版本，真的就算驗證了嗎？

最近看了理性避難所談 MVP 的影片，裡面用網路賣鞋的例子，讓我重新想了一次我們口中的先做一版。

影片以 Zappos 的早期做法為例：先把鞋子的照片放到網路上，有人下單，再去取得商品、完成寄送。它用這個故事說明，在投入完整的倉儲與流程之前，可以先確認一個更前面的問題：有人願意這樣買鞋嗎？

Zappos 賣鞋的例子出自這段影片。它給我的提醒，是先挑清楚要驗證什麼，而不是一開始就把所有事情做齊。

我看完最想留下的重點是：MVP 的重點，不在 MV，也不在 P，而在於你要做什麼實驗。

不是先決定做一個多小的產品，而是先決定想驗證什麼，再決定需要做多少東西。你相信什麼？哪個假設還不確定？看到什麼結果，才會決定繼續、調整或放棄？

這也接近 Lean Startup 的原意：透過嘗試與觀察取得學習，而不是把小版本本身當成目的。中文有人稱它為「精益創業」，台灣出版的書名則是《精實創業：用小實驗玩出大事業》。

除了賣鞋，我也想到 Dropbox 的早期示範影片。創辦人 Drew Houston 分享過這支影片的故事：用具體的示範，讓人看懂原本不容易解釋的使用方式，吸引大家注意。

對我來說，這個例子的重點不是「拍一支影片就能創業」，也不是 Dropbox 當時完全沒有開發產品。而是，當你想先確認人們能不能理解、對這種用法有沒有興趣，示範影片可以是實驗的一部分。不必把所有正式營運的東西都補齊，才開始觀察反應。但有人感興趣，也不等於已經證明長期使用、付費和維運成本都成立。

Webvan 則讓我看到另一面。這家公司做線上生鮮雜貨配送，曾參與 Webvan 的 Ben Foster 回顧，他們在需求還沒跟上之前，就先建立了昂貴的倉庫與訂單配送設施，準備大規模營運。

這不是說倉庫不重要，而是順序需要想清楚。我的理解是，在投入那些不容易回頭的建設之前，應該先問：有沒有足夠的人，願意以足夠的頻率購買？這樣的需求，能不能支撐配送與營運成本？不能把「大家應該會需要」直接當成答案，再把這個假設蓋成一座倉庫。

三個例子放在一起，給我的提醒不只是少花錢。Zappos 先試著完成買鞋這件事，Dropbox 用示範讓人理解與表達興趣，Webvan 的回顧則提醒我們，不要在需求與商業模式還沒站穩時，就先把規模建起來。它們面對的問題不同，實驗也不該長得一樣。

所以我說的不是「先求有，再求好」，而是先用足夠小、但能回答問題的實驗，決定下一步值不值得做。把該控制的品質輕忽掉，只能得到一個做得不好的版本，不一定得到可信的答案。

但一個實驗也有它的範圍。有人願意下單，不會自動證明後面的物流、成本與長期經營都成立。知道了一件事，還要知道哪些事尚未有答案。

我想在新專案開始之前，和提出需求的人先確認：第一步做完，要用什麼結果決定繼續投入。

對方不一定知道怎麼描述情境，也不一定能先替我們訂好指標。我們可以根據已知的困擾，先整理一個候選做法，把想確認的問題、要觀察的結果，以及還不能保證的地方拿出來，請他修正。

驗證方法由我們協助設計，不是要求客戶先學會 MVP，才能開始合作。需要他投入多少時間、提供哪些經授權的資料，也要一起說清楚。

如果你正在評估一個新服務，還不知道使用者會不會用、願不願意付費，這個問題會比先排出完整功能更早需要回答。

聽到一個新需求，很容易開始想，這套東西要有哪些功能。

要不要 App，要不要登入，要接哪些資料，後面是不是也需要管理介面。功能一項一項加進去，計畫逐漸完整，事情也好像開始往前了。

放回剛才的賣鞋例子，我會停在一個問題上：如果我們只是把這份功能計畫縮小一點，就知道它值得做了嗎？

我們說先做一個版本時，其實可能在談不同的事情。

有時客戶已經很清楚自己需要什麼，工作流程和交付範圍也確認了。第一個版本，是讓那些已經說好的工作先能使用，再繼續改善。

但有時我們還不知道，這個問題是不是足夠重要，使用者願不願意改變習慣，或對方會不會付費。我們卻已經開始規劃，要用多少時間把它做出來。

兩種情況，都可能叫 MVP。

需要回答的問題卻不一樣。

如果我們還在確認需求，第一步也許不必把整套系統做出來。可以先選一個真實情境，拿一份樣本，由人協助完成一次，看看對方最在意的到底是哪一段。

假設要處理的是找資料，就先看一次真實查找。現在要多久、會找錯什麼、找到之後能不能往下做。這些還沒看清楚之前，多做一個漂亮介面，不一定會讓答案更明確。

如果對方只想先看我們能做什麼，也可以用脫敏或示意資料呈現一段候選做法，讓他更容易指出哪裡不合現場。但示範能做出來，和真實使用能改善，是兩件事。後面的判斷，仍要回到實際工作核對。

我也會想先約定，看到什麼結果，值得繼續往下。

對方說很有意思，是一種回應。願意安排實際使用，或討論付費與導入，則是另外一些回應。不能全部算成同一件事。

資料一時拿不出來，也不能直接判定他沒有需求。可能是權限還沒取得，也可能是我們要求他整理的東西太多。要先看能不能縮小到一份樣本、一次操作，或找對能授權的人。若必要證據始終無法取得，就清楚說明目前能做到哪裡，不把示範當成已驗證的成果。

如果結果不如預期，也要有機會停下來想。問題可能不重要，方法可能不適合，也可能只是挑錯了使用情境。先知道是哪一個，才有辦法決定下一步。

這不代表所有工作都該隨便做一做。

涉及客戶資料、付款或專業判斷，該有的權限、審核和測試，仍然需要。可以縮小要驗證的範圍，不能把必要的責任一起縮掉。

對已經答應的開發與交付，也不能事後用一句只是 MVP，就把原本的承諾拿掉。

我想調整的是更早的那個時刻。

當我們還在決定要不要投入時，先把最不確定的地方寫清楚，找一個有機會得到答案的做法。不要等整套東西都完成，才開始問，有沒有人真的需要。

下一次談新專案，我想先留一點時間給這個問題。

第一個版本完成後，我們希望比現在多知道哪件事？

— Adam｜metabiz 創辦人

延伸參考：理性避難所｜MVP 與精益創業