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

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

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

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

我看完最想留下的重點是：MVP 重在驗證關鍵假說。版本有多小不是唯一重點，更要看這次嘗試能讓我們知道什麼。

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

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

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

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

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

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

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

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

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

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

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

兩種情況，都可能叫 MVP。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— Adam｜metabiz 創辦人

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