最近我看到 Paul Graham 的一則推文，談到失敗的創業者通常仍會受到敬重，只要他們曾做出不錯的東西，並且明白自己為何失敗。

2007 年我和兩個兄弟一起創立群眾募資新創「microPledge」時，我們確實努力想做出好東西：一個任何專案都能使用的群眾募資平台，並以軟體專案為主軸。

而我相信我們知道自己為何失敗：我們的第一個版本過於複雜，而不是最小可行產品，而且我們在還沒向潛在使用者測試、推銷之前就把它做出來了。接著就是搞垮我們的 PayPal 法律問題。

本文將概述我們的新創，深入探討我們犯下的錯誤與學到的教訓，並列出完整的事件時程以作紀錄。同時也會探討為何 Kickstarter 能起飛，而 microPledge 卻沒有。不過，microPledge 確實啟動了我們的職涯。

microPledge 的概況與起源

早在 2006 年 1 月，我哥哥 Berwyn 在通勤上班的路上有了 microPledge 的點子。最初的構想大概是：「想像一下，讓左鄰右舍、朋友還有阿嬤每人出 20 美元，合力蓋一座社區遊樂場。我們只需要一個能促成這些新創作的網路工具！」

不久後他就聯絡了我和另一個哥哥 Bryan，問我們要不要一起來做這個。Bryan 當時剛創立自己的網頁設計公司，馬上就加入了。我則是大學畢業沒幾年，一直在讀 Paul Graham 談新創的文章，很想加入試試。我也早就在關注 Python 這個程式語言，正想開始使用它。

時機非常好——「crowdfunding（群眾募資）」這個詞正是在 2006 年 8 月首次被使用。我們從 2006 年 6 月到 2007 年 7 月花了約 12 個月打造平台，並在 2007 年 8 月上線，正好搭上群眾募資開始成為熱門概念的浪潮。

以下是 microPledge 原始首頁的截圖（目前仍保存在我們的唯讀網站上）。

我們起初專注於幫助人們為軟體專案募資，但也希望這個系統能適用於任何類型的實體專案。

想要募資的創作者可以輕鬆建立專案：我們刻意將發起專案表單精簡到單一畫面：

在此之後，專案創作者可以設定目標金額，然後等待贊助進來。承諾贊助的款項會先轉入信託帳戶，直到撥款時機到來。

我們使用 PayPal 作為支付系統。當時它是少數能讓你把錢付給他人的供應商之一。然而，我們一開始並沒有仔細閱讀他們的條款細則：簡單來說，PayPal 不喜歡你以信託方式持有資金。但這部分下面會再詳述。

我們從天使投資人那裡拿到一小筆資金：約 NZ$10,000 來自家人，NZ$60,000 來自一位朋友。當時我們估計這筆投資約佔公司三分之一的股份，所以我們三位創辦人合起來仍持有三分之二。這筆錢足夠支付我們三人在全職開發期間的最低生活開銷。

回頭看，那段時光非常有趣：和兄弟們一起打造屬於自己的新創，學習 Python、SQL 和網頁開發。

為何我們會失敗

microPledge 並非徹底失敗：我們有約 1200 位使用者、建立了 100 個專案，總承諾金額達 $25,000。其中一小部分專案達到了目標。所以我們確實獲得了一些初步動能，然後陷入停滯、燒光資金，最終以失敗收場。

以下我將說明我認為我們失敗的各種原因。現在回頭看，這些道理顯而易見，但在 2006 年對三個年輕的軟體宅來說，卻一點也不明顯。

這些多半在任何「新創入門 101」文章的「千萬別這麼做」清單上都能看到。事後諸葛總是特別容易。

過於複雜的進度與撥款機制

microPledge 沒能起飛的原因之一，是系統實在太複雜。別忘了我們是三個幾乎不懂行銷的工程師。與其做一個極度簡單的「第 1 版」，我們卻打造了一台魯布·戈德堡機械：技術上很厲害，卻難以理解。

我們設計了一套漸進式撥款機制，讓專案創作者可以拖曳滑桿來表示（例如）「我已完成 30%」，並上傳證據——照片或原始碼——來展示目前的產品進度。贊助者會收到通知，接著拖曳滑桿來投票，經過一段投票期後，創作者就能拿到 30% × 總承諾金額 × 平均投票百分比的款項。

以下是我們其中一個專案頁面的截圖（這個專案達到了目標，但最終並未開發）：

