做那些无法规模化的事
译者注：这是 Paul Graham 在 2013 年 7 月发表的经典创业指南，原文标题为 “Do Things That Don’t Scale”。作为 Y Combinator 创始人，Paul Graham 在这篇文章中分享了他观察到的成功创业公司早期的共同模式——创始人必须做那些看起来「不够优雅」、无法规模化的事情。
在 Y Combinator，我们最常给创始人说的一条建议就是：不要一开始就想着规模化，先做那些看似「不值当」的小事。
很多初创团队以为创业要么立刻起飞，要么注定失败。他们的逻辑是：你做了个产品上线，如果真的更好，人们自然会 找上门来 ；要是没人来，那就说明市场根本不存在。[1]
实际上，初创公司之所以能起飞，是因为创始人自己把它们推起来的。可能有少数公司是自然成长的，但大多数都需要创始人主动推动才能启动。
这就像老式汽车在有电动启动器之前，需要人用手摇曲柄才能发动。发动机启动后会自己运转，但启动过程本身是独立且费力的。
招募用户
创始人在早期最常做的无法规模化的事，就是亲自去招募用户。几乎所有初创公司都必须这样做。你不能坐等用户自己找上门，而要主动出击。
Stripe 是我们投资过的最成功的初创公司之一，他们解决的是一个紧迫问题。如果说有谁可以坐等用户上门，那就是 Stripe。但实际上，他们在 YC 圈内以强势的早期人工获客著称。
对于那些为其他初创公司做产品的初创公司来说，我们投资的其他公司是一个巨大的潜在用户池，而没有人比 Stripe 更好地利用了这个优势。在 YC，我们用 「Collison 安装法」 来形容他们发明的技巧。比较内向的创始人会问：「你愿意试试我们的 beta 版吗？」如果对方说愿意，他们就说：「太好了，我们发个链接给你。」但 Collison 兄弟绝不会等。只要有人同意试用 Stripe，他们会立刻说：「现在就试，把笔记本给我。」然后当场就帮你设置好。
创始人抗拒亲自招募用户有两个原因。第一个是恐惧加懒惰的组合。他们宁愿待在家里写代码，也不想出去和陌生人聊天，何况大部分人可能还会拒绝他们。但要让初创公司成功，至少有一个创始人（通常是 CEO）必须花大量时间在销售和推广上。[2]
另一个原因是，早期的绝对数字看起来实在太小了。他们觉得那些知名的初创公司不可能是这样开始的。这种想法的错误在于低估了复合增长的力量。我们鼓励每个初创公司用周增长率来衡量进展。如果你有 100 个用户，下周需要再获得 10 个才能达到 10% 的周增长率。虽然 110 看起来比 100 好不了多少，但如果你保持 10% 的周增长率，数字会大得出乎意料。一年后你会有 14,000 个用户，两年后会有 200 万。
当你一次获取上千用户时，你会做不同的事情，而且增长最终也会放缓。但如果市场存在，你通常可以先人工获客，然后逐渐转向不那么手动的方法。[3]
Airbnb 是这种做法的经典例子。市场平台是最难启动的，所以一开始你得准备采取英雄般的措施。Airbnb 就是这样：他们在纽约挨家挨户推广，招募新用户，帮助现有用户改善房源信息。
当我回想 YC 期间的 Airbnb 时，印象最深的是他们总是拖着行李箱。每次周二晚餐见到他们，他们都是刚从某个地方飞回来。
脆弱
Airbnb 现在看起来像个不可阻挡的巨头，但早期它是如此脆弱，大约 30 天的外出与用户面对面接触就决定了成功与失败的区别。
这种早期的脆弱性并不是 Airbnb 独有的。几乎所有创业公司在初期都很脆弱。这是缺乏经验的创始人、投资者（也包括记者和网上那些 懂王们 ）最容易搞错的地方之一。他们会不自觉地用成熟公司的标准来判断初创公司。就像看着刚出生的婴儿就断言「这孩子将来成不了大事」一样荒谬。
如果记者和网上那些懂王们觉得你的公司不行，那没啥值得在意的，他们总是搞错。如果投资者看轻你的公司也没关系，当他们看到增长时会改变想法的。真正的危险是你自己看轻了自己的初创公司。我见过这种情况发生。我经常需要鼓励那些看不到自己正在构建的东西的全部潜力的创始人。连比尔·盖茨都犯过这个错误。他在创办 Microsoft 后还回到哈佛读秋季学期。他没待多久，但如果他意识到 Microsoft 哪怕只会达到日后规模的哪怕一小部分，他根本不会回去。[4]
对于早期创业公司要问的问题不是「这家公司在称霸全球吗？」而是「如果创始人做了正确的事，这家公司能变多大？」而正确的事在当时往往既费力又看起来微不足道。Microsoft 刚开始时只是阿尔伯克基的几个家伙，为几千个爱好者（当时是这么叫的）的市场写 Basic 解释器，看起来一点都不了不起。但回过头看，这是统治个人电脑软件的最佳路径。Brian Chesky 和 Joe Gebbia 在为房东的公寓拍摄「专业」照片时，也并不觉得自己在走向成功。他们只是在努力生存。但回过头看，这同样是统治大市场的最佳路径。
如果你做的产品是为了解决自己的问题，那你只需要找到你的同类人，这通常很简单。否则你就需要更有目的性地去找到最有希望的用户群体。通常的做法是通过相对不精准的发布获得一些初始用户，然后观察哪种类型的用户看起来最有热情，再去寻找更多类似的人。比如，Ben Silbermann 注意到很多早期 Pinterest 用户对设计感兴趣，所以他去了一个设计博主的会议来招募用户，效果很好。[5]
取悦用户
你不仅要采取非常手段来获取用户，还要让他们开心。Wufoo 会给每个新用户寄手写感谢信，只要能做到（结果比预期的时间要长）。你的第一批用户应该觉得注册你的服务是他们做过的最好的选择之一。而你要绞尽脑汁想新的方法取悦他们。
为什么我们必须教创业公司这个？为什么这对创始人来说是反直觉的？我想有三个原因。
第一个原因是很多初创公司创始人都是工程师出身，而客户服务不在工程师的训练范围内。工程师的思维是：你应该构建强壮优雅的东西，而不是像销售一样逐一应对每位用户。
讽刺的是，工程师传统上厌恶手把手指导，部分原因是这些传统来自工程师权力较小的时代——当时他们只负责构建，不用运营整个公司。当你是 Scotty 时可以脾气暴躁，但当你是 Kirk 时就不行了。
第二个原因是创始人担心这样做无法规模化。但当初创公司的创始人担心这个时，我会指出他们目前没什么可失去的。也许如果你想方设法让现有用户超级开心，有一天用户会多到无法为每个人做这么多。那将是一个很棒的问题。试试看能不能让它发生。
顺便说一下，当它真的发生时，你会发现取悦客户比预期的更容易规模化。部分原因是你通常能找到方法让任何事情比预期的更容易规模化，部分原因是取悦客户到那时已经渗透到你的文化中了。
我从来没见过一个创业公司因为太努力让初期用户开心而偏离正道。
但也许阻止创始人意识到能对用户多么用心的最大因素是，他们自己从未体验过这样的用心。他们的客户服务标准来自于他们作为客户时接触的那些大公司。Tim Cook 不会在你买了笔记本电脑后给你寄手写便条——他做不到。但你可以。这是小公司的优势之一：你可以提供大公司无法提供的服务水平。[6]
一旦你意识到现有惯例不是用户体验的上限，思考你能在多大程度上取悦用户就变得非常有趣了。
体验
我在想一个短语来表达你对用户的关注应该有多极端，然后我意识到 Steve Jobs 早就说过了： insanely great 。Steve 不只是把 “insanely” 当作 “very” 的同义词用。他的意思更字面一些——一个人应该专注于执行质量，专注到在日常生活中会被认为是病态的程度。
我们投资的所有最成功的创业公司都有这个特质，这可能不会让准创始人感到惊讶。新手创始人不明白的是，insanely great 在初创期创业公司中意味着什么。当 Steve Jobs 开始使用这个短语时，Apple 已经是一家成熟的公司。他指的是 Mac（以及它的文档甚至包装——这就是痴迷的本质）应该被疯狂地精心设计和制造。这对工程师来说不难理解。这只是设计强壮优雅产品的更极端版本。
创始人难以理解的是（Steve 自己可能也难以理解），当你把时间滑块调回到创业公司生命的前几个月时，insanely great 会变成什么样。应该疯狂伟大的不是产品本身，而是成为你用户的体验。产品只是其中一个组成部分。对于大公司来说，产品必然是主导因素。但如果你能用专注弥补这个差距，就可以用一个早期、不完整、有 bug 的产品，为用户创造一个疯狂伟大的体验。
也许可以，但应该吗？是的。过度投入早期用户不只是获得增长的一种允许的技巧。对于大多数成功的创业公司来说，这是让产品变好的反馈循环的必要部分。做更好的捕鼠器不是 一步就能完成的事 。即使你按照大多数成功创业公司的方式开始，构建你自己需要的东西，你第一次构建的也永远不会完全正确。除非在犯错代价很高的领域，通常最好不要一开始就追求完美。在软件领域尤其如此，通常最好的做法是一旦有了最小的实用性就把东西放到用户面前，然后看他们怎么使用。完美主义往往是拖延的借口，而且无论如何，你对用户的初始模型总是不准确的，即使你就是用户之一。[7]
你从直接与最早期用户接触中得到的反馈将是你得到的最好的反馈。当你大到必须依靠焦点小组时，你会希望能像只有少数用户时那样，去他们家里和办公室看他们使用你的产品。
聚焦
有时正确的无法规模化的做法是专注于一个特意缩小的市场。就像先控制火势让它真正热起来，然后再添柴。
Facebook 就是这么做的。它最初只服务哈佛学生，潜在市场只有几千人。但正因为学生们觉得这个产品就是为他们量身定做的，关键的一批用户注册了。Facebook 不再只服务哈佛后，在相当长时间内仍然只为特定大学的学生服务。当我在 Startup School 采访 Mark Zuckerberg 时，他说虽然为每所学校创建课程列表很费力，但这让学生觉得这个网站就是他们的自然家园。
任何可以被描述为市场平台的初创公司通常都必须从市场的一个子集开始，但这对其他初创公司也有用。总是值得问的是，是否存在一个市场子集，你可以在其中快速获得关键用户群体。[8]
大多数使用控制火势策略的创业公司都是无意识地这样做的。他们为自己和朋友构建东西，而这些人恰好是早期采用者，直到后来才意识到他们可以把它提供给更广泛的市场。如果你无意识地这样做，策略同样有效。不有意识地察觉到这种模式的最大危险是那些天真地抛弃其中一部分的人。比如，如果你不是为自己和朋友构建东西，或者即使你是，但你来自企业界，你的朋友不是早期采用者，你就不再有现成的完美初始市场了。
在公司中，最好的早期采用者通常是其他初创公司。他们天生更开放接受新事物，而且因为刚刚起步，还没有做出所有选择。另外，当他们成功时会快速增长，你也会跟着增长。YC 模式的一个意外优势（特别是让 YC 变大）是 B2B 初创公司现在有一个即时市场，即数百个其他初创公司。
Meraki
对于硬件初创公司，有一种我们称为「Meraki 做法」的无法规模化做法的变体。虽然我们没有投资 Meraki，但创始人是 Robert Morris 的研究生，所以我们知道他们的历史。他们的起步方式真的无法规模化：自己组装路由器。
硬件初创公司面临软件初创公司没有的障碍。工厂生产的最小订单通常是几十万美元。这可能让你陷入困境：没有产品你就无法产生获得制造产品资金所需的增长。在硬件初创公司必须依赖投资者资金的时代，你必须很有说服力才能克服这个困难。众筹（或更准确地说，预订）的出现帮了很大忙。但即便如此，我还是建议初创公司如果可以的话，最初要采用 Meraki 做法。这就是 Pebble 做的。Pebble 团队自己组装了前几百块手表。如果他们没有经历那个阶段，当他们在 Kickstarter 上线时，可能不会卖出价值 1000 万美元的手表。
就像过度关注早期客户一样，自己制造东西对硬件初创公司来说是有价值的。当你就是工厂时，你可以更快地调整设计，而且你会学到原本永远不会知道的东西。Pebble 的 Eric Migicovsky 说他学到的一件事是「找到好螺丝有多么重要」。谁知道呢？
咨询
有时我们建议 B2B 创业公司的创始人把过度参与推向极端，挑选一个用户，就像为那一个用户构建咨询项目一样。让初始用户充当你的模具；不断调整直到完美适合他们的需求，你通常会发现做出了其他用户也想要的东西。即使没有很多这样的用户，可能也有更多相邻的领域。只要你能找到一个真正需要某样东西并且能对这种需求采取行动的用户，你就在制造人们想要的东西方面有了立足点——这是任何创业公司最初需要的全部。[9]
咨询是无法规模化工作的经典例子。但（像其他慷慨施恩的方式一样）只要你不收钱，这样做是安全的。这就是公司越界的地方。只要你是一个只是对客户格外用心的产品公司，他们会非常感激，即使你没有解决他们所有的问题。但当他们开始为这种用心付钱时——当他们开始按小时付费时——他们期待你做所有事情。
另一种招募最初不太热情用户的类似咨询的做法是代表他们使用你的软件。我们在 Viaweb 时就这样做过。当我们接触商家询问他们是否想用我们的软件制作在线商店时，有些人说不，但他们会让我们为他们做一个。为了获得用户，我们什么都愿意做，所以就做了。
当时我们觉得很丢脸。我们没有在组织大型战略电商合作伙伴关系，而是在试图销售行李箱、钢笔和男士衬衫。但回过头看，这正是对的做法，因为它让我们了解使用我们软件对商家来说是什么感觉。有时反馈循环几乎是即时的：在为某个商家建站时，我发现我们缺一个功能，就花几个小时实现它，然后继续建站。
手动
有一个更极端的做法：你不只是使用你的软件，而是就成为你的软件。当你只有少数用户时，有时可以手动做那些你打算以后自动化的事情。这让你启动得更快，而且当你最终把自己从循环中自动化出去时，你会确切知道要构建什么——因为你有亲自做这件事的肌肉记忆。
当手动组件在用户看来像软件时，这种技巧开始具有恶作剧的意味。比如，Stripe 给第一批用户提供「即时」商家账户的方式是创始人在幕后手动为他们注册传统商家账户。
有些创业公司一开始可能完全靠手动操作。如果你能找到有问题需要解决的人，并且你能手动解决，那就继续这样做，直到你做不下去为止，然后逐渐自动化瓶颈。用还不完全自动化的方式解决用户问题可能看起来有风险，但这比更常见的情况要好得多——有一些自动化的东西但还没解决任何人的问题。
大型发布
我应该提一种通常不太管用的初始策略：大型发布。我偶尔会遇到一些创始人，他们似乎认为初创公司是炮弹而不是飞机，只有以足够的初始速度发射才能成功。他们想同时在 8 个不同媒体上发布，还要有媒体禁发期（embargo）。当然要选在周二，因为他们在某篇文章里读到这是发布产品的最佳日子。
很容易看出发布有多不重要。想想一些成功的初创公司，你记得他们的发布吗？你从发布中需要的只是一些初始用户。几个月后，你的成功更多取决于你让这些用户多么满意，而不是你初期获得了多少关注。[10]
那为什么创始人认为发布很重要？自恋和懒惰的结合。他们认为自己正在做的产品太棒了，每个知道的人都会立即注册。另外，如果你可以仅仅通过广播你的存在来获得用户，而不是一个一个地招募他们，那工作量会少得多。但即使你正在构建的真的很棒，获得用户总是一个渐进的过程——部分因为伟大的东西通常也是新颖的，但主要是因为用户还有其他事情要考虑。
通常来说，合作伙伴关系对初创阶段也不怎么奏效，尤其不适合作为点燃增长的手段。缺乏经验的创始人常犯的错误是相信与大公司的合作伙伴关系将是他们的重大突破。六个月后，他们都在说同样的话：工作量比我们预期的大得多，我们最终几乎什么都没得到。[11]
仅仅在最初做一些非凡的事情是不够的。你必须在最初做出非凡的努力。任何省略努力的策略——无论是期待大型发布为你获得用户，还是大合作伙伴——本身就是可疑的。
向量
需要做一些无法规模化的费力事情来开始如此普遍，以至于或许我们应该停止把初创公司想法当作标量。相反，可以尝试把它们当作一对向量：你要构建什么，加上你最初要做的无法规模化的事情来让公司运转起来。
开始这样看待创业公司想法可能很有趣，因为现在有两个组成部分，你可以尝试在第二个组成部分上也发挥想象力。但大多数情况下，第二个分量都是常见的——人工获客并给他们压倒性的好体验——而把初创公司当作向量的主要好处是提醒创始人需要在两个维度上努力工作。[12]
最理想的情况下，这两个组成部分都会成为你公司 DNA 的一部分：你在初创阶段必须做的那些无法规模化的事情，不仅仅是不得已而为之，而是能够永久性地让公司变得更好。如果你在小的时候必须在用户获取上很激进，当你变大时可能仍然会很激进。如果你必须制造自己的硬件，或者代表用户使用你的软件，你会学到原本学不到的东西。最重要的是，如果你只有少数用户时必须努力取悦他们，当你有很多用户时你会继续这样做。
注释
[1] 实际上 Emerson 从未具体提到过捕鼠器。他写的是「如果一个人有好的玉米或木材，或木板，或猪要卖，或者能做出比别人更好的椅子或刀子，坩埚或教堂风琴，你会发现通向他家的路是宽阔而坚实的，即使它在树林里。」 ↩
[2] 感谢 Sam Altman 建议我明确这一点。不，你不能通过雇佣别人来做销售来避免自己做销售。你必须最初自己做销售。后来你可以雇一个真正的销售员来替代你。 ↩
[3] 这样做有效的原因是随着你变大，你的规模帮助你成长。Patrick Collison 写道「在某个时刻，Stripe 的感觉发生了非常明显的变化。它从我们必须推动的巨石变成了实际上有自己动力的火车车厢。」 ↩
[4] YC 能帮助创始人的一个更微妙的方式是校准他们的雄心，因为我们确切知道很多成功的创业公司在刚起步时是什么样子的。 ↩
[5] 如果你正在构建一个你无法轻易获得一小群用户来观察的东西——比如企业软件——而且在一个你没有关系的领域，你将不得不依靠冷拨与引荐。但你甚至应该在这样的想法上工作吗？ ↩
[6] Garry Tan 指出了创始人在开始时会陷入的一个有趣陷阱。他们太想显得大，以至于甚至模仿大公司的缺陷，比如对个别用户的冷漠。这在他们看来更「专业」。实际上，拥抱你小的事实并利用这带来的任何优势是更好的。 ↩
[7] 你的用户模型几乎不可能完全准确，因为用户的需求经常因你为他们构建的东西而改变。给他们一台个人电脑，突然他们需要在上面运行电子表格，因为你的新电脑的到来导致有人发明了电子表格。 ↩
[8] 如果你必须在最快注册的子集和付费最多的子集之间选择，通常最好选择前者，因为这些可能是早期采用者。他们会对你的产品有更好的影响，而且他们不会让你在销售上花费那么多精力。虽然他们钱更少，但在早期你不需要那么多来维持目标增长率。 ↩
[9] 是的，我可以想象你最终可能做出只对一个用户真正有用的东西的情况。但这些通常是显而易见的，即使对缺乏经验的创始人也是如此。所以如果你做的东西显然不是为一个人的市场做的，不要担心这种危险。 ↩
[10] 甚至可能存在发布规模和成功之间的反相关关系。我记得的唯一发布都是著名的失败，比如 Segway 和 Google Wave。Google Wave（团队协作产品，已停运）是一个特别令人警醒的例子，因为我认为它实际上是一个很棒的想法，部分被过度造势杀死了。 ↩
[11] Google 在 Yahoo 的支持下变大，但那不是合作伙伴关系。Yahoo 是他们的客户。 ↩
[12] 它也会提醒创始人，第二个组成部分为空的想法——没有什么你可以做来开始的想法，比如因为你没有办法找到用户来手动招募——可能是个坏想法，至少对那些创始人来说是这样。 ↩
感谢 Sam Altman、Paul Buchheit、Patrick Collison、Kevin Hale、Steven Levy、Jessica Livingston、Geoff Ralston 和 Garry Tan 阅读本文草稿。