做不可规模化的事
2013年7月
在 Y Combinator，我们给出的最常见的建议之一，就是去做那些不可规模化的事。很多有志于创业的人相信，初创公司要么自然起飞，要么就不会。你造出一个东西，放出去，如果真是更好的捕鼠夹，人们会按承诺踏破你的门槛——要么如此，要么市场根本不存在。[1]
事实上，初创公司起飞，是因为创始人让它们起飞。也许有极少数是自己长起来的，但通常需要某种推力才能让它们动起来。有个好比喻：汽车引擎在有电子启动器之前，需要手摇曲柄来启动。引擎一旦运转，就会持续运转，但启动本身是一个独立而费力的过程。
招募
创始人在起步阶段必须做的最常见的不可规模化的事，就是手动招募用户。几乎所有初创公司都必须如此。你不能等用户来找你，你必须主动出去找到他们。
Stripe 是我们资助过的最成功的初创公司之一，他们解决的是一个迫切的问题。如果有哪家公司可以坐等用户上门，那应该是 Stripe。但事实上，他们在 YC 内部以早期积极获客而闻名。
为其他初创公司服务的初创公司，在我们资助的其他公司里有一大批潜在用户，而充分利用这一点的莫过于 Stripe。在 YC 我们用"Collison 安装法"来称呼他们发明的这个技巧。腼腆一些的创始人会问：“你愿意试试我们的 beta 版吗？“如果对方答应，他们就说：“太好了，我们发个链接给你。“但 Collison 兄弟可不想等。每当有人同意试用 Stripe，他们就会说：“好，把你的电脑给我”，当场帮对方完成注册。
创始人不愿意亲自出去招募用户，有两个原因。一是害羞加懒惰的综合体——他们宁愿待在家里写代码，也不愿出去跟一堆陌生人打交道，还可能被大多数人拒绝。但一家初创公司要成功，至少要有一位创始人（通常是 CEO）必须花大量时间在销售和市场营销上。[2]
另一个原因是，刚开始的绝对数字看起来太小了。他们心想：那些大名鼎鼎的成功初创公司，不可能就是这样起步的。他们犯的错误，是低估了复利增长的威力。我们鼓励每家初创公司以每周增长率来衡量进展。如果你有100个用户，下周需要再增加10个，才能实现10%的周增长率。虽然110和100看起来差不多，但如果你保持每周10%的增长，你会惊讶于数字会变得多大。一年后你将有14000个用户，两年后将有200万。
当你每次获取一千名用户时，你做的事情会不一样，增长最终也必然会放缓。但如果市场存在，你通常可以先从手动招募用户开始，然后逐步切换到不那么手动的方式。[3]
Airbnb 是这个技巧的经典案例。平台型产品极难滚动起来，你应该预期刚开始要采取非常之举。Airbnb 的做法，是在纽约挨家挨户上门，招募新用户，并帮助现有用户改善他们的房源页面。我记忆中 YC 时期的 Airbnb 创始人，是拎着行李箱的形象，因为每次周二晚餐出现时，他们都是刚从某个地方飞回来。
脆弱
Airbnb 现在看起来势不可挡，但在早期，它脆弱到只需要大约30天亲身和用户互动，就能决定成败。
这种初期脆弱性并非 Airbnb 独有。几乎所有初创公司在早期都是脆弱的。而这正是缺乏经验的创始人和投资人（以及记者和论坛上的事后诸葛亮）最常犯的错误：他们不自觉地用成熟公司的标准来评判处于幼虫期的初创公司。就像有人看着一个刚出生的婴儿，然后下结论：“这么小的家伙，根本不可能成就什么大事。”
记者和事后诸葛亮看不上你的初创公司，无伤大雅——他们总是会把事情看错。即便投资人看不上你的初创公司也没什么；看到增长，他们会改变想法。最大的危险，是你自己看扁了自己的初创公司。我见过这种事发生。我经常要鼓励那些看不到自己所做之事全部潜力的创始人。就连比尔·盖茨也犯过这个错误。他在创办微软之后，回哈佛读了秋季学期。他没待多久，但如果他意识到微软会变成后来那样的规模哪怕一个零头，他根本就不会回去。[4]
评估早期初创公司，正确的问题不是"这家公司能主宰世界吗”，而是"如果创始人做对了，这家公司最大能做多大”。而那些正确的事，当时往往看起来既费力又无关紧要。当微软只是阿尔伯克基的几个人，为几千名爱好者（当时就是这么叫的）市场写 Basic 解释器时，它看起来不可能有什么了不起，但回头来看，那是主宰微型电脑软件的最优路径。我知道 Brian Chesky 和 Joe Gebbia 在为最早的房东公寓拍"专业"照片时，并不觉得自己正在走向辉煌。他们只是在努力活下去。但回头来看，那也是主宰一个大市场的最优路径。
如何找到可以手动招募的用户？如果你是为了解决自己的问题而构建产品，你只需要找到和你类似的人，这通常不难。否则，你就需要更主动地去找出最有价值的用户群。通常的做法是：先通过一次大撒网式的发布，获得初始的一批用户，然后观察哪种类型的人最热情，再去主动寻找更多同类用户。比如，Ben Silbermann 注意到 Pinterest 最早的用户中有很多对设计感兴趣，于是他去参加了一个设计博主大会招募用户，效果很好。[5]
让用户欣喜
你应该采取非常之举，不只是为了获取用户，还要让他们满心欢喜。在力所能及的时间里（结果出乎意料地久），Wufoo 给每一位新用户发手写感谢信。你的第一批用户应该觉得，注册你的产品是他们做过的最好选择之一。而你也应该绞尽脑汁，想出新的方法让他们喜出望外。
为什么我们要教初创公司这些？为什么创始人对此缺乏直觉？我想有三个原因。
其一，很多创业者受过工程师训练，而客户服务不在工程师的训练体系中。你应该构建健壮优雅的东西，而不是像销售人员那样对个别用户百般体贴。讽刺的是，工程文化传统上排斥手把手服务用户，部分原因是这种传统形成于工程师力量较弱的年代——那时工程师只负责自己那一亩三分地，而不是主导全局。你是 Scotty 的时候可以耍脾气，但你是 Kirk 的时候就不行了。
另一个原因是，创始人担心这样做无法规模化。但当幼虫期初创公司的创始人担心这个问题时，我会指出，他们现在没什么可输的。也许他们竭尽全力让现有用户超级满意，总有一天会多到无法这样对待每一个人。那将是一个很棒的问题。去看看你能不能让它发生。顺带一提，当那一天真的到来，你会发现让用户欣喜，比你预期的更具规模化的可能性——一方面是因为你通常能找到让任何事情比预期更好地规模化的方法，另一方面是因为让用户欣喜到那时已经渗透进你的企业文化。
我从未见过哪家初创公司因为对初期用户太过用心而走入死胡同。
但也许最大的阻碍，是创始人从未亲身体验过那种细致入微的关怀。他们对客户服务的标准，是从他们作为消费者接触过的公司——大多是大公司——那里形成的。Tim Cook 不会在你买了笔记本之后给你发手写便条，他做不到。但你可以。这是小公司的一个优势：你能提供大公司无法企及的服务水平。[6]
一旦你意识到现有的惯例并非用户体验的天花板，以一种令人愉悦的方式去思考你能为用户走多远，就会是一件很有趣的事。
体验
我试图找一个词来表达你对用户的关注应该达到何种程度，然后我意识到 Steve Jobs 早就说出来了：insanely great（疯狂的好）。Steve 用"insanely"并不只是"非常"的同义词，他的意思更字面——应该将执行质量的关注推到在日常生活中会被视为病态的程度。
我们资助过的所有最成功的初创公司都做到了这一点，这也许并不出乎有志创业者的意料。新手创始人没有领悟的，是"疯狂的好"在一家幼虫期初创公司中意味着什么。当 Steve Jobs 开始使用这个短语时，苹果已经是一家成熟的公司了。他的意思是 Mac（以及它的文档，甚至包装——这就是痴迷的本质）应该设计得和制造得疯狂地好。这对工程师来说不难理解，不过是把"设计出健壮优雅的产品"推到更极端的程度。
创始人难以领悟的（Steve 本人或许也难以领悟）是：当你把时间轴往前拨到初创公司创立头几个月时，“疯狂的好"会变形成什么。应该疯狂地好的不是产品，而是成为你用户的那种体验。产品只是其中一个组成部分。对大公司来说，它必然是主导部分。但你完全可以，也应该给用户提供一种疯狂好的体验——哪怕产品还处于早期、不完整、充满 bug 的状态，只要你用关怀来弥补差距。
可以，也许，但应该吗？是的。对早期用户的过度投入，不只是一种获取增长的许可技巧。对大多数成功的初创公司来说，它是让产品变好的反馈循环中必不可少的一环。造出更好的捕鼠夹不是一个原子操作。即便你从大多数成功初创公司的起点出发——构建你自己需要的东西，第一个版本也从来不会完全对。而除了在错误代价极高的领域，往往最好不要一开始就追求完美。在软件领域尤其如此，通常最好的做法是：只要有一点实用价值，就尽快拿到用户面前，然后看他们怎么用它。完美主义往往是拖延的借口，而且无论如何，你对用户的初始模型总是不准确的，即便你自己就是其中一个用户。[7]
和最早期用户直接互动所获得的反馈，将是你得到过的最宝贵的反馈。当你大到只能依靠焦点小组时，你会希望自己能像只有几个用户时那样，去到用户的家里和办公室，看他们怎么使用你的东西。
燃火
有时候，正确的不可规模化的技巧，是主动聚焦于一个刻意缩小的市场。这就像先把火控制在小范围内，让它烧旺，再添加更多木柴。
Facebook 就是这么做的。起初它只面向哈佛学生。这种形态下，潜在市场只有几千人，但正因为学生们觉得它真的是为自己打造的，足够多的人注册了。Facebook 在不再只是哈佛学生的专属之后，还在相当长的时间里只服务于特定大学的学生。我采访 Mark Zuckerberg 时，他说，虽然为每所学校建立课程列表是很大的工作量，但这样做让学生觉得这个网站是他们天然的家园。
任何可以被描述为平台型产品的初创公司，通常必须先从市场的某个子集起步，但这对其他类型的初创公司也同样有效。始终值得问一句：有没有某个子市场，能让你快速达到临界用户数量？[8]
大多数采用"燃火"策略的初创公司，做的时候并没有刻意为之。他们为自己和朋友构建产品——而这些朋友恰好是早期用户——然后才意识到，原来可以把它推向更广阔的市场。不刻意为之，策略照样奏效。不有意识地了解这个模式最大的危险，是那些会天真地丢掉其中某一部分的人。比如，如果你不是为自己和朋友构建产品，或者即便是，但你来自企业界，你的朋友都不是早期用户，那么你就不再有一个现成的完美初始市场了。
在各类公司中，最好的早期用户通常是其他初创公司。它们天然对新事物更开放，而且因为刚刚创立，还没有把所有选择都锁定。更重要的是，当它们成功，它们会快速增长，你也随之增长。这是 YC 模式（尤其是把 YC 做大）众多意外收获之一：B2B 初创公司现在有了一个现成的、数百家初创公司组成的即时市场。
Meraki 式创业
对于硬件初创公司，有一种做不可规模化之事的变体，我们称之为"Meraki 式创业”。虽然我们没有投资 Meraki，但其创始人是 Robert Morris 的研究生，所以我们了解他们的历史。他们起步做的是真正不可规模化的事：自己动手组装路由器。
硬件初创公司面临一个软件初创公司没有的障碍。工厂生产的最低订单量通常是几十万美元。这会把你带进一个两难困境：没有产品，就无法产生融资所需的增长；没有融资，就无法生产产品。在硬件初创公司还得依靠投资人融资的年代，你需要极具说服力才能跨过这道坎。众筹（或者更准确地说，预售）的出现帮了大忙。但即便如此，我仍建议硬件初创公司在可能的情况下，先走 Meraki 式路线。Pebble 就是这么做的。Pebble 的创始人自己组装了最初的几百块手表。如果他们没有经历那个阶段，上 Kickstarter 时大概也卖不出价值1000万美元的手表。
和过度关注早期用户一样，自己动手制造也是硬件初创公司的宝贵经历。当你就是那个工厂，设计迭代会快得多；你还会学到许多否则永远不会知道的事。Pebble 的 Eric Migicovsky 说他学到的事情之一是：“选到好螺丝有多关键。“谁能想到呢？
咨询
有时候我们会建议 B2B 初创公司的创始人，把深度参与推向极致——选定一个单一用户，像是在为那一个用户做专属咨询一样行事。这个初始用户充当铸模的模具；不断调整，直到完美契合他们的需求，你通常会发现，你做出来的东西其他用户也想要。即便这样的用户不多，也可能有邻近的领域蕴含更多用户。只要你能找到哪怕一个真正需要某样东西、并能付诸行动的用户，你就已经在构建人们真正想要的东西上站稳了脚跟——这对任何初创公司的起步来说都已足够。[9]
咨询是不可规模化的工作的典型例子。但（就像慷慨施恩的其他方式一样），只要你不以此收费，就可以放心去做。公司越界的地方就在这里。只要你是一家产品公司，只是对某个客户格外用心，他们就算你没能解决所有问题，也会非常感激。但一旦他们开始专门为你的这份用心付钱——开始按小时付你钱——他们就会期待你做所有的事。
另一种咨询式的技巧，用于招募那些起初不那么热情的用户：代替他们使用你自己的软件。我们在 Viaweb 就是这样做的。当我们去找商家，问他们是否愿意用我们的软件搭建网上商店时，有些人说不，但愿意让我们替他们搭建一个。为了获取用户，我们什么都愿意做，于是我们就这么做了。当时我们觉得自己很没出息——没有在促成宏大的电子商务战略合作，却在卖行李箱、钢笔和男士衬衫。但回头来看，这恰恰是正确的事，因为它让我们了解到商家使用我们软件的感受。反馈循环有时几乎是即时的：在给某个商家搭建网站的中途，我发现我们缺少某个功能，于是花几个小时把它做出来，然后继续搭建网站。
手动
还有一种更极端的变体：你不只是使用自己的软件，而是化身为软件本身。当用户数量还很少时，有时可以手动完成你计划后来自动化的工作。这让你能更快发布，而且当你最终将自己从循环中自动化掉时，你会确切地知道应该构建什么，因为你已经亲手做过，有了肌肉记忆。
当手动部分在用户眼中看起来像软件时，这个技巧开始带有恶作剧的色彩。比如，Stripe 向最初的用户提供"即时"商家账户的方式，是创始人在幕后手动为他们申请传统商家账户。
有些初创公司起初可以完全手动运作。如果你能找到一个有问题需要解决的人，而你可以手动解决它，那就大胆去做，能做多久就做多久，然后逐步将瓶颈自动化。用一种还没自动化的方式解决用户问题，听起来有点让人不安，但它比另一种更常见的情况要好多了——你有了一个自动化的系统，却还没能解决任何人的问题。
大发布
我应该提到一种通常没用的初始策略：大规模发布。我偶尔会遇到一些创始人，他们似乎相信初创公司是抛射物而不是有动力的飞机——只要发射时的初速度足够大，就能飞得足够远。他们想同时出现在8个不同的媒体上，并且附带发布禁令。当然，还要在周二，因为他们在哪里看到说周二是发布的最佳日期。
发布的重要性有多小，很容易看出来。想想一些成功的初创公司，你还记得他们的发布吗？一次发布，你需要的不过是初始的一批核心用户。几个月后你的状态好不好，更多取决于你让那些用户有多满意，而不是他们有多少。[10]
那么为什么创始人觉得发布很重要？自恋加懒惰的综合体。他们认为自己在构建的东西如此了不起，每个听说它的人都会立刻注册。而且，如果靠广而告之就能获得用户，而不是一个个手动招募，工作量也会少得多。但即便你在构建的东西真的很了不起，获取用户始终是个渐进的过程——部分原因是了不起的东西通常也是新鲜的东西，但主要原因是用户有其他事情要操心。
合作关系通常也没用。对初创公司普遍没用，用来启动增长则尤其没用。缺乏经验的创始人常犯的一个错误，是相信与大公司的合作将是他们的重大突破。六个月后他们都在说同一件事：这比我们预期的工作量大得多，最终我们几乎什么都没得到。[11]
只在开始阶段做出非凡之举还不够，你必须在开始阶段付出非凡的努力。任何省略了这份努力的策略——无论是指望大规模发布来带来用户，还是寄望于大公司合作伙伴——本身就值得怀疑。
向量
做不可规模化的费力之事才能起步，这几乎是普遍规律，所以也许是时候停止把初创想法看作标量了。我们应该尝试把它们看作向量：你将要构建的东西，加上你最初为启动公司而要做的不可规模化的事。
以这种方式来看初创想法，会很有意思，因为有了两个分量，你可以在第二个分量上和第一个分量一样发挥想象力。但在大多数情况下，第二个分量会是一成不变的那个——手动招募用户，给他们提供令人难以置信的好体验——而把初创公司视为向量的主要好处，是提醒创始人需要在两个维度上努力。[12]
在最好的情况下，向量的两个分量都会对公司的基因有所贡献：那些为了起步而必须做的不可规模化的事，不只是必要之恶，而是永久性地让公司变得更好。如果你在公司小的时候必须积极主动地获取用户，等公司大了，你可能仍然积极主动。如果你必须自己制造硬件，或者代替用户使用软件，你会学到其他方式永远学不到的东西。最重要的是，如果你在只有少数几个用户时，必须努力让他们欣喜，当你有了很多用户时，你仍会这样做。
注释
[1] 其实爱默生从未专门提过捕鼠夹，他写的是：“如果一个人有好的玉米、木材、板材或猪要卖，或者能做出比任何人都更好的椅子、刀具、坩埚或教堂风琴，即便他身处林中，你也会发现一条宽阔而坚实的路通向他家。”
[2] 感谢 Sam Altman 建议我把这点说清楚。不，你不能通过雇人来代替自己做销售。最开始你必须自己做销售，之后才能雇一个真正的销售来接替你。
[3] 这之所以奏效，是因为随着你变大，体量本身会帮你增长。Patrick Collison 写道：“在某个时刻，Stripe 的感觉发生了非常明显的变化。它从我们不得不推动的巨石，变成了一节本身就有动力的车厢。”
[4] YC 能帮助创始人的一个较微妙的方式，是校准他们的雄心，因为我们确切地知道许多成功初创公司在刚起步时的样子。
[5] 如果你在构建的东西很难找到小批用户去观察——比如企业软件——而且你在这个领域也没有人脉，你就不得不依靠陌生拜访和引荐。但你真的应该在这样的想法上工作吗？
[6] Garry Tan 指出了创始人在起步阶段会掉入的一个有趣陷阱。他们太想表现得像大公司了，于是连大公司的缺点也一起模仿，比如对个别用户漠不关心。这在他们看来更"专业”。其实，更好的做法是接受自己很小这个事实，并利用它带来的一切优势。
[7] 你对用户的模型几乎不可能完全准确，因为用户的需求往往会随着你为他们构建的东西而改变。给他们造一台微型电脑，他们突然就需要在上面跑电子表格，因为你的新微型电脑的出现，促使有人发明了电子表格。
[8] 如果你必须在最快注册的子集和付费最多的子集之间做选择，通常最好选前者，因为那很可能是早期用户。他们对你产品的影响更好，而且不会让你在销售上耗费太多精力。虽然他们的钱更少，但在早期维持目标增长率，你并不需要那么多钱。
[9] 是的，我能想象到一些情况，你最终做出的东西可能真的只对一个用户有用。但那些情况通常很明显，即便对缺乏经验的创始人也是如此。所以如果做出一个只有一个用户的市场的产品这种风险并不明显，就不用担心它。
[10] 甚至可能发布规模与成功之间存在负相关。我记得的发布，都是像 Segway 和 Google Wave 这样著名的失败。Wave 尤其令人警惕，因为我认为它本来是个很棒的想法，却部分地被过度包装的发布所扼杀。
[11] 谷歌靠着雅虎的助力做大，但那不是合作关系。雅虎是他们的客户。
[12] 这也会提醒创始人：一个第二分量为空的想法——一个没有任何你能做到的起步方式的想法，比如你根本找不到可以手动招募的用户——很可能是个坏想法，至少对那些创始人来说是如此。
感谢 Sam Altman、Paul Buchheit、Patrick Collison、Kevin Hale、Steven Levy、Jessica Livingston、Geoff Ralston 和 Garry Tan 审阅本文草稿。
英文版：paulgraham.com/ds.html｜中文版：hijiangchuan.com/paulgraham/153-do-things-that-dont-scale
更新记录：
- 2026-03-24 HiJiangChuan 初稿翻译，术语待验证；