最近幾年，興起 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
- 不會寫程式：用手邊可以兜出的方案實作
- 會寫程式：只寫一個「可以解決問題」的功能就上線。
Lean SaaS
這是我的新書 Lean SaaS 的第一章。若你對接下來的內容有興趣的話，我將會在這本書繼續連載後面的內容（保證每週連載，約十期）。
連載期間價格 30 USD。連載結束後 45 USD。
本書最後附贈 SaaS 上線 checklist，我會在書中的逐章解釋 CheckList 的每一條意義。
歡迎各位讀者來信交流，我的 email 是 xdite@rocodev.com