许多软件创始人失败的原因很简单：他们发布产品太晚。他们花费数年时间在真空中开发产品，结果第一次让真实客户接触到产品时，产品就崩溃了。

Indie Hackers 播客中就有许多这样的故事。节目公开宣称的使命是帮助听众从创业者的错误中学习，但主持人 Courtland Allen（考特兰·艾伦）却经常流露出一种存在主义式的苦恼，怀疑这件事是否真的可能做到：

……有些事情，你可以反复告诉别人，讲到口干舌燥，但在他们亲自犯错、用痛苦的方式发现你的话到底是什么意思之前，他们仍然不会听，也不会真正理解你在说什么。

——Courtland Allen，Indie Hackers 播客

我一直想：“不，Courtland。这听起来效率太低了。我会吸取这些免费的教训，不去犯那些代价高昂的错误，谢谢。”

看到这篇文章的标题，你大概已经猜到我的计划没能奏效。

产品创意

这个想法是在我盯着自己写过的最丑陋的代码时冒出来的。那段代码属于我去年创建的一个菜谱搜索工具。那个应用始终没能发展起来，但偶尔做做还是挺有意思的。代码库里有一块一直让我头疼：配料解析。

给定像 "2 cups finely chopped red onions" 这样的字符串，应用需要识别出 2 是数量，cups 是计量单位，依此类推：

一开始，解析很简单，但随着新的边界情况不断出现，它也变得越来越脆弱、越来越复杂。久而久之，这套逻辑逐渐腐化成了一座令人抓狂的正则表达式（regular expressions）迷宫——正则表达式是一套用于处理文本的指令，功能强大，却也以难以阅读而闻名。

我很想彻底放弃这一切，改用机器学习（machine learning）方案，但那将是一项规模巨大的工作。我不可能在一个不赚钱的网站上，为一个次要功能投入数月的开发时间。

然后我突然想到：如果配料解析本身就是一门生意呢？如果这对我来说是个问题，那其他开发者肯定也会为此苦恼。希望其中一些人赚了钱；如果我能解决他们的问题，他们应该愿意把其中一部分钱给我。于是，我的配料解析服务 Zestful 就这样诞生了。

并不存在的 MVP

在精益创业领域，人们经常谈论“MVP”，即最小可行产品（minimum viable product）。MVP 是一个创意最简单的版本。按照要求，你应该尽快把它做出来，交到潜在客户手中，然后根据他们的反应判断它是否解决了一个真实问题。

最常见的失败故事之一，就是创始人对自己的想法过于自信，以至于忽略了构建 MVP。相反，他们投入数月甚至数年时间，打造出一个没人想要的完整产品。

对于 Zestful，我确实构建了一个 MVP。我甚至预先定义了验收标准，防止自己掉进无休止调整和改进的兔子洞。

经过大约 120 个小时的开发工作，我的工作原型满足了验收标准。

然而，我又过了两个月才正式发布。那段时间里，我没有发布产品，而是继续写代码。

没关系，因为这是在写销售代码

你可能会想知道，我的 MVP 明明已经“完成”了，为什么之后还会原地打转这么久。下面是那两个月里我的思路概述：

第 1 天：完成验收标准

服务能用了！但客户只有在命令行中写复杂表达式才能使用它。

在 Web 3.1 时代，我怎么能让客户蒙受编写 curl 命令的屈辱？加一个简单的 HTML 前端，客户就能直接在浏览器中测试这项服务了。

5 天后

基本的前端能用了，但让这个孤零零的 HTML 表单在那里，却没有任何说明，感觉很奇怪。

我需要围绕这个表单做一个网站。不过会是个极其简单的网站——只需要一天时间。

4 天后

好了，太棒了！这项服务有网站了。

……但网站没有文档页面来解释每个字段。我今天下午就能把这个搞定。

2 天后

现在页面太多了，导航栏在移动设备上显示不下了。

我要让导航栏支持响应式布局。用我的 Web 框架 Angular，这肯定只需要一个小时。

8 天后……

