over 10 years ago

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

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

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

M 不代表草率

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

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

M 的 scope

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

我的建議是:

不會寫程式的作法

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

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

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

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

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

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

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

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

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

← Lean SaaS : Build SaaS From Small Ideas 寫給大學生的程式技能 Cheatsheets →
 
comments powered by Disqus