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 是需要耗费完全不同等级的心力的...。
大赞 不过看到大段繁体还是比较头疼 推荐一下 同文堂插件 https://chrome.google.com/webstore/detail/new-tong-wen-tang/ldmgbgaoglmaiblpnphffibpbfchjaeg
