我从用户身上学到的东西

2022年9月

我最近告诉 Y Combinator 的申请者，能给出的最佳建议是

解释你从用户身上学到了什么。

这测试了很多东西：你是否在关注用户，你对他们的理解有多深，甚至他们对你所做的事情有多需要。

之后我问自己同样的问题。我从 YC 的用户，即我们资助的初创公司中学到了什么？

我想到的第一件事是，大多数初创公司都有相同的问题。没有两个初创公司有完全相同的问题，但令人惊讶的是，无论他们在做什么，问题的本质是多么相似。一旦你给 100 家做不同事情的初创公司提供建议，你很少会遇到你没有见过的问题。

这个事实是 YC 成功的原因之一。但在我们开始 YC 时我并不知道这一点。我只有几个数据点：我们自己的初创公司，以及朋友们创办的那些。让我惊讶的是，相同的问题以不同的形式反复出现的频率。许多后期投资者可能永远不会意识到这一点，因为后期投资者在整个职业生涯中可能不会给 100 家初创公司提供建议，但 YC 的合伙人在头一两年就能获得如此多的经验。

这就是资助大量早期阶段公司的一个优势，而不是较少数量的后期公司。你获得了大量的数据。不仅仅是因为你在看更多的公司，还因为更多的事情出错。

但知道（几乎）所有初创公司可能遇到的问题并不意味着对他们的建议可以自动化或简化为公式。与 YC 合伙人进行个别的办公时间是无可替代的。每个初创公司都是独特的，这意味着他们必须由了解他们的特定合伙人提供建议。 [1]

我们在 2012 年夏季的“打破 YC 的批次”中以艰难的方式学到了这一点。在那之前，我们将合伙人视为一个池子。当一家初创公司请求办公时间时，他们会得到任何合伙人发布的下一个可用时段。这意味着每个合伙人都必须了解每个初创公司。这在 60 家初创公司时运作良好，但当批次增加到 80 家时，一切都崩溃了。创始人可能没有意识到有什么问题，但合伙人感到困惑和不满，因为在批次进行到一半时，他们仍然不知道所有公司。

起初我很困惑。为什么在 60 家初创公司时一切都很好，而在 80 家时却崩溃了？这只是多了三分之一。然后我意识到发生了什么。我们使用的是 O(n²) 算法。所以当然它崩溃了。

我们采用的解决方案是这些情况下的经典方案。我们将批次分成更小的初创公司组，每组由一组专门的合伙人监督。这解决了问题，并且从那时起一直运作良好。但打破 YC 的批次强有力地展示了对初创公司提供建议的过程必须是多么个性化。

另一个相关的惊喜是创始人在意识到他们的问题方面有多糟糕。创始人有时会来谈论某个问题，而在谈话过程中我们会发现另一个更大的问题。例如（这个案例太常见了），创始人会来谈论他们在筹集资金方面遇到的困难，而在深入挖掘他们的情况后，结果是公司表现不佳，投资者能看出来。或者创始人会担心他们仍然没有解决用户获取的问题，而原因恰恰是他们的产品不够好。有时我会问“如果你没有自己建立这个，你会使用它吗？”而创始人在思考后会说“不。”好吧，这就是你们在获取用户方面遇到麻烦的原因。

创始人通常知道他们的问题是什么，但不知道它们的相对重要性。 [3] 他们会来谈论三个让他们担忧的问题。一个是中等重要性，一个根本不重要，而一个如果不立即解决就会毁掉公司。这就像看一部恐怖电影，女主角对她的男朋友背叛感到非常沮丧，而对那扇神秘敞开的门只是略微好奇。你想说：别管你的男朋友，想想那扇门！幸运的是，在办公时间你可以这样做。因此，尽管初创公司仍然会定期倒闭，但很少是因为他们走进了一个有谋杀者的房间。YC 的合伙人可以警告他们谋杀者在哪里。

并不是说创始人会听。另一个大惊喜是创始人多么频繁地不听我们的建议。几周前，我和一位在 YC 工作了几个批次的合伙人交谈，她开始看到这个模式。“他们一年后回来，”她说，“说‘我们希望我们听了你的话。’”

我花了很长时间才弄明白为什么创始人不听。起初我认为这只是固执。这是部分原因，但另一个可能更重要的原因是，关于初创公司的很多事情都是反直觉的。当你告诉某人一些反直觉的事情时，他们听起来是错误的。因此，创始人不听我们的原因是他们不相信我们。至少在经验教会他们之前，他们不会相信。 [4]

初创公司之所以如此反直觉，是因为它们与大多数人的其他经历截然不同。除了那些经历过的人，没有人知道这是什么感觉。这就是为什么 YC 的合伙人通常应该是创始人。但奇怪的是，初创公司的反直觉性恰恰是使 YC 成功的另一个原因。如果它不是反直觉的，创始人就不需要我们的建议来指导他们如何去做。

专注对早期阶段的初创公司来说尤为重要，因为他们不仅面临一百个不同的问题，而且除了创始人之外没有人来处理这些问题。如果创始人专注于不重要的事情，就没有人专注于重要的事情。因此，YC 的本质就是找出哪些问题最重要，然后想出解决这些问题的想法——理想情况下在一周或更短的时间内——然后尝试这些想法并衡量它们的效果。重点是行动，取得可衡量的、短期的结果。

