http://blog.xdite.net/posts/2013/11/19/lean-saas-mvp-m

（我就不打書啦。純貼文章。聊聊技術創業者的問題）

=====

最近幾年，興起 Lean Startup 的風潮。主要的訴求是創業者應該先把重點放在打造一個 Minimum Viable Product (MVP)，觀察市場的需求，再行調整變化商業主軸成長。

說起來簡單，但沒人敢篤定的說，這個 Minimum 的 M 到底要做到什麼程度才足夠。討論一個點子，快速製造出一個原型，然後讓使用者快速反餽調整？這樣做的人很多，但卻不是人人 work。

更普遍的是你見到一個「草率」的產品上線，然後從此就快速沉寂消聲匿跡。

M 不代表草率

很多創業者在製作產品的過程中，常常不自覺得把「MVP」這三個字拆開來看，亦即只完成了「M」，以為實作了「Mininum」的產品規格，就可推出觀看市場反應。事實上，市場上有人會要的東西是 MV（Minimum Viable）。如果你的產品並沒有解決了任何有價值有意義的問題，只是一堆精美的介面功能，那麼是沒有人會買單的。只是浪費了時間浪費了金錢，生出一堆沒有用的程式碼。

相反地，若提供的解決辦法對某些人很重要，那麼就算產品介面再怎麼 crappy，他們還是有興趣停下來試用，甚至付錢給你希望開發者將把它做得更加完善。

M 的 scope

回到正題。我們終歸要討論 M 的 scope 到底在哪裡。

我的建議是：

不會寫程式的作法

如果你不會寫程式的話。先去找一個「會用」的工具湊出一個勉強能夠動的流程，解決問題，然後開始找人試用。

如果你找不到現成的工具可以兜，那麼還有一個方式。你可以拿非常仿真的 Mockup 工具，如 Axure XP、Balsamiq，把「可以解決問題」的流程和出現的畫面畫出來。

不要覺得這樣的步驟很麻煩，因為到這裡為止，還是只有梳理工作流程而已。

你可以從這樣的流程，粗略的知道後面將要面臨多麻煩的事。以想要開一個商店來說，你就會知道商店：

• 需要一個上架介面
• 需要傳圖介面
• 需要結帳介面
• 提供哪些結帳選項
• 提供哪些寄送方式，如何選擇
• 要用哪種條列方式管理使用者訂單

會覺得製作這些畫面很花時間對吧？這些都只是畫面而已。要寫出後面的程式可能是畫一張畫面「五倍」甚至是「十倍」的時間。

透過把畫面與流程畫出來的方式，可以讓你 (很清楚的）知道要製作這個東西要花多久的「成本」（不管是時間上還是金錢上）。

不要因為覺得很麻煩，就使用「功能列表條列」、或者「單張畫面，列出滿滿按鈕與分頁去表示所需功能」的方式去估算工作時間。

因為事實上，在列表上，一個功能你都只會以為需要一小時或一天就能完成。而真實會發生的情形是，一條功能至少要開發 7 天。

當你一旦理解到要執行這個計畫所需成本可能是多麼巨大的時候，自然就會毫不猶豫的把不需要的功能砍掉，只專注在「必要的解決手段」。就這個例子，甚至最可能的情形，是上去 Shopify 上面開一個網路商店，或者是註冊一個 Wufoo (線上表單服務）payment integration Plan。

會寫程式的作法

會寫程式的作法反而相反。我相信各位開發者都很威，開發軟體的成本對你們來說都超低。但，請千萬千萬忍住，只做一個功能就好。思考哪個功能是「解決問題手段裡面絕對不可以沒有的」，只做這一個就好了。以 Logdown 這種部落格平台來說，標準就是只做一個編輯器，以及簡單的文章系統就好了。

（真的不要擔心作太少，一上線你就會知道就算只有「一個」也是會操掛你。相信我，實際試一次就知道了）

因為技術創業者都是「很會寫程式」才會出來創業的人。所以往往的毛病就是不打 idea 草稿，邊寫邊想。又以 Ruby on Rails 開發者（哈，在說我自己）最容易有這壞毛病，因為開發程式太快。所以 generate model, generate controller, 套個版，就覺得這東西可以上線，上線就等於可以開始收錢發財了。

然後，就沒有然後了。

作產品跟上班、接案做的東西驗收標準完全是不一樣的。上班、接案，你只要按照 issue tracking 上的「指示」完成工作就可以了。但是「產品」的「完成」標準，是「順利」的「幫 End User 解決他的問題」。而要做到這件事，產品需要花上大量的時間打磨：介面要做到讓用戶可以理解不會迷路。程式不會出現詭異的錯誤。按照 End User 的需求調整加強，甚至打掉重練。

一開始就作太多功能的問題是：開發者以為這些功能都已經「完成」了。但事實上，他們每一個對使用者來說幾乎都是「未完成」的。也許使用者可以從這麼多的功能列表「猜」出開發者想要提供什麼服務，但是實際上他們不會繼續用下去。因為這個網站爛透了，每一個功能都是「未完成」。沒有解決到任何一丁點問題的網站，沒有人有興趣繼續用下去。

那麼你說，沒關係，我可以之後照使用者的反饋調整網站。但是問題又來了，做了那麼多功能「都有問題」，使用者的回報意見，自然涵蓋了所有板塊。那麼你該如何判斷出什麼問題沒做好才是最嚴重的呢？優先權該放在哪個模組呢？有些厲害的模組甚至是當初花了很多心血做的。結果使用者劣評如潮，你思考了下徘徊在投入心血改進和不如砍掉兩個選項。但狠的下心嗎？

然後，就沒有然後了。被第一次進來的 Customer Feedback 打爆，就沒有然後了。

所以，只做一個能夠解決問題的功能。只做這樣就好了。

Recap

• Minimal "Viable" Product
• 不會寫程式：Write down User Story
• 不會寫程式：用手邊可以兜出的方案實作
• 會寫程式：只寫一個「可以解決問題」的功能就上線。