about 11 years ago

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 是需要耗費完全不同等級的心力的...。

← Cells 實作 Partial 封裝的最佳實踐 (3) 先做軟體,不要先做平台 →
 
comments powered by Disqus