# 候补名单已经过时了吗？

URL: https://www.mattsenter.com/zh/blog/is-the-waitlist-dead

应用发布得更快了，让客户等待就需要更充分的理由。

你宣布要做一款应用，搭个落地页，收集邮箱，告诉大家：令人期待的东西就要来了。

与此同时，另一个人看到同样的机会，打开编程智能体，开始动手。

等你发出“快准备好了”的邮件，潜在客户可能已经在用别的产品。

这就是在智能体开发时代，我对创业公司候补名单的疑问。从一个想法到可用版本，所需时间已经改变。我不太确定，关于产品发布的建议是否跟上了变化。

如果今天就能提供有用的东西，为什么还要让人以后再来？

## 旧方法有它的理由

过去开发产品需要数月工程投入，候补名单让创始人能够接住早期兴趣：测试文案、招募测试用户，在软件逐渐成形的同时聚集受众。

[Linear](https://review.firstround.com/linears-path-to-product-market-fit/) 和 [Superhuman](https://review.firstround.com/superhuman-onboarding-playbook/) 是熟悉的例子。Linear 从名单中挑选早期用户，通过小批次测试改进产品。Superhuman 大量投入一对一上手指导。两种方式都帮助团队有针对性地了解客户。

但这些策略诞生于今天的编程智能体出现之前。它们解释了旧方法的来历，却不能证明其中的取舍如今仍然合理。

当交付一个能运行的实验版本变得便宜，只收集兴趣表达就更难得到充分辩护。

邮箱地址说明有人足够喜欢你的承诺，愿意填写表单。真正使用应用的人，才能指出承诺在哪里落空。

## 你也给了竞争者时间

公开的候补名单，会在你未必已经赢得客户之前，就公布一个机会。

当产品的核心功能相对容易复现时，这一点尤其重要。公告描述问题，演示勾勒方案，报名数量展示需求。

竞争者不必复制你的整张路线图。只要先解决客户问题中的足够一部分，就能比你更早变得有用。

这是竞争风险，不是已经证实的定律。我没有找到研究证明候补名单经常导致创业公司丢掉市场。同样，先发布也不保证胜利。

尽管如此，故意拉长“我想要”和“我能用”之间的距离，仍然值得审视。

客户的问题正在发生。发布日程是你的安排。

## 新一些的例子告诉我们什么？

[Lovable 在自己的回顾中](https://www.linkedin.com/posts/lovable-dev_we-failed-2-launches-in-2024-the-third-time-activity-7278452566454120448-v343)描述了 2024 年两次不成功的发布、从名单中逐步接纳用户，以及仍然频繁卡住的 AI。公司将最终突破归因于产品改进、品牌重塑和更好的沟通。名单早就存在，但不足以带来突破。

Manus 让“限制访问的发布方式已经过时”这个断言变得复杂。它[在 2025 年 3 月开始邀请制测试](https://www.axios.com/2025/03/10/manus-chinese-ai-agent-deepseek)，之后[宣布年度经常性收入达到 1 亿美元](https://manus.im/blog/manus-100m-arr)。这说明限制式发布之后可以取得商业成功，却不能说明限制本身导致了成功，也不能说明更早开放会更差。

我们应当在两个方向上采用同样的标准。成功公司用过候补名单，不证明名单有效。失败公司用过名单，也不证明名单就是问题。

## 邀请别人进入产品，是另一回事

为一个想法收集兴趣，与控制人们已经在使用的产品的访问权限，有重要区别。

[Instinct](https://instinct.com/) 展示了邀请模式：其公开首页有“邀请朋友”的链接。这本身不能解释公司为何限制访问，但指向一种不同的互动：现有用户可以把另一个人带进产品体验。

当邀请通向真正能用的产品时，我觉得它更可信。

合理的限制确实存在。你可能每周只能支持少量新客户。运行智能体可能很贵。你可能需要先观察故障，再接纳更多人。

邀请同样可以制造稀缺感。形式不能回答问题，限制的原因才能。

## 最有力的辩护：寻找客户仍然需要投入

开发更快，并不会自动带来获客渠道。

一个近期的创始人自述说明了这一点。[Hado SEO 的创始人称](https://www.reddit.com/r/lovable/comments/1qgo3lj/how_i_went_from_0_to_1137mo_in_45_days_with_a/)，自己收集了 80 个邮箱，在发布周将其中五人转化为付费客户。发布前，他花时间在社区帮助潜在客户，打磨产品主张。这些数据来自本人，未经独立核实，但描述的是付费转化，而不只是漂亮的报名总数。

这是为短期发布准备辩护的合理理由。你可以了解客户聚在哪里、怎样描述问题，以及你能否触达他们。

但仍有一个问题：如果给同样的人一个小而能用的产品，你是否能学到更多？

开发越快，这个替代方案就越现实。

## 让等待有充分理由

我怀疑那些主要为了让未发布应用显得抢手的候补名单。

有用的名单应该对应具体限制：容量上限、客户实验、外部依赖，或者正在解决的产品问题。应该有等待的理由，也有获得访问资格的条件。

“制造热度”是弱得多的回答。

在加上邮箱表单之前，先想想能给这些人交付什么。一个工作流程。一项有用的能力。一个范围有限、却能做好一件事的版本。

然后，你就能衡量他们是否使用、是否回来，以及是否在意产品改进。

如果别人在你制造完期待之前，就能发布你这个想法的可用版本，那么你究竟在等什么？