这并不意味着创始人应该不顾后果地急于向前。如果你以足够高的频率修正方向，你可以在微观层面上果断，而在宏观层面上则保持谨慎。结果是一个稍微曲折的路径，但执行得非常迅速，就像跑卫在场上奔跑的路径一样。实际上，回头的次数比你想象的要少。创始人通常能正确猜测出该往哪个方向跑，尤其是当他们有像 YC 合伙人这样的经验丰富的人来验证他们的假设时。当他们猜错时，他们会迅速注意到，因为他们会在下周的办公时间讨论结果。 [5]

导航能力的小幅提升可以让你变得更快，因为它有双重效果：路径更短，当你更确定这是正确的路径时，你可以沿着它更快地移动。这就是 YC 的价值所在，帮助创始人获得额外的专注，使他们能够更快地行动。而且，由于快速行动是初创公司的本质，YC 实际上使初创公司更像初创公司。

速度定义了初创公司。专注使速度成为可能。YC 改善了专注。

为什么创始人对该做什么感到不确定？部分原因是初创公司几乎按定义是在做一些新的事情，这意味着没有人知道该怎么做，或者在大多数情况下甚至不知道“它”是什么。部分原因是初创公司通常是如此反直觉。还有部分原因是许多创始人，尤其是年轻和雄心勃勃的创始人，已经被训练成以错误的方式获胜。这花了我很多年才弄明白。大多数国家的教育系统训练你通过破解考试来获胜，而不是实际做任何它应该衡量的事情。但当你开始创业时，这种方法就不再有效。因此，YC 的部分工作就是重新训练创始人停止尝试破解考试。（这需要出乎意料的长时间。一年后，你仍然会看到他们回归旧习惯。）

YC 不仅仅是更有经验的创始人传授他们的知识。它更像是专业化而非学徒制。YC 合伙人和创始人的知识形态不同：创始人获得 YC 合伙人那种百科全书式的初创公司问题知识并不值得，而 YC 合伙人获得创始人那种深度领域知识也不值得。这就是为什么经验丰富的创始人做 YC 仍然是有价值的，就像经验丰富的运动员有教练仍然是有价值的一样。

YC 给予创始人的另一个重要东西是同事，这可能比合伙人的建议更重要。如果你看看历史，伟大的工作聚集在某些地方和机构：15 世纪末的佛罗伦萨，19 世纪末的哥廷根大学，罗斯时代的《纽约客》，贝尔实验室，施乐帕克。无论你多么优秀，优秀的同事都会让你变得更好。实际上，非常有雄心的人可能比其他任何人更需要同事，因为他们在日常生活中对同事的渴望如此强烈。

无论 YC 是否能有一天与那些著名的聚集地并列，它都不会因为缺乏努力而失败。我们非常清楚这一历史现象，并故意将 YC 设计成一个聚集地。到目前为止，毫不夸张地说，它是最大的优秀初创公司创始人聚集地。即使是试图攻击 YC 的人也承认这一点。

同事和初创公司创始人是世界上最强大的两种力量，因此你会期望将它们结合在一起会产生重大影响。在 YC 之前，在人们考虑这个问题的程度上，大多数人认为它们无法结合——孤独是独立的代价。这就是我们在 1990 年代在波士顿创办自己的初创公司时的感觉。我们有一小部分年长的人可以向他们寻求建议（质量各异），但没有同龄人。没有人可以与我们一起对投资者的不当行为表示同情，或对技术的未来进行推测。我常常告诉创始人要做一些他们自己想要的东西，而 YC 当然就是这样：它被设计成正是我们在创办初创公司时所想要的。

我们想要的一件事是能够获得种子资金，而不必去找随机的富人。现在这在美国已经成为一种商品。但优秀的同事永远无法成为商品，因为他们在某些地方聚集的事实意味着他们在其他地方相对缺乏。

然而，当他们聚集在一起时，会发生一些神奇的事情。在 YC 晚宴上的能量是我所经历过的其他任何事情都无法比拟的。我们本来只希望能有一两家其他初创公司可以交谈。当你有一整个房间的人时，那完全是另一回事。

YC 的创始人不仅相互激励。他们还相互帮助。这是我从初创公司创始人身上学到的最快乐的事情：他们在帮助彼此方面是多么慷慨。我们在第一批中注意到了这一点，并有意识地设计 YC 来放大这一点。结果是比大学更为强烈的东西。在合伙人、校友和他们的批次伙伴之间，创始人被希望帮助他们并且能够帮助他们的人包围着。

备注

[1] 这就是为什么我从来不喜欢人们称 YC 为“训练营”。它像训练营一样紧张，但在结构上正好相反。每个人都不是在做同样的事情，而是在与 YC 合伙人交谈，以找出他们特定的初创公司需要什么。

[2] 当我说 2012 年夏季批次被打破时，我的意思是合伙人感觉到有什么不对劲。事情还没有糟糕到初创公司有更糟糕的体验。事实上，那一批表现得异常好。

[3] 这种情况让我想起了研究表明人们在回答问题时要比判断自己答案的准确性要好得多。这两种现象感觉非常相似。

[4] Airbnb 特别擅长倾听——部分原因是他们灵活且有纪律，但也因为他们在前一年经历了如此艰难的时光。他们准备好倾听。

[5] 最佳的果断单位取决于获得结果所需的时间，而这取决于你正在解决的问题类型。当你与投资者谈判时，可能需要几天，而如果你在构建硬件，可能需要几个月。

感谢 Trevor Blackwell、Jessica Livingston、Harj Taggar 和 Garry Tan 阅读这篇草稿。