最近我读到 Paul Graham 的一条推文，他说只要创始人曾做出过不错的产品，并清楚自己为何失败，那么即便创业失败，通常仍会受到钦佩。

2007 年，我和两个兄弟一起创办了众筹创业项目 microPledge，我们确实想做出点好东西：一个任何项目都能使用的众筹平台，并以软件项目为重点。

而我相信我们已经清楚自己失败的原因：第一版产品过于复杂，而不是一个最小可行产品，而且我们在向潜在用户验证和推销之前就把它做了出来。之后 PayPal 的法务问题则给了我们最后一击。

本文将概述我们的创业经历，深入剖析我们犯过的错误和学到的教训，并按时间顺序记录整个过程。同时也会探讨为什么 Kickstarter 成功了，而 microPledge 没有。不过，microPledge 确实 kickstart（启动）了我们的职业生涯。

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 年，对三个年轻的软件极客来说却并不明显。

这些问题中的大多数，大概在任何一篇“创业入门”文章的“切勿事项”清单里都能看到。事后诸葛亮总是很美妙。

过于复杂的进度与发放机制

microPledge 未能起飞的一个原因是系统实在太复杂了。别忘了，我们是三个几乎不懂营销的工程师。我们没有做一个极简的“1.0 版本”，反而造出了一台鲁布·戈德堡机械：技术上很精妙，却难以理解。

我们设计了一套分阶段发放资金的机制：项目创建者可以拖动滑块来表示（例如）“我已完成 30%”，并上传照片或源代码等证据来展示迄今为止的产品进展。认筹者会收到通知，然后拖动滑块进行投票，投票期结束后，创建者将获得 30% × TotalPledged × AverageVotePercentage 的资金。

这是我们的一个项目页面的截图（该项目达到了目标，但最终并未开发）：

细节非常多，从我们那份长达多页的项目创建者常见问题解答就能看出。此外，我们还有一套完整的项目报价系统，任何人都可以提交项目建议，然后开发者为其报价，最优报价者中标。

别误会：对于这样一个复杂的系统，microPledge 的界面已经算做得不错了。我们花了大量时间推敲细节！“筹款温度计”和进度滑块清晰直观，细节通过工具提示逐步呈现，创建者和认筹者都会在投票流程中得到引导。

我们的错误出在更早的阶段：我们设计了一套精巧的系统……却没人需要。比 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 的众筹系统出售给感兴趣的买家。然而，事实证明知识产权并不值钱——有几个人表示感兴趣，但没有真正的买家。

而且我们的要价基本等同于白送——我们只是想收回一些成本。引用我们“招股说明书”中的话，潜在买家可以购买以下其中一项：

1. 完整网络软件的授权，价格为 US$7,500，包含源代码的完整权利和修改权。
2. 以上全部加上平台的完整所有权，包括独占权、转售权等。价格面议——报价需超过 US$35,000。

我们还尝试在 Flippa.com 上出售公司。同样，这也没什么进展。最终，所有出售尝试都不了了之，几年后我们让 micropledge.com 这个域名过期了。

我们的收获

失败是良师，在这几年里我们学到了很多。

商业方面

在创业方面，我们学到的东西本质上就是上面“失败原因”清单的反面：

• 从一个极简的 1.0 版本开始（KISS 原则）。
• 强调（付费）客户想要的产出。
• 聚焦于愿意付费的市场；也许不是开源。
• 先销售——在写任何代码之前。
• 仔细阅读支付系统的细则。:-)

通过这些经历，我们确实获得了宝贵的商业经验：我的哥哥 Bryan 创建了 microPledge 的母公司 Brush Technology，microPledge 失败后，我和 Berwyn 又一起帮他运营了数年，该公司至今仍作为一家软硬件咨询公司在运营。

microPledge 几年后，我们又创办了另一家创业公司 Hivemind，它生产有形产品：一套用于蜂箱的电子监测与报告系统。向养蜂人销售很不容易，但这家创业公司的发展要好得多，我们也将之前学到的几条教训付诸了实践。

技术方面

作为一名没有接受过正规软件工程训练的程序员，我想直到多年以后才意识到自己从这次创业经历中学到了多少。

在技术方面，我学会了网页开发（HTTP、HTML 表单，以及足以“惹麻烦”的 CSS 和 JavaScript）。我学会了 Python 开发，以及关系型数据库和 SQL（特别是 PostgreSQL）。刚开始时 Bryan 可能是我们当中最懂这些的人，不过我想我们每个人都学到了很多。

我还了解了网页框架：我们评估过 Django，但最终选择了 web.py，这是一个由 Aaron Swartz 创建的微框架。令我惊讶的是它至今仍在积极维护。我至今仍喜欢小而轻的网络工具：更像是库，而非框架。

我学到的另一件事是我称之为“diff 测试”的方法。这是 Berwyn 的主意，不过我确定这并非他的原创——我听过它被称为“快照测试”或“使用黄金文件的测试”。基本思路是将测试的预期输出保存到文件中，并将该快照提交到版本控制中。然后运行待测代码时，将输出写入一个新文件，测试只需将其与快照进行 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 域名过期：一个时代的终结。