如何透過最小可行產品（MVP）測試創業想法
我在 CakeResume 的精實創業實例
大家好，我是 CakeResume 的創辦人劉君羿。2016 年 3 月我離開了我的第一份工作，並創辦 CakeResume。
前一年半，在極有限的金費和人力下（只有我一人和我工作一年半存的錢），我學會了如何把每一分資源最大化；秉持著精實創業的 80/20 法則，盡可能只用 2 分的力氣就達到 8 分的效果，讓 CakeResume 從一個陽春的線上履歷編輯器成長為一個有十萬多名使用者的人才平台。
這段期間，我學到的最寶貴的經驗便是擁抱資源上的限制。從 0 到 1 的過程中，新創公司應專注於欲解決的問題的核心；而資源上的限制能迫使你專注在核心問題上；你必須學會取捨，知道什麼必須先完成、什麼可以等到未來有餘力時再補上。這便是最小可行產品（Minimum Viable Product）的概念。
然而，儘管大多數想創業的人都有這個概念，但在沒有足夠的經驗下，仍然無法做出精準的判斷，堅持在不必要的工作上，造成資源（包含時間）的浪費。
所以，關鍵問題在於「到底何為最小可行產品？」然而這的問題會因不同的題目、團隊的強項、擁有的資源等而異，並沒有一個普世的法則。我也是經過一段時間摸索，才逐漸知道怎麼取捨。因此我希望透過分享我的經驗，讓其他團隊做為參考，減少摸索過程，更快的找到適合自己的精實風格。
心理建設——學會接受不完美
學會接受不完美是一個比想像中還要困難的課題。
最小可行產品的概念知易行難；儘管大部分的新創團隊都聽過最小可行產品的概念，但實際操作起來，卻往往無法克服自己的疑慮；特別是在打算發布產品前，很容易近鄉情怯，心想「或許等完成這項功能再發布會更好」，並深怕發布後無人問津。
舉例而言，我大學時曾經嘗試做一個網路二手書店，特色是可以很快速上架大量二手書，同時還能將已上架的書籍匯出相容於拍賣平台的 excel 檔，以方便快速上架到拍賣平台。當時雖然我已經找到合作的實體二手書店，但卻遲遲沒有推出產品，而是把時間花在購物系統上，例如購物車、合併運費規則、運送方式選擇等等，此外我還蒐集了數十萬本書籍資料，打算一上線就讓平台上可以搜尋到所有書籍。如此花了半年多耽溺於產品開發，然而等產品上線後，卻因為沒人想使用而草草結束。
如果讓我重新測試這項想法，我會先釐清我要解決的問題的核心是什麼；以這個例子而言，就是「讓二手書商可以很容易將大量二手書上架到拍賣網站上」。弄清楚問題核心後，會發現其實我根本不需要為此而重新架設一個二手書交易平台，只需要先做一個快速上架工具即可，實作的困難度也會大幅降低。等完成後，就能直接讓我合作的書商使用；如果對方覺得很有用，就能推廣給其他書商；等未來真的很多書商使用這個上架工具時，再逐漸打造自己的交易平台即可 — — 亦即循序漸進的推出不同功能，而非等開發完所有功能後一口氣推出。
值得注意的是，當時我也知道最小可行產品的概念，然而投入一些時間開發後，便會開始擔心如果產品不夠成熟就推出，可能會讓早期使用者感到不滿、打壞了品牌名聲、最後導致前功盡棄，因此不斷的延遲推出時間。
這是很容易能理解的心理狀態；試想，團隊早期花了許多心力總算構思、討論出一個似乎還沒有人做過的想法，並獲得所有共同創辦人的認同；之後又投入一段時間做出產品除雛形；如今卻要把這個在這段時間內朝夕相處的想法推到市場上接受無情的考驗，難免讓人卻步。而我也是經過好幾個專案的失敗才逐漸克服了這個障礙。
因此，在我們實際執行最小可行產品的概念之前，首先得先了解以下兩點，才能避免未來拘泥在自己的想法上，或者拘泥在產品的細節上。
a. 在經過驗證之前，想法是廉價的
沒有想法是完美的。有哪家公司現在所做的事情跟創業最初的想法是完全一樣的呢？一家公司現在所做的事是經過經營過程中不斷的市場調查、測試演變而來的。
同樣的，創業最初的想法也不會讓你成功；而是需要透過不斷的測試與修正，才能摸索出你的公司的真正價值。若是一開始就很看重自己的想法、認為這是獨一無二的發現，那麼就容易踟躕不前，或者無法適時放棄。
而要有效率的驗證自己的想法，唯有快速推出最小可行產品測試水溫，並及時地改變策略或者宣布失敗，才能避免資源的浪費。
b. 不用擔心最小可行產品有很多缺陷
最小可行產品的目的不在於讓目標客群感到非常滿意，而是只要能驗證目標客群是否如預期的對這項產品有興趣即可。因此，就算有三千個早期採用者對這項產品有很大的興趣，但卻因為功能不足或者有些 bugs 而感到不滿也無所謂，因為我們只要能夠判定這是個值得繼續走下去的題目即可；所以哪怕三千人都留下不完美的印象甚至收到許多負評也無傷大雅，畢竟這世上的人多的是，未來持續優化產品提升滿意度即可；況且收到負評總比推出後吸引不到任何人的興趣、什麼評論也沒收到來得好。
有了這兩點認知，確保將來你的想法和執行方式都保有極大的彈性、能夠敏捷調整後，我們就能開始探討最小可行產品的實際操作細節。
1. 盡早推出最小可行產品
最小可行產品的目的在於驗證你的命題。因此，這裡的秘訣是盡可能降低你的命題的複雜度，如此才能有效、精準、快速地進行測試；如果你的命題很複雜，那麼就應該拆成幾個較小的命題，並且按照重要程度依序驗證。
釐清了命題後，就需要制定最小可行產品的規格，並用最短的時間推出最小可行產品，以驗證你的命題。
以 CakeResume 為例，最初的想法是要做一個多媒體線上履歷工具。理想上，這個編輯器就跟現在的 CakeResume 一樣，有很多模板可以讓使用者自行排列組合，並能夠嵌入圖片、影片、投影片等多媒體元素，並且既能線上瀏覽也能下載 PDF；不過這實做起來很複雜，要開發這樣的編輯器至少要花半年以上；因此，我試著釐清我想解決的問題，得到的結論是「市面上沒有一個自由度高的網頁版履歷工具能在呈現學經歷的同時還能展示作品集」釐清問題後，便能發現只有三項功能是必要的：
- 履歷發布後必須提供線上版及分享連結（不需支援 PDF 版本）
- 高度客製化（不須拖拉式編輯器只需一個沒有格式的編輯器就能做到）
- 可以嵌入圖片（不用管可否嵌入影片和投影片）
如此一來，要測試是不是也有很多人也遇到跟我同樣的問題，只要有一個簡單版的文件編輯器（就像功能很少的 Google Docs）、並且編輯完可以發布成一個網頁就行了。
由於市面上已經有些簡單的文件編輯器，只要付錢購買程式碼就能安裝到自己網站上，因此我唯一要做的就是設計一個可以把我的訴求說明清楚的首頁、以及將履歷發布成網頁的流程即可。如此一來，實作的複雜度也瞬間從六個月以上變成兩週內即可完成。
善用 Landing Page（著陸頁）介紹最小可行產品
除了一個可以操作的最小可行產品外，更重要的是一個言簡意賅地說明這項產品訴求的著陸頁（也就是使用者點進你的產品連結第一個看到的畫面）。
著陸頁的功用在於讓人一眼看出你的產品想解決的問題。著陸頁上會有一個明確 Call to Action（可能是註冊、購買、訂閱、了解詳情等等），這個 Call to Action 的用意是來測試市場對你提出的解決方案是否有興趣。由於你的 最小可行產品可能不夠完整或者只是 beta 測試版，使用者不見得能完整體驗到你的解決方案；因此，你可以在登陸頁上的放上設計圖、介紹影片等來說明你的完整想法，並藉由追蹤有多少人點擊按鈕、註冊、提交 email、觀看影片等，來判斷市場對你提出的解決方案是否感興趣。
以 CakeResume 的小可行產品而言，由於我們是一個毫無知名度的履歷工具，許多第一次看到我們網站的人可能不敢貿然將自己的資料放到我們網站上，或者擔心會因為網站關閉等問題而白白浪費編輯時間。因此，我們的最小可行產品不要求早期採用者完整編輯完履歷（因為我們知道只有少數的人會走完這步驟），而是透過追蹤有多少人點擊登陸頁上的「Try it out」按鈕得知有多少人對於「高度客製化的多媒體線上履歷」感興趣。
某些時候，甚至可以只做一個登陸頁來測試自己的想法，不見得需要有一個可以操作或體驗的產品。特別是像實體商品、服務、線上課程等很有畫面的產品，不妨拍些照片或短片，寫些描述，並放上一個「訂閱最新消息」或者「取得早鳥優惠」按鈕，就可以測試市場水溫了。
Bonus — 做自己想用的產品
或許你會問「你是怎麼判定線上版、高度客製化、和可嵌入圖片是 CakeResume MVP 的必要功能呢？」原因很簡單，因為這是我自己的需求；當時就是因為我找不到具備這些功能的履歷編輯器才打算做 CakeResume 的。
做一個自己需要的產品有許多好處；這能幫助你判斷哪些是必要功能，以及你可以時常問自己會不會想用自家產品（如果不想，那是缺乏了什麼功能？）此外，就如同 Getting Real 一書中所說的，通常你會有這樣的問題，就表示世界上也會有一大群人跟你有同樣的問題。
A great way to build software is to start out by solving your own problems. You’ll be the target audience and you’ll know what’s important and what’s not. That gives you a great head start on delivering a breakout product.
The key here is understanding that you’re not alone. If you’re having this problem, it’s likely hundreds of thousands of others are in the same boat. There’s your market. Wasn’t that easy?
– 37signals. Getting Real
2. 開始推廣最小可行產品
哪怕產品再好，若是沒有行銷，也不會有人知道。
因此，當你認定最小可行產品已經完成，那就暫且放下想去優化它、加些新功能的衝動，專心地去行銷最小可行產品，不要輕易回到產品開發上！
以 CakeResume 為例，當我推出 MVP 後，一開始並不順遂；我嘗試各種管道推廣，包含在 Reddit 上分享、去 Quora 上回答其他人關於履歷撰寫的問題並附上 CakeResume 的網址等等，然而並沒有得太什麼回應，以至於我差一點就要放棄了。直到我分享到 Product Hunt 上，獲得不少好評，我才認定這個方向直得繼續嘗試，並且離職創業。
行銷一個全新的產品是一項艱鉅的任務；要將一個沒沒無名的產品推廣到有幾千名早期採用者必須經過許多嘗試。很多團隊在這個步驟遇到挫折後，便回去開發更多功能，試圖以技術解決問題；等到花了許多時間開發再推出後，仍然沒人有興趣使用，才知覺浪費了許多時間在沒有人感興趣的題目上。
假如真的不管怎麼行銷都乏人問津，那麽就應該重新評估你想解決的問題是否太小或者市場區隔太有限，並重新擬定產品方向或者放棄。
3. 從使用者回饋決定下一步該怎麼走
如果 MVP 進行順利了話，你便能獲得許多早期採用者的意見回饋。這些回饋將能幫助你決定下一個該加上的功能是什麼或者目前產品有沒有什麼可以改良的地方。
有一批早期採用者對產品的開發有很大的幫助。你可以試著與這些早期採用者保持聯絡，甚至面對面訪談他們的需求；等未來你有新的想法時，也可以諮詢他們的意見。由於這些早期採用者都是真的需要你的產品的人，他們的建議會比你邀請來的親朋好友更有價值。
我很慶幸在能從 Product Hunt 上獲得我的第一批早期採用者。當時 CakeResume 每天大概只有 50 人次來訪，儘管人數不多，但卻讓我持續開發產品時有一種踏實的感覺；因為我知道只要我一推出新功能，馬上就會有人使用，並且我可從他們的回饋知道他們喜不喜歡我做的新功能。如此一來，就不會只是我一人瞎猜到底下一步該做什麼了。
4. 不斷循環、演進
最小可行產品的概念不是只適用在剛推出產品時；不管公司是甚麼規模，都可以用這個方法快速測試市場反應；反應好就繼續優化，反應不好就適時放棄或改變切入點。
三個月前，有幾家企業跟我們說儘管他們認為我們人才搜尋引擎很不錯，但是如果我們能夠依照他們搜尋的條件每週自動推播最新的人才給他們那就更加方便了。於是，我們有了打造一個「人才配對通知」服務的想法。
但我並不想因此投入人力開發；畢竟只有兩三家企業主動說他們希望有這功能，並不表示其他企業也會想使用。因此，我先規劃了一封 email，寄給我們平台上刊登職缺的部分企業，跟他們說我正在規劃這項新功能，並問他們有沒有興趣使用我們的測試版——
有趣的是，雖然信中說「我們目前還未對外開放這項功能」，但實際上是我們根本什麼功能也還沒有；我的想法是，如果有很多企業表示興趣，那我再趕工做出來就是了；在此之前我們可不想花時間開發一個不確定有沒有市場的服務上！
最後我們收到三十幾家企業表示他們非常有興趣體驗這項服務，並回覆我們他想訂閱的人才關鍵字與年資限制。但儘管如此，有興趣歸有興趣，到底這對企業有沒有實質的幫助還很難說；因此我們也沒馬上開發功能，而是之後每週用半手動的方式寄人才配對通知 — —
由於這個實驗的重點是獲得企業對這項服務的建議，所以我們要求企業告訴我們得與每週配對的滿意度與心得。
如此每週寄一次，維持了一個多月，評價非常的好，此外有些本來沒收到邀請的企業聽到正在體驗這項服務的企業的分享後，也主動詢問我們可否參與體驗。也因為這些回饋，我們決定開發出這項產品；讓企業可以制定關鍵字和年資外，也能制定求職階段、地點等條件以訂閱人才配對通知，之後系統每週就會配送最新的符合條件的人才給企業 — —
不管是創業初期或者後來的新功能，都適用最小可行產品的概念；永遠在實作前，想想有沒有更輕量的方式測試你的想法，如此才能及早發現問題，避免不必要的資源浪費。
結語
透過「快速推出 MVP → 取得使用者反饋 → 修正產品方向」的循環流程，企業能有效率的驗證自己的想法，確保時刻走在正確的方向，避免資源的浪費。
其中這種「最小可行」的概念不僅能運用在產品開發上，也能普及到生活中的種種計畫與新嘗試上。例如，假設你想做一款巧克力蛋糕；儘管你沒有食譜上要求的高級法芙娜調溫巧克力，也沒有厲害的食物調理機；但沒關係，你仍然可以先買些便宜的巧克力做原料、並且用打蛋器慢慢攪拌。等到你確定做巧克力蛋糕確實很有趣，但在慢慢補原料和器具補齊即可。
希望透過以上的實際案例以及常見的 MVP 挫敗原因說明對你有幫助。如果你在嘗試用 MVP 測試自己的想法或者不知道如何開始，歡迎在下方留言與我討論！
參考資料
Getting Real by 37signals — https://basecamp.com/books/getting-real
The Lean Startup by Eric Ries — http://theleanstartup.com/
