Posts Tagged ‘PMF’

Funnel (或稱 Conversion Funnel) 是網路業最基本的概念之一，它的意思是 100 個人路過你的網站，你能夠把幾個人變成忠實顧客。

一般最基本的電子商務 Funnel，大概分五個步驟：

• 100% — 流量
• 20% — Email 訂戶 (或 Facebook 粉絲)
• 10% — 加入會員
• 3% — 下訂單
• 1% — 重複購買

你可以看到我在每個步驟前面都加了一個數字，好讓你們對於這個漏斗有些概念 (這些是我大略抓的數字，每家公司會因為他們的商業模式有差異)。

如果是一個免費的 Smartphone App，則大約是這樣的 Funnel：

• 100% — 點擊 Admob/Adsense/iAd 廣告
• 20% — 下載
• 6% — 打開一次
• 2% — 重複使用

注意到每個網站不會只有一個 Funnel，從不同地方來的流量，往往會有不同的第一、第二層轉換率，例如：SEM (關鍵字廣告) 的轉換率往往會比 SEO (搜尋引擎最佳化) 的高一些。所以你必須要清楚的知道你有幾個主要的漏斗，並詳細的追蹤。

不過從「加入會員」(或是「下載」) 之後，那就是你的產品本身的問題了。這時候不同的 Funnel 來的人，差異比較小。Fred Wilson 前陣子發表了一個 30/10/10 定律，和我的觀察非常一致，大概是這樣子的：

• 30% 的會員/下載每個月會使用一次
• 10% 的會員/下載每天會使用一次
• 尖峰時段的同時在線使用者大約是 10% 的會員人數

所以也就是說從加入會員開始，你的目標是讓 1/3 的使用者至少會真的使用你的服務一次，再讓其中的 1/3 成為「主顧客」。這大概是網路業一個最基本的「黃金比率」，如果能優化到這樣的程度，那可以說你的產品是有達到某種程度的 Product Market Fit。如果無論你怎麼做都無法留住 1/3 的客人，那你可能要考慮 Pivot 去別的產品。

網路業已經 16 年了，這其中不但累積了許多深奧的學問，規則更是時時刻刻都在更新。需要一群夥伴陪你一起研究？第四屆 appWorks 育成計畫已經正式開放申請，歡迎加入。

(Image via intersectionconsulting, CC license)

Xdite 的網誌最近真是好文連連，繼上周的「需不需要一開始就 Scale」之後 (我也因此寫了什麼時候 Scale)，昨天又寫了一篇很棒的「Startup 需不需要一開始注意資金的問題？」。在文章裡，他說：

我發現，這些玩垮的網路公司，幾乎所有的問題點出都在於「燒錢不會痛」… 沒有活命壓力就沒有 “deadline” ，然後有天就很難看的直接 dead 了… 需不需要一開始注意資金的問題？當然需要。只不過我的想法偏向「注意資金」的定義是「嚴格注意資金的運用」，而不是「去募到一堆錢然後亂花」。錢太多，十之八九會讓公司在一開始就滋養出一堆奇怪的病症…

寫得真是太貼切了。就像我說的，尋找新商業模式，和開發軟體一樣，都是一種「創造新知識」的過程，9 個女人也沒辦法在 1 個月生出小孩，所以這樣的過程你多砸更多「資源」下去，速度不但往往不會變快，甚至常常只會有反效果。

倒是 Xdite 的文章最後，提了一個很有趣的問題：

Lean Startup 由創投來教又是更詭異的一件事。創投的存在基本上就是投注給你「很多資金」。而仔細回想，其實只要你很缺錢，自然就會很 Lean，所謂 Lean Startup 只是當你很缺錢時會自動產生的一連串決策成果。你會變得很 Agile，很注重投資效益，很注重 Pivot，很注重 deadline，因為不重視就會直接死。拿了很多錢又怎樣 Lean 呢？我也想不通。

聽起來的確蠻衝突的，創投不是希望你拿錢的人，這回怎麼又叫你要 Lean Startup 呢？Jamie 也說自己是創投，那他一天到晚寫那些精實創業的 MVP、Pivot、PMF，到底什麼意思？

其實事情也沒有那麼複雜，我稱它叫做「演化」。演化是「天擇」的結果，而創投這個「物種」，近年來碰到的巨大環境變遷，就是「創業成本」的不斷降低 — 主要來自於開源/自由軟體、AWS 等雲端服務、行動裝置 (App Stores) 和社群媒體的普及。

在我看來，現在的網路創業，跟 99 年我們創辦碩網資訊時相比，成本至少差了 10 倍，甚至將近 100 倍。想當年我們要先花好幾百萬台幣自己打造一個 B2C 電子商務平台、再花好幾十萬買主機、最後一個月的 co-location 還要好幾萬。時光快轉 12 年，在 2011，你隨便 Google 都可以找到幾十種 Open Source EC 平台可以用，再懶惰一點的去商店街，一年才 1 萬塊租金，三兩下店就開張了。

所以當創業變得「便宜」，新創團隊的勝負關鍵就不再是誰的「本比較粗」，而變成一場「效率」和「生產力」的戰爭。相對的，當錢不再是最重要的資源，而管錢的 VC 卻想要成為 Startups 的股東時，那我們就必須要能提供錢以外的「資源」和「價值」，來協助創業團隊找到更多效率和生產力。「超級天使」因應而生，有人說，這是「創投產業的革命」，對我來說，這就只是物競天擇的結果。