細節非常多，從我們那份長達好幾頁的專案創作者常見問題就能看出來。此外，我們還有一套完整的專案報價系統，任何人都可以提出專案構想，然後由開發者報價，最優惠的報價就會勝出。

別誤會：以一套複雜的系統來說，microPledge 的 UI 其實做得不錯。我們花了很多時間琢磨細節！「募資溫度計」和進度滑桿清晰又直觀，細節透過工具提示逐步呈現，創作者和贊助者也都會在投票流程中獲得引導。

我們的錯誤更早就犯下了：我們設計了一套精密的系統……卻沒人需要。比 microPledge 晚兩年上線的 Kickstarter，靠一個簡單的「Back this project」按鈕就成功了，專案創作者要嘛在達標時拿到全部款項，要嘛一毛也拿不到。沒有進度階段、沒有投票、沒有撥款計算。

我們不是為了複雜而複雜；我們是想解決贊助者是否能信任創作者真的會把產品做出來的問題。但事實證明，大家其實還滿願意信任的，而且大多數時候，這套模式是可行的！確實有相對少數在 Kickstarter 上未履行承諾的創作者、讓贊助者不滿的案例。但大家本來就知道有風險，而且只投了 $20，又能氣到哪裡去？

簡言之，microPledge 作為最小可行產品來說太過精細，也比使用者真正想要的複雜太多：贊助者只想要一個簡單的贊助按鈕，創作者只想要拿到錢。

過度設計的軟體

把三個有完美主義傾向的軟體工程師關在同一個房間裡，他們注定會把東西過度設計。

舉例來說，我們自己開發了一套迷你ORM，而不是使用現成的套件（或直接寫 SQL）。身為新創，我們應該專注於把事情做完，而不是去寫框架層級的程式碼。

我們花了很多時間調整 PostgreSQL 設定來啟用 WAL 日誌（在當時，這很難設定），好讓我們能自豪地告訴使用者我們有即時備份。我們其實只要寫一個 5 行的腳本，用 pg_dump 每天備份一次就好了。

我還記得自己曾花了好幾個小時寫程式來偵測並處理隨機 SHA-1 雜湊的碰撞問題。這種事基本上幾十億年都不會發生一次，所以我想我當時應該先去讀一篇關於密碼學雜湊的文章才對。

而我們做這一切時，根本沒有付費用戶，也沒有像樣的營收策略！那時我們還沒深刻體會到，新創的生死取決於能否創造營收，而不是程式碼的技術實力。

如果團隊裡能有一個具藝術或商業頭腦的人，而不是再多一個工程師思維的兄弟，或許就能避免這兩種「過度複雜化」的問題。

重視機制，而非成品

如果你看看上面那張專案頁面的截圖，最顯眼的部分是贊助與進度，而不是贊助者將會得到的產品。介紹專案本身的文字只有小小一段。

相較之下，Kickstarter 的專案頁面一開頭就是一支大力推銷產品的大影片，接著通常是一大段關於該產品的詳細介紹，穿插著高品質的照片。以下是某個Kickstarter 專案頁面的頂部：

Kickstarter 幫助創作者讓他們（潛在的）產品真正發光。我們的專案頁面則沒有。他們還會引導你做出很棒的專案頁面。基本上，他們是在訓練這些微型新創的創辦人，向自己的受眾行銷。

我認為我們會犯這個錯，是因為我們是從創作者的角度思考，而不是從付費客戶——也就是贊助者（或用銷售術語來說，買家）的角度。基於同樣的道理，「Kickstarter」這個名字比「microPledge」好一些：它強調的是產品的產出，而不是贊助的投入。

焦點選擇錯誤

雖然 microPledge 確實支援實體專案，但我們多數的推廣力道都放在軟體專案上，特別是作為資助開放原始碼軟體的一種方式。

我們從那裡起步，是因為那是我們熟悉的領域，而且軟體散布很容易。然而，回頭看那幾乎肯定是個錯誤：開放原始碼確實能賺錢，但收入通常來自企業支援與擴充功能，而不是群眾募資。

Kickstarter 和其他募資網站往往聚焦於真實的、實體的專案。要讓一般人願意為一個硬體小玩意或一雙新型鞋子掏錢，遠比為軟體掏錢容易得多。

沒掌握使用者真正的需求

另一個重大的失敗原因，是我們在沒有探詢市場、也沒有測試真實使用者實際需求的情況下，就把系統做出來了。

