许多软件创业者失败的原因很简单：产品发布得太晚。他们在真空中埋头开发数年，结果真实用户一上手，产品就土崩瓦解。

Indie Hackers 播客里就有不少这样的故事。节目的宗旨是帮助听众从创业者的错误中吸取教训，但主持人 Courtland Allen 却常常流露出一种近乎存在主义式的焦虑：这真的能做到吗？

……有些事情，你就算说破嘴皮子反复叮嘱，人们还是不会听，也不会真正明白你在说什么，直到他们自己出去摔了跟头、犯了错，才会艰难地领会你的意思。

-Courtland Allen，Indie Hackers 播客

我当时总想：“得了吧，Courtland。这也太没效率了。我就白拿这些现成的教训，才不去犯那些代价高昂的错误呢，谢谢。”

看到这篇文章的标题，你大概已经猜到，我的如意算盘落空了。

产品创意

这个想法是在我盯着自己写过的最丑陋的一段代码时冒出来的。那段代码在一个我去年做的菜谱搜索工具里。这个应用一直不温不火，但偶尔做做还挺有意思。代码库里有一个角落始终让我头疼：食材解析。

比如给定这样一个字符串 "2 cups finely chopped red onions"，应用就得判断出 2 是数量，cups 是计量单位，等等：

起初解析还算简单，但随着各种边界情况不断出现，逻辑变得越来越脆弱、越来越复杂。久而久之，这套逻辑退化成了一座由正则表达式构成的、让人抓狂的迷宫——这种处理文本的指令虽然强大，却也出了名的难读。

我很想把这些全部推倒重来，换成机器学习方案，但那将是一个巨大的工程。我不可能为一个根本不赚钱的网站上的小功能投入好几个月的开发时间。

然后，我突然灵光一现：如果食材解析本身就是一门生意呢？如果这对我是个难题，那其他开发者肯定也在为它发愁。希望其中有些人是赚钱的，如果我能帮他们解决问题，他们或许愿意分我一点。于是，我的食材解析服务 Zestful 的想法就此诞生。

那个算不上 MVP 的 MVP

在精益创业的圈子里，人们常把“MVP”——最小可行产品挂在嘴边。MVP 就是一个想法的最简版本。你应该尽快把它做出来，交到潜在客户手里，再根据他们的反应来判断它是否真的解决了某个实际问题。

最常见的失败故事之一，就是创始人对自己的想法过于自信，以至于忽略了打造 MVP。相反，他们花上数月甚至数年去打磨一个完整产品，结果却无人问津。

做 Zestful 时，我确实做了一个 MVP。我甚至提前定好了验收标准，就是为了防止自己掉进无休止的微调和优化的兔子洞里。

大约 120 个小时的开发之后，我的可运行原型就满足了验收标准。

然而，我又过了两个月才正式发布。这段时间里，我全花在继续写代码上了。

没关系，这可是在写销售型代码

你可能会好奇，我的 MVP 都已经“完成”了，怎么还会原地打转这么久。好吧，下面就是那两个月里我的心路历程总结：

第 1 天：已达成验收标准

服务能跑了！但客户只有会写复杂的命令行表达式才能用。

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

5 天后

基础前端能用了，但就这么孤零零地放一个 HTML 表单在那里，连个说明都没有，实在太奇怪了。

我得围绕这个表单建一个网站。不过就是个超级简单的网站——一天就能搞定。

4 天后

好了，太好了！服务有网站了。

……但网站还没有解释每个字段的文档页面。我今天下午就能把它弄完。

2 天后

现在页面太多了，导航栏在手机上都溢出了。

我来把导航栏做成响应式的。用我的前端框架 Angular，这肯定只要一个小时。

8 天后……

这就像九头蛇。每次我刚加上“再加一个简单的东西”，就会冒出两件因为它而不得不做的事。到最后，自从宣布代码完成已经过去了两个月，我都惊讶于自己居然还没发布任何东西。

这事很重要，但可以等等

我必须要发布了。然而，我的关键任务清单还是没做完。我估算了一下，还得五天才能完成。

然后，一件有趣的事发生了。在下定决心要尽快发布之后，我意识到“必须要有”和“发布前必须要有”其实是两回事。

一个例子就是我的使用条款。如果我先上线，过几天再补上会怎样？最坏的情况不过是在发生法律纠纷时会处于弱势，但上线几天内就有人来告我的概率能有多大？

少废话，快上线

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

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

我拖延发布，是为了逃避被拒绝吗？

在“已完成”和“已上线”之间那两个月的真空期里，一位朋友问我，是不是害怕把产品拿给客户看。那些拖延发布的任务，会不会只是一种逃避被拒绝的方式？

这个念头我也闪现过，但很快就被我否定了。我以前做过销售，每天打陌生电话，被拒绝 40 次。被拒绝可吓不到我。

上线那天，我坐下来写第一封陌生推销邮件：写给一位素不相识的菜谱应用开发者。我得解释清楚，为什么他们应该把我的食材服务集成到他们的应用里。

我盯着空白屏幕整整半小时，一个字都写不出来。我已经向朋友解释过几十次我的服务了，但这一次不一样。每当我想到一个潜在的卖点，脑海里就会浮现客户尖锐的反驳：

这值得你开的那个价吗？

这怎么帮我增加利润？

我为什么需要你？

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

另一种拒绝

这和做销售时完全不同。那份工作是向企业推销光纤网络，但光纤不是我铺的，网络也不是我设计的。坦然接受那种拒绝很容易。

现在，我卖的是自己创造的东西。更何况，那是我写的软件。写软件是我身份认同中极其重要的一部分。没有什么是我做得更好、也更引以为傲的了。如果我把产品展示给客户，他们可能会想：“这东西不怎么样。你拿来卖，说明你觉得它很好。所以，你也不怎么样。”

残酷的现实

在几十次推销、几次对话、零成交之后，我才恍然大悟：我已经成了那个花了数月时间投入到一个客户根本不想要的产品上的开发者。

有些企业确实能用上我这样的服务，但最需要它的那些早就自己造轮子了。剩下的人虽然也觉得这是个不错的服务，却无法证明这笔开销是合理的，哪怕服务一个月只要 20 美元。

就在这里，我发现了自己策略中的致命缺陷。对我的客户来说，最大的成本不是我那点月费，而是为了集成我的服务而去修改他们应用的成本。

除此之外，他们还得权衡增加一个外部依赖的成本。如果我的服务宕机了怎么办？他们的应用会不会也跟着挂掉？还是说，他们得为我的服务失效的情况再单独搭建一套备用运行模式？

我把顺序搞反了

回过头看，我的整个流程都是反的。向客户做陌生推销是我的最后一步，但我本该在写下一行代码之前就去做这件事。

一开始，我为自己先做产品的决定找了个合理的借口：客户可能口头上答应这个想法，最后却根本不会买。我想要的“答应”是真金白银的销售，是客户通过购买服务来表示认可。

虽然这个逻辑现在听来依然有道理，但我却忽略了“拒绝”的价值。如果客户在概念阶段就拒绝了产品，那我把它做出来之后，他们也不太可能改变主意。如果所有人都说不，那这条路很可能就是死胡同。

编辑：Samantha Mason。插图：Loraine Yow。