Lean Startup 是最近幾年來的顯學，其主要的訴求是創業者應該先把重點放在打造一個 Minimum Viable Product (MVP)，觀察市場的需求，再行調整變化商業主軸成長。
這一套理論在近年來被大家一直傳誦，已經讓人聽到長繭了。但是最讓眾人疑惑的其實還是幾點：
(1) 所謂的 Minimum 到底要砍到多少才是 Minimum ?
(2) 這麼少的 Feature 的站台，難道真的會有人來用嗎？
(3) 如何證明一開始少功能的站台真的比多功能的站台好處還要多？
(4) 開發一個產品，初期應該做到多少功能，才算是足夠？
這幾個問題，也是我一路以來一直想知道的答案。
我們團隊最近很紅的產品 Logdown，其實從來不是一個「計畫中」的產品。它只是一個我們眾多一直很想做的點子的其中一個，然後在 Hackathon 中莫名其妙的被做完了原始的 prototype，然後莫名其妙的變成了產品，最後莫名其妙的變成了一間公司。
從這三個月莫名其妙的旅程中，在 Logdown 的茁壯過程，我趁機會執行了一狗票過去幾年來一直我觀察到的現象、卻從來沒有機會在職場上印證的假設，意外的得到了不少答案...
多小的產品規格才是 MVP："一個"足夠解決問題的功能範圍
在做 Logdown 之前，我自己作過很多產品，也幫客戶作過很多專案。讓我一直抱有疑惑的是：以規格數來算，在規格裡面被規劃幾條是 MVP？如果以一個中型公司「產品企劃」企劃出的專案，通常規格會多達 20-30 項，那麼所謂的 MVP 是不是 10 項？還是 7 項？
而我後來發現，其實嚴格的定義來說，只需要「一項」。市場上需要一個夠好的寫作平台，嚴格來說，是需要一個夠好的網頁文字編輯器，其實作這樣完全就夠了。
當然，我們當時沒有這麼大膽，覺得作這一個平台只需要這個功能。但是我們的時間和精力只夠我們當下只做這一個功能，然後在這個給定的時間內，做到最好。（因為是在一個 Hackathon 中做的..）
在上線以後，我們就發現這個功能就足夠吸引幾百個人對我們的東西有興趣...
這個原始方向「也許」是對的，所以才會有後續的開發維護。
不是減法原則：直接讓用戶告訴我們什麼是最重要的
把一個只有一個功能的原型變成一個產品，後續的最大挑戰是你知道既有市面上類似的產品有哪些功能。但是，一個成熟的部落格平台有 100 項功能，我們到底要先實作哪些功能？
有些人可能會建議，把 100 條功能先整理調列出來，賦予權重，再投票篩出作最重要的 10 個功能？但幸運的是，因為當時我們公司實在是太忙了，沒有美國時間作「整理」這種事。
我們實作的功能順序是：只要這個功能被不同的 user 抱怨超過 3 次（這種基本功能你們竟然沒有？？），這個功能才會真的進我們的 issue tracking list，稱之為 Complain Driven Development。
我們得以把最值得投資的功能在很早的階段就都做完，不用花時間在做錯的功能，再陷入到底要砍還是繼續維護的兩難。
當然，上述的這兩個作法，表面上的風險很大，在一般的公司我的老闆絕對不允許我幹這種事，好險這間公司我是老闆（笑）。
產品 V.S 裝置。既然是作產品，就需要包裝。包裝會帶給產品超乎想像的改進作用...
Faria 的老闆 Theo，曾經寫過一篇文章 Building Complete Products vs. Devices，我相當認同他的觀點。
他提到一個「產品」，內容應該具有以下必備：
- Support
- Blog & Twitter
- Demo Video
- Setup & Getting Started
- Print Materials
- Behind the scenes
一直以來，我覺得台灣大部分的網站都是屬於他口中的「Device」，使用者進來一個網站：
- 開發者把所有能呈現的功能一口氣呈現
- 找不到自助說明文件
- 找不到官方交流管道
- 找不到回報問題的地方
這也是我之前作產品時的毛病。只是在當時，我並沒有意識到這是 "Product" V.S "Device" 的問題。
也一直以為這些事情是 Beta 站的常態：
(1) 試用的朋友在玩過我寫的 prototype，會開口問：「嗯...你這個應該是 XXX 服務吧？我剛花了一陣時間才搞懂這是什麼」
(2) 使用者只有微小建議，但找不到「只做建議」的地方
(3) 使用者只有卡在小地方，但找不到「只想偷偷問」的地方
(4) 使用者不知道這個服務最近上了什麼新功能，找不到官方素材可以幫忙寫文章廣告...
開發者無法第一時間有效傳達這個服務想解決什麼，使用者也沒有順暢的管道可以反應有價值的意見給開發者。但這些問題似乎卻沒有一些有效的方式可以一次解決。
產品包裝的實驗
而這次作 Logdown，在頭兩週快馬加鞭把大多數的重要功能寫完之後，我決定一反常態，把所有功能開發都暫停下來。讓同事們花了整整兩週，接下來只很奢侈的專注在做首頁與 Tour。
我一直想知道為什麼歐美的網站要花那麼多時間作 Landing 頁面以及 Tour 頁面，Fouder 還那麼有空寄信問候每個使用者網站用得爽不爽？我只知道也許作這些事也許可以解決上述遇到的那些問題...
後來的事情發展證明這個早期投資完全是值得的。我們得到了遠超乎預期的效果：
不需要重複的一再介紹自己
Landing 與 Tour 讓我們不需要重複的一再介紹自己（而且是對世界用戶），使用者幾秒內就能決定這是不是他需要的服務。而 由引導式的流程導引陌生的使用者註冊。
重新審視「產品的核心賣點」
而在製作 Landing 和 Tour 的過程中，也逼開發者重新審視「產品的核心賣點」到底是什麼。
- 寫英文 Tour 真的很累，所以根本不想要作太多雜魚 Feature，以免還要寫介紹...
- 在截圖時，發現當初 UI 做的不夠精緻，根本不能上相，只好 UI 大調整...
- 部落格系統的某些核心重要賣點，我們根本還沒實作。只好趕緊調整優先權，趕快做出來，以免沒有內容可以放...
如果不是採 MVP 的成長方式，我們可能連 Tour 都寫不出來，也沒有機會邊做邊「精練」。
重新審視使用流程是不是合理
我們在寫站內的教學時和對照用戶的來信時，也發現使用者操作功能的流程完全不是我們預期的那樣。如果沒有撰寫 Help，我們不會知道我們設計出的操作模式有些其實完全不合理...
寫信，大量的寫信。使用者絕對主動會告訴你許多開發者想像不到的秘密...
最後一件事我學到的就是：寫信，大量的寫信給你的 user。我平常也是很多 SaaS 用戶的使用者，之前我常覺得一些服務的 Founder 很假掰，怎麼有空寄給使用者問候信。難道是生意太冷清絕望了，才問使用者哪裡做得不好？
收到這些信，偶爾我心情很好也是會回幾封，跟他講我覺得哪些功能不合理，為什麼我用完之後還是沒太高意願付錢。
但是我其實從來沒想過要抄這一招。因為我真的不知道寄信給使用者打招呼要幹嘛....（矛盾？）
但是這次不知道哪裡來的好奇心，想說順便在 Logdown 裡面寄信給 user say hello（設定在註冊後三小時後），想看看會發生什麼事。結果竟然打開潘朵拉的盒子....
我竟然遭受到了有生以來最恐怖的客服信 DDoS，在 Logdown 開始寄 hello 的信的第一個月，我收到了幾百封的使用者意見信，回到手真的是差一點都快斷掉了。
這才讓我意識到，不是使用者小氣不肯給開發者意見，他們只是懶得上 support，或覺得事情沒嚴重到值得寫 support。但如果是你「順便」寫信問候他，他會很樂意「順便」「回信」「給你一點意見」。
我們從這些幾百封的信裡面得到了大量的改進意見，許多的點是我們從沒想像到的。而且與我們官方 Support 上的 issue 類型都完全不一樣。
如果是像以前 device 型的作網站。我們不知道會多走多少冤枉路...
Summary
Logdown 是我們團隊作過有史以來「最少」「功能」的一個網站。最少功能並不是指實際上被開發的功能最少，而是經過「正規」「規劃」所做出的功能最少。幾乎都是「被很多使用者要求」「真的有必要」才作。
但是就要到達一個「Product」的標準，雖然一直走在「應該是相對正確的方向」，但實際上真的付出的力量遠超過作那些正規的 "Device" 網站。
所以真的不需要再擔心 Minimum Viable Product，Feature 太 Minimum 的問題，打造 Product 與 Device 是需要耗費完全不同等級的心力的...。