分享 一趟 MVP 的旅程:在 Logdown 學到的幾件事

xdite · 2013年09月27日 · 最后由 cqcn1991 回复于 2013年10月22日 · 8720 次阅读
本帖已被管理员设置为精华贴

http://blog.xdite.net/posts/2013/09/27/mvp-logdown-learn 分享作 Logdown 學到的幾件事。


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

说得好!

这文章写得太赞了,值得反复拜读!

超级喜欢这篇文章。

简体中文版 (google 翻译)

http://blog.xdite.net/posts/2013/09/27/mvp-logdown-learn 分享作 Logdown 学到的几件事。

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" VS "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 是需要耗费完全不同等级的心力的...。

我表示自从看了金瓶梅后,繁体中文再也不是障碍了。

大赞!Running Lean 的经验之谈。值得创业团队集体反复谈论。

文章写的好,可是 logdown 我前两天登陆不了是咋回事

#7 楼 @blackanger 通过 github 登录的么?我也遇到过,后来翻墙之后好像就没有这个问题了。估计应该是墙的问题

#8 楼 @chunlea 不是,我翻墙了也不行,普通注册登陆

#4 楼 @search 你太有爱了,繁体看起好头疼

Complain Driven Development +1

#9 楼 @blackanger 那就截图,看看提示什么错误,然后反馈给@xdite

#12 楼 @chunlea 早反馈给她了,她的 blog 里

l @xdite @chunlea 知道原因了。当初点击邮件验证跳转出现的问题,删除浏览器缓存就可以正常登录了。

终于对 MVP 有点认识了,希望其他有实际产品经验的也能像@xdite一样分享出来,对我很有启发。

果断收藏,赞

大赞 不过看到大段繁体还是比较头疼 推荐一下 同文堂插件 https://chrome.google.com/webstore/detail/new-tong-wen-tang/ldmgbgaoglmaiblpnphffibpbfchjaeg

寶貴的經驗!P.S. 還是傳統漢字有愛的說。。不過臺灣術語神碼的(實現 » 實作)看慣了大陸技術書還是不大習慣 XD

挺好的。赞一个。

#1 楼 @nightire 所以说重点就是,我们应该重视 tour 和 landing?不过这 2 个是什么意思啊?就是现在 logdown 的首页吗?

需要 登录 后方可回复, 如果你还没有账号请 注册新账号