所以，創投為什麼要教 Lean Startup？因為我們希望服務到我們的客戶，也就是每一位辛苦的創業者。當我們能提供錢以外的價值，創業者才會更願意和我們成為一起奮鬥的夥伴。或者說，無論在矽谷還是在台北，創投都在經歷一場重大的變種過程，大家努力的演化，就只是想成為最後生存下來新物種，如此而已。

無論如何，我覺得這對於創業團隊都是好事，因為天平已經倒轉，讓創業者從弱勢的一方，變成了強勢的一方。讓創投必須要更用功，提供更多的價值。這，只能說是更美好的世界，是吧？

而你千萬別懷疑，appWorks 絕對不只是教 Lean Startup 而已。在這裡，除了創業需要的所有理論、工具、案例，你還可以隨時跟 50 個第一流團隊切磋、互相幫助，這，就是我們提供的價值。第四屆 appWorks 育成計畫即將在幾天後正式開始接受申請，我們期待你的加入。

歡迎在 Google+ 上加入我們的討論

(Image via kk, CC license)

前陣子，在他們的產品發表會，Gulu 的 Jimmy 在台上脫口說了：「Jamie 說技術不重要！」回來之後，為了澄清這句話的前因後果，我於是寫了一篇「技術到底重不重要」。

而這個討論就從那邊開始延續了下去，除了我的文章下面出現的 75 則回應之外 (蠻精彩的，你們可以去讀讀)，Jimmy 幾天前也在他自己的網誌闡述了他的想法 — Scalability Matters for Web Startup，他說：

(W)eb startup developers… should think about scale before they write their application. Building your app, for example, using scala on mongoDB and set it up to autoscale on AWS is smart, is free, and is easy!

基本上的意思就是說 Scale 並不難，也不貴，所以你應該從一開始就做。

而接下來的幾天，大家便在 Inside 討論了起來。到了昨晚，Xdite 也在他的網誌發表了「Startup 需不需要一開始就注意 Scale 的問題？」，他說：

在這個議題中，我覺得最容易混淆的點是：將 “Scalability” （擴充性）與 “Maintainability” （維護性）混在一起講… 如果不把 Maintainability 做好，很快的，你的 code 在三個月之內就會腐爛而且臭不可聞… 一個產品需要被重視「Scalability」，通常是在人為的「調整」費用高過「直接買機器」、「轉換成為另外一種架構」的成本這一類的狀況，才有可能發生…

很清楚也很棒的解釋。

其實如果你仔細想想，這個問題的核心根本不是「Scalability 重不重要？」，因為廢話它當然重要，只是重要的「時間點」到底在哪裡。也就是說，講這麼多，大家其實真正在討論的根本就是「什麼時候 Scale？」。而這個問題是沒有標準答案的，所以能夠有這麼多人發表他們的意見，是非常棒的一件事。但最後你們自己要參考各方觀點之後，根據你們自己的能力和資源，去做出你們自己的安排。

未知需求 vs 成本風險

對我來說，這是一個「未知需求」 vs 「成本風險」問題 — 當你不確定有沒有人喜歡你的產品，先開發給 1,000 人用的 MVP (Minimal Viable Product)，花的時間和力氣比較少，風險相對的也比較低。

在 appWorks 輔導 50 個創業團隊下來，我的經驗是通常你的前面 5~10 個 MVP 是沒有人要用的，因為你對市場的理解度還很低。所以當你可以用少一點的時間、少一點的開發精力去驗證你對市場的假設，如果事實證明你是錯的，至少不會那麼心痛。

接著你會不斷的 pivot，到了第 11 個 MVP，終於讓你找到了 PMF (Product Market Fit) — 也就是確定了這個產品真的有 1,000,000 人要用。這時候，你再花資源下去，把它升級成 1,000,000 人用的架構。沒錯，這裡面可能有很多code 要重寫，但是至少前面 10 個嘗試，你沒有浪費太多珍貴的資源。

假設你對市場的理解度不高，用這樣的 Lean Startup 方式去創業，11 個嘗試下來你的期望值是比較高的。當然，如果你對掌握市場的需求很有自信，或是已經有明確的通路，那就相反，應該像 Google+ 一樣，從一開始就用規劃給 1 百萬甚至是 1 億人的 Waterfall 方式執行。

另外，從 1,000 人規模化到 1,000,000 人，其實也不一定要大幅的重新寫 code。我的經驗和 Xdite 說得很像，有時候就只是把機器從 AWS 的 Micro Instance 升級到 XL Instance，或是加上 App Server Load Balancing 架構而已。唯有當這些架構升級都已經無法滿足，或是邊際成本過高時，你才會真的去大幅度的把程式碼 refactor。

以上，希望這些討論能讓你對於 Scale 這件事情有更深入的了解，也更能決定自己的規模策略，加油！

有興趣多了解 Lean Startup 的精神和方法？第四屆 appWorks 育成計畫即將在下周正式開始接受申請，敬請期待。

歡迎在 Google+ 上加入我們的討論

(Image via jdhancock, CC license)