當然，我們也有做一些推廣，主要是針對我們認為可能會覺得有用的軟體專案創作者。例如，我們與 Apache 的 mod_wsgi 擴充套件維護者 Graham Dumpleton 有不少互動（我們就是用 mod_wsgi 來運行 microPledge）。我們說服他用 microPledge 開了一個純捐款專案，他也在過程中給了我們一些寶貴的回饋。

而在 2007 年 9 月，我們在紐西蘭報紙《Dominion Post》上獲得了一點媒體報導（該文也同步刊載在 Stuff.co.nz 上，他們的姊妹新聞網站）。

話雖如此，我們本來就應該從一開始——在花 12 個月開發之前——就向潛在的專案創作者和真正的贊助者推銷它。我們應該根據這些回饋不斷迭代產品。我們之所以沒這麼做，最主要的原因可能是，對我們而言寫程式很有趣；拿起電話則不然。

PayPal 的法律問題

上線幾個月內，我們就已經能看出情況不太妙。然而，真正讓我們被一錘敲死的，是上線一年後與 PayPal 的法律糾紛。

microPledge 處理金流的方式是這樣的：我們透過 PayPal 接受贊助，再將這筆錢轉入我們的信託帳戶，最後隨著專案進展分批撥款給專案創作者。

正是「以信託方式持有資金」這一點害了我們。這真的要怪我們自己：我們沒有仔細閱讀 PayPal 的服務條款，而以信託方式持有資金正是他們禁止的行為之一。

PayPal 會發現，是因為有信用卡詐騙犯開始試圖透過我們的網站洗錢。這件事被 PayPal 察覺，他們接著對我們進行稽核，並發現我們以信託方式持有資金。

我們出發點是好的，當然也都如約撥款，但我們才發現 PayPal 裡根本沒什麼「pal（朋友）」。他們一發現我們以信託方式持有資金，就立刻凍結了我們的帳戶，儘管我們多次打電話向客服求情，他們仍將我們的資金凍結了長達 6 個月。

我們感到非常沮喪，使用者當然也很不滿。我們考慮過各種選項和其他支付供應商，但無論如何 microPledge 本來就沒有獲得我們期望的動能，所以這 6 個月的凍結基本上就是喪鐘了。

嘗試出售公司智慧財產

在宣告放棄後，我們改變策略，嘗試將 microPledge 的募資系統賣給有興趣的對象。然而，事實證明智慧財產並不值什麼錢——我們得到一些詢問，但沒有找到買家。

而且開價根本算是大放送——我們只是想多少回收一些成本。引述自我們的「Prospectus」，潛在買家可以購買以下其中一項：

1. 以 US$7,500 取得完整網路軟體的授權，包含原始碼的完整權利與修改權。
2. 包含上述所有項目，再加上平台的完整所有權，含專屬權、轉售權等。價格面議——出價需超過 US$35,000。

我們也曾嘗試在 Flippa.com 上出售公司。同樣地，這件事也沒什麼進展。最終，所有出售的嘗試都不了了之，幾年後我們就讓 micropledge.com 這個網域過期了。

我們學到了什麼

失敗是最好的老師，在這兩年裡我們學到了很多。

商業方面

在新創方面，我們學到的東西，基本上就是上面「為何失敗」清單的反面：

• 從極度簡單的第 1 版開始（KISS 原則）。
• 強調（付費）客戶想要的成果。
• 聚焦於願意付費的市場；也許不是開放原始碼。
• 先銷售——在你寫任何程式碼之前。
• 仔細閱讀你的支付系統的細則。:-)

透過這一切，我們確實獲得了寶貴的商業經驗：我哥哥 Bryan 創立了 microPledge 的母公司 Brush Technology，在 microPledge 失敗後，我和 Berwyn 幫忙營運了好幾年，該公司至今仍作為一家軟體與電子顧問公司持續營運。

microPledge 幾年後，我們又創立了另一家新創 Hivemind，打造了一項實體產品：蜂箱的電子監測與回報系統。賣東西給養蜂人很不容易，但這家新創的表現明顯好很多，我們也將先前學到的幾項教訓付諸實行。

技術方面

身為一個沒有受過正規軟體工程訓練的程式設計師，我想直到多年後才意識到，自己從這次新創經驗中學到了多少。