这简直就是九头蛇。每次我加完“再加一个简单功能”，都会因此冒出另外两个必需的功能。最终，从我宣布代码完成算起，两个月过去了，而我却困惑地发现自己什么都没发布。

这很重要，但可以等一等

我必须发布。然而，我的关键任务清单仍然没有完成。我估计还需要五天才能做完。

然后，一件有趣的事情发生了。在下定决心尽快发布之后，我意识到“必须具备”和“发布所必需”之间存在差别。

一个例子是我的使用条款。如果我不等它就绪，先发布，过几天再写，会发生什么？最坏的情况是，如果发生法律纠纷，我会处于不利地位；但在发布后的几天内，有人起诉我的概率有多大？

别废话，直接发布

对于任务清单上的每一项，我都问自己：“如果没有它就发布，会发生什么？”用对待使用条款时同样无情的怀疑态度审视每项任务后，我真正的发布清单浮现出来了。不到 24 小时后，我就把 Zestful发布到了 RapidAPI 这个 API 市场。我的服务上线了！

现在到了见真章的时刻。我的服务已经准备好接受真实客户的付款。我只需要说服他们购买。

我是不是为了逃避被拒绝而推迟发布？

在“完成”和“发布”之间那两个月的悬置期里，一位朋友问我，是不是害怕把产品展示给客户。那些推迟发布的任务，是否只是我逃避被拒绝的一种方式？

我确实想过这个问题，但很快就否定了这种可能。我以前做过销售，每天打陌生电话联系客户，听到 40 次“不”都不在话下。被拒绝并不可怕。

发布当天，我坐下来准备写第一封陌生推介（cold pitch）：给一位不认识我的菜谱应用开发者发邮件。我必须解释为什么他们应该把我的配料服务集成到自己的应用中。

我盯着空白屏幕挣扎了半个小时，什么都写不出来。我已经向朋友解释过几十次自己的服务，但这次不一样。每当我想到一个潜在的卖点，就会想象客户严厉的反驳：

这凭什么值得你收这么高的价格？

这怎么能增加我的利润？

我为什么需要你？

糟糕。我确实害怕被拒绝。

另一种被拒绝

这和做销售完全不同。那份工作要求我向企业销售光纤互联网，但光纤不是我铺设的，网络也不是我设计的。所以面对拒绝，我很容易一笑置之。

而现在，我卖的是自己创造的东西。更何况，这是我亲手写的软件。写软件是我身份认同中非常重要的一部分。我没有其他事情能做得更好，也没有其他事情能让我如此自豪。如果我把产品展示给客户，他们可能会想：“这东西不怎么样。你想把它卖出去，所以你一定觉得它不错。那么，你也不怎么样。”

残酷的现实

在进行了几十次推介、几次交谈，却一笔生意都没做成之后，我终于意识到，自己已经成了那种花费数月时间打造客户并不想要的产品的开发者。

有些企业确实可以使用类似我的服务，但最需要它的那些企业已经自己实现了这项功能。其他企业都认为这项服务挺不错，却无法证明这笔开支合理，尽管这项服务每月只收费 20 美元。

而这正是我发现自己策略中致命缺陷的地方。对客户来说，最重要的成本不是我的月费，而是修改他们的应用、集成我的服务所需的成本。

除此之外，他们还必须权衡增加一个外部依赖的成本。如果我的服务发生故障，会怎么样？他们的应用会停止工作吗？还是说，他们需要为我的服务失效的情况，构建一整套备用运行模式？

我把顺序完全搞反了

现在回头看，我的流程完全颠倒了。向客户进行陌生推介是我最后一步，但我本应该在写下第一行代码之前就做这件事。

一开始，我为先做产品的决定找了个理由。客户可能会对这个想法说“是”，但之后却始终不购买产品。我想要的“是”必须是真正的销售，是客户通过购买服务来表示同意。

虽然这个逻辑现在听起来仍然有道理，但我没有考虑到“不”的价值。如果客户在概念阶段就拒绝了产品，那么在我把它做出来之后，他们也不会改变主意。如果所有人都说“不”，那它很可能就是一条死路。

由 Samantha Mason（萨曼莎·梅森）编辑。插画：Loraine Yow（洛林·姚）。