最近超多人來問我關於做 App 的事，特別是那個很紅的詞，MVP。但我發現，天啊，十個人裡面大概有九個都搞錯 MVP 的意思了。大家把它當成「App 的第一版」，然後砸錢、花時間，最後做出來一個四不像，市場根本不買單。說真的，這條路我看了太多人摔倒了。
所以今天想來聊聊這個，到底什麼才是真正能幫你省錢、驗證點子的 MVP（Minimum Viable Product，最小可行性產品）。跟你想的可能完全不一樣。
重點一句話
真正的 MVP 不是你 App 的 1.0 版，它是一個用完就該丟掉的實驗工具。它的唯一目的，就是用最少的錢和時間，去驗證你那個最核心、最大膽的假設是不是真的有人要。
一個簡單例子：跑步計時器 App
我們來想像一下。你想做一個給田徑跑者的單圈計時 App。好，這時候你的核心假設是什麼？應該是這個：
「田徑跑者需『要』一個單圈計時 App。」
聽起來像廢話對吧？但在你真正開始燒錢寫 code 之前，所有事情都必須繞著這句話轉。任何跟驗證這句話無關的功能，都是在浪費生命和錢。
這時候創業者最常犯的錯就來了：
「欸，我們可以加個計算平均圈速的功能嗎？感覺很酷！」
等等，停一下。這個「平均圈速」功能，有助於我們驗證「跑者需『要』一個單圈計時器」這件事嗎？老實說，可能沒有。那是個 nice-to-have 的東西，是錦上添花，但不是我們現在要測試的核心。
不過呢，如果你的想法是這樣：
「我的計時器跟別人不一樣！它是用 GPS 自動偵測，跑者經過終點線不用自己按鈕。」
喔，那情況就完全不同了。這就是你的獨特賣點（USP）。你的 MVP 就應該要圍繞著這個 USP 來打造。所以，你的假設其實應該要更精準一點：
「田徑跑者需要一個『全自動』的單圈計時 App。」
看到差別了嗎？這樣一來，那個 GPS 自動計時功能就不是「多加的」，而是整個 MVP 的心臟。你做的所有事，就是要去證明這個「全自動」是大家想要的。其他功能？全部砍掉，之後再說。
怎麼做，或是說，怎麼想才對
好，觀念溝通完，那具體來說，一個「正確」的 MVP 應該長怎樣？我直接做個對比表格，你看完應該就懂了。很多人，包括一些接案公司，嘴上說做 MVP，但其實做的是右邊那個「第一版 App」，那根本是兩回事。
| 大家以為的「第一版 App」(The Wrong Way 👎) | 真正的「拋棄式 MVP」(The Right Way 👍) |
|---|---|
| 目標是要做出一個功能完整、可以上架、最好能開始賺錢的東西。 | 目標只有一個：驗證那個最關鍵的假設。像個科學實驗，不是在做生意。 |
| 會在 Google Play 或 Apple App Store 公開上架，給所有人下載。 | 根本不會上架。通常是在一個受控的環境下（例如你人在旁邊），找幾個精準的目標用戶來測試。它可能陽春到連登入功能都沒有，所以也過不了商店審核。 |
| 程式碼要寫得穩固、有架構，因為這是未來所有功能的基礎。 | 程式碼能跑就好，越快越髒越好。因為測試完，整包 code 都要丟掉。對，你沒看錯，直接扔進垃圾桶。 |
| 會用敏捷開發（Agile），每兩週衝刺一次，不斷加新功能。 | 敏捷開發在這太慢了。我們目標超明確，直接規劃好，一口氣把它做完。中途不改規格、不加功能，除非是核心假設變了。 |
| 希望能直接帶來收入，所以可能會花時間做金流系統。 | 完全不考慮賺錢。做金流系統花的時間和錢，遠比你從這幾個測試用戶身上賺到的多太多了。這是個成本，不是資產。 |
大家最常搞錯的幾個點
我知道，看到上面那張表，你心裡一定一堆問號。特別是「把 code 丟掉」這件事，聽起來就很反直覺。
「蛤？把 code 丟掉？這樣不是更浪費時間和錢嗎？」
對，從「整個專案的總成本」來看，是多了一點點工。我們等於把核心功能寫了兩次：一次是 MVP 裡的快速骯髒版，一次是驗證成功後，在正式版 App 裡寫的乾淨、有架構的穩定版。
但你要換個角度想。在點子還沒被驗證之前，你口袋裡的錢（或你老闆的錢）是超級有限的資源。我們的目標應該是「用最低的成本，最快地知道這點子行不通」，而不是「怎麼讓專案總成本最低」。
說得更白話一點：MVP 是你用自己的錢在賭博，賭贏了，後面的正式開發就有機會用投資人的錢了。你當然要盡可能省自己的錢啊！花 10 天做一個拋棄式 MVP 發現點子不行，損失就是 10 天的錢。但如果你花 30 天做一個「比較像樣的第一版」，結果市場不要，你就虧了 30 天的錢。哪個划算？
這個觀念跟我們常聽到的 Lean Startup 提到的迭代有點不同。很多人會秀那種「滑板 → 滑板車 → 腳踏車 → 摩托車」的圖，好像 MVP 就是滑板。但在 App 開發的世界，打造一個可以迭代的「地基」本身就很花錢。在不確定地基上蓋的房子有沒有人要住之前，先用樂高蓋個模型試試水溫，才是明智之舉。那個樂高模型，就是你的拋-棄-式-MVP。
「那到底要做 Android 版還是 iOS 版？」
這要看你的假設。如果你的目標用戶群明顯偏好某個平台，那當然就只做一個。或者，像有些測試情境，你會自己提供設備給用戶，那選哪個平台就更沒差了。
除非你的假設是「想測試不同平台用戶的行為差異」，不然千萬不要一開始就兩個平台都做，成本直接翻倍，完全不符合 MVP 精神。
「這樣的 MVP 大概多少錢？要花多久？」
這個問題很現實。如果你的假設夠單純，一個功能點的 MVP，找個 freelance 開發者或小團隊，時間大概落在 1 到 4 週。如果超過 8 週，那可能就要回頭檢討一下，是不是你的假設太複雜了，把太多東西混在一起測。
至於費用，原文作者提到在歐洲，一個 MVP 大概是 3,000 到 10,000 歐元。我自己是覺得...這個數字可以當參考。換算台幣大概是十萬到三十幾萬。說真的，在台灣找接案或小團隊，這個價錢也差不多是這個區間，但可能要看你驗證的功能複雜度。這筆錢是拿來「買答案」的，而不是「買一個 App」。相較於一個正式版 App 動輒破百萬的開發費用，這筆「學費」其實非常划算。
而且，在台灣的創業生態裡，像是國發會（National Development Council）底下有很多給新創的補助資源，他們在審核時，其實也很看重你是否有做過類似的市場驗證。有一個經過驗證的 MVP 成果，絕對比只有一份 PPT 來得有說服力多了。
總結一下吧，我自己是覺得，把 MVP 當成一個「省錢的失敗機會」會是更健康的心態。你不是在打造一個會成功的產品，你是在花一筆小錢，去測試你所有可能失敗的環節，然後避開那個最致命的失敗。
所以，下次當你又有個絕妙的 App 點子時，先別急著找人報價做 App。先問自己：
「我最需要被驗證的那個『瘋狂假設』是什麼？以及，我能用什麼『最不像 App 的方法』去得到答案？」
想通了這個，你大概就省下了一大筆冤枉錢了。
換你說說看：如果你現在有一個 App 點子，你最想驗證的那個核心假設會是什麼？在下面留言分享一下，看看大家的點子有多酷！說不定能激發出更多火花。😄