在技術方面，我學會了網頁開發（HTTP、HTML 表單，以及足以惹麻煩的 CSS 和 JavaScript）。我也學會了 Python 開發，以及關聯式資料庫和 SQL（特別是 PostgreSQL）。剛開始時 Bryan 可能是我們當中最懂這些的人，不過我想大家都學到了很多。

我也學到了網頁框架：我們評估過 Django，但最終選擇了 web.py，這是由 Aaron Swartz 打造的微框架。令我驚訝的是它至今仍在積極維護。我至今仍偏好小而輕的網頁工具：多一點函式庫，少一點框架。

我學到的另一件事是我稱為「diff testing」的方法。這是 Berwyn 的點子，不過我確定不是他原創的——我聽過它被稱為「snapshot testing」或用「golden files」測試。基本概念是將測試的預期輸出存成檔案，並把這份快照提交到版本控制中。接著當你執行待測程式碼時，將輸出寫到新檔案，測試就只是將它與快照做 diff 比對。從那之後我在許多專案中都用過這個技巧；它特別適合資料轉換的任務。

但或許我學到最重要的事是團隊合作：如何以團隊方式開發軟體、如何分工與組織工作、以及使用好工具的重要性等等。microPledge 是我第一份與團隊一起開發、並使用版本控制的工作。這些指導大多來自我年長的哥哥 Berwyn，他已在一家中等規模的軟體公司工作了好幾年。

結論

我的主要心得是，所有從失敗中學到的東西，對我們未來的職涯都非常寶貴。對我個人職涯而言特別有價值的，是用 Python 開發網頁應用程式的技術經驗，以及學習如何在（小型）團隊中打造軟體。

如果我們帶著現在所知的知識再做一次 microPledge，會成功嗎？我想我們會有很大的機會。我們會打造一個簡單得多的系統，並向對的人推廣它。

然而，有一樣東西我們仍然不會有：立足矽谷。Paul Graham 和他的夥伴把 Y Combinator 從波士頓搬到矽谷是有原因的。在小小的紐西蘭要為這類新創募資要困難得多。話雖如此，我認為我們還是有機會取得在地、小規模的成功。

Kickstarter 之所以成功——也值得為他們喝采——是因為它簡單明瞭，並讓系統聚焦於創作者想販售的產品，而非金流機制。

我還會再創業嗎？直到現在我都還想著：「不了，我想先在比較穩定的公司工作一陣子。」但寫下這篇文章卻讓我感到意外，也重新燃起了熱情。也許，是時候再來一次了！

時程表

以下是 microPledge 的時程表（主要是為我自己做個紀錄！）。

• 2006 年 1 月：Berwyn 在通勤途中萌生最初的點子
• 2006 年 1 月：首次 Subversion 提交
• 2006 年 2 月：三兄弟首次開會討論 μPledge（我們的原名）。會議記錄引述：「我們（天真地？）想像能在 6 個月內做出可發布的東西。」
• 2006 年 3 月：決定網頁框架：我們選擇 web.py 而非 Django，因為它的「學習曲線只有六分之一」，感覺輕量許多
• 2006 年 6 月：首次程式碼提交：程式碼架構與迷你 ORM 的開端
• 2006 年 7 月至 12 月：初期程式碼：資料模型、HTML 產生、伺服器建置
• 2007 年 1 月：PayPal 處理程式碼
• 2007 年 2 月至 3 月：頁面樣板、專案頁面、進度滑桿等
• 2007 年 3 月：撰寫 microPledge 專利申請
• 2007 年 4 月至 5 月：贊助與投票、提領資金功能、登入、允許開發者以 10% 罰款退出
• 2007 年 5 月：使用 Amazon S3 的檔案上傳與專案縮圖
• 2007 年 6 月至 7 月：一連串測試與除錯、PostgreSQL WAL 備份、完成伺服器建置
• 2007 年 8 月：上線！發布新聞稿、投稿至 Slashdot.org，並接觸數個開放原始碼專案
• 2007 年 9 月：《Dominion Post》刊出新聞報導
• 2008 年 9 月：PayPal 因我們以信託帳戶持有資金而凍結帳戶
• 2008 年 10 月：請我們的 1200 位使用者每人贊助 $10 以「讓 microPledge 繼續營運」（改用不同的支付供應商）
• 2009 年 12 月：嘗試出售 microPledge 軟體或智慧財產
• 2010 年 2 月：嘗試在 Flippa.com 上出售公司
• 2013 年 2 月：我們讓 micropledge.com 網域過期：一個時代的結束。