Inside Linear：以品味、匠心与专注打造产品 | Karri Saarinen（联合创始人、设计师、CEO）

Karri Saarinen 2023-10-08

Inside Linear：以品味、匠心与专注打造产品 | Karri Saarinen（联合创始人、设计师、CEO）

Inside Linear：以品味、匠心与专注打造产品 | Karri Saarinen（联合创始人、设计师、CEO）

文字记录

设计的重要性

Karri Saarinen： 我的看法是，就像任何领域或行业一样，一件事越重要，设计就越重要。每当出现一个新范式——比如说移动端、Web 或其他什么——第一批出现在那里的产品并不需要做得特别好，因为它们是最早的。然后，当你做出了十万个不同的邮件客户端，现在任何一个邮件客户端都必须相当出色，才能被当作一个邮件客户端来看待。门槛已经非常高了。我觉得今天这几乎已经是一个非常基本的事实——几乎从一开始，你就需要相当高水平的设计，用户才会注意到你、认真考虑你。

嘉宾介绍

Lenny： 今天的嘉宾是 Karri Saarinen。Karri 曾是 Coinbase 的创始设计师、Airbnb 的首席设计师，此前还联合创办过两家创业公司，最近则是 Linear 的联合创始人兼 CEO。我相当有信心地说，Linear 是全球增长最快、最受喜爱的 issue tracking（问题追踪）工具，越来越多产品团队正在使用它来构建自己的产品。

Karri 和他的团队以一种非常独特的方式打造公司和产品——极度强调匠心和品质，不做 AB 测试，不设基于指标的目标，而是专注于品味和主见。他们也没有固定的跨职能团队，而是围绕项目组建团队，完成后即解散。此外，他们只有一位产品经理——担任产品负责人——仅此一人。在这次对话中，Karri 分享了他如何围绕品质和匠心建立文化、如何做权衡取舍，以及如何将品质和深思熟虑落实为可操作的实践，让设计成为与现有巨头竞争时的差异化优势。

我们聊到了一种叫做「Linear Method」的产品构建方式，其核心理念包括打造有主见的软件（opinionated software）、以一致的周期（cycle）推进工作等。我们还深入了解了 Linear 独特的招聘方式——候选人会进行一段有薪试工，与团队一起工作数天，而非仅仅参加面试。此外，Karri 也分享了 Linear 如何获得最初的十个客户、如何找到产品市场匹配（product-market fit），以及如何扩展增长引擎。

这期内容干货满满，我非常期待你听到它。那么，有请 Karri Saarinen。

什么是 Linear

Lenny： Karri，非常感谢你来到这里。欢迎来到播客。

Karri Saarinen： 谢谢，Lenny。很高兴来这里。

Lenny： 也许我们可以先设定一下背景，你能简单介绍一下 Linear 是什么、做什么吗？另外也可以分享几个数据，让大家了解 Linear 目前的规模。

Karri Saarinen： Linear 是一个项目与 issue tracking（问题追踪）系统，软件公司和技术团队都爱用它。我们帮助软件公司构建软件。我们成立于 2019 年，如今一些顶级的增长型公司——比如 Block、Vercel、Ramp、Retool、Mercury 和 Softstack——都在使用 Linear 构建产品。除此之外，我们还有许多其他公司，数以千计的公司在使用 Linear。这些公司可以是非常早期的团队，比如刚从 YC 毕业的创业公司，也可以是上市公司。

简单说一下我们为什么创建 Linear——正如你提到的，我曾在 Airbnb 跟你共事过，在那之前我在 Coinbase 工作，更早之前我有自己的创业公司。我们三位联合创始人都有类似的经历，都在不同阶段的多家公司工作过。我们经常看到，用于管理软件项目的工具并不能真正满足需求。我觉得很多工具感觉笨重、复杂，或者仍然沿用一种陈旧的软件开发思维方式。我们就觉得应该对此做点什么。Linear 的目标就是为现代软件开发打造一个最无摩擦、最高效的系统。另外也很高兴分享一个消息：过去两年我们一直是盈利的。我们还有一个很有意思的数据——我们实际上拥有负的终身烧钱率（net negative lifetime burn rate），这意味着我们银行里的现金比我们融资总额还多。很多创业公司通常的路径是融资、然后花钱建设。但因为我们很早就建立起了商业模式，所以我们处在一个实际上没有花任何投资款来建设业务的位置上。

关于匠心与品质

Lenny： 这太疯狂了，我甚至都不知道这个。正因如此，很多创始人和产品负责人都非常推崇 Linear 打造产品的方式和你们对产品的思考。为了框架化这次对话，我想深入探讨三个领域：一是你们如何构建产品，二是你们如何组建团队和运营业务，三是你们如何增长 Linear。首先，我想聊聊匠心。

很显然，人们推崇 Linear、使用 Linear 的最大原因之一，就是用户体验和产品的品质。我知道你的团队非常重视匠心和用户体验。我猜想这也伴随着一些取舍——比如可能需要更长时间才能交付东西，可能因为用户在等待某个功能而你们还没准备好发布，因此流失了一些销售。你想把它做得更好。关于为匠心创造空间、打造真正优秀的产品，你学到了什么？

匠心始于人

Karri： 我觉得很有意思的是，你提到的这些事情——招聘、组建业务、打造产品和匠心——它们彼此之间其实是相互关联的。单就产品匠心而言，我可以明确地说，它一定始于人。在招聘方面，我们一直在寻找真正在意这件事的人。从商业角度看，我们之所以如此重视匠心，是因为我们认为协作只有在人们使用产品的过程中才会发生，而我们的产品正是用来帮助协作、协调的。

如果产品有摩擦，体验不够好，或者有各种小毛小病，用起来就会让人非常烦。我们认为，要让业务成功，品质和匠心是非常重要的。当然，有时候确实需要做取舍。比如时间线上的取舍——我们本来准备发布某个东西，然后我或者其他人去看了一下，发现”嗯，这个感觉不对，我们应该修一下，所以我觉得现在不应该发布。”

有时候这确实会推迟时间线，但可能也就是几天的工夫，并不是说我们需要把所有东西推翻重来。我们的另一种做法是，我们非常乐意尽早把东西推送给我们自己，以及一小群选择加入的客户。每当我们构建一个新功能时，我们的原则之一就是，我们不想在一开始花大量时间去设计，然后把它打磨得完美无缺。

早期发布与快速迭代

我们其实相信，当你开始构建一个东西的时候，你才会真正意识到它应该怎么运作、怎么才能更好。很多时候我们跟团队说，“把它放进去就行，差不多第一周就放进去。你有了一些设计方案或者设计想法之后，就直接把它放进应用里，发布到生产环境。“这些内容只对我们自己可见，所以我们可以内部测试。

然后下一阶段，我们会寻找可能对这个功能感兴趣的客户，或者直接邀请人们加入某个体验计划。在这些阶段，体验可能会有点粗糙，打磨得不够好，但我们觉得没问题，因为我们明确告诉他们，“这个还没做完，我们只是想尽早获取你的反馈，这样才能把它做得更好。“等到正式面向所有人发布的时候，我们才会花更多精力去打磨和精雕细琢。

Lenny： 这太有意思了，我都不知道你们是这样做的。你们居然真的会那么早就把东西发布给一小群想要尝鲜的人。然后你刚才是说，你们会找一个客户来共同创造，一起推动功能演进、调整改进？

Karri： 通常是一个，也可能是三个、五个或者十个。尤其是面向大公司的功能，我们通常会去找一家大公司合作，因为这些场景有时候很难凭想象去理解它应该怎么运作。如果有人愿意跟我们合作，告诉我们”我们是这样做的”，那就好多了。比如我们和 Vercel 就是这样合作的——他们对路线图功能有一些想看到的改动，我们跟他们一起改进，他们可以在过程中不断给我们反馈。

Lenny： 这太有意思了。因为我觉得从外部看 Linear，感觉你们就是花所需的时间去打造很棒的东西，然后一发布就很惊艳、很出色。但事实证明，你们的构建方式并不完全是这样的。你们确实会很早地发布东西，只是在完成之前人们不一定会看到它，但背后其实有一整套流程。

匠心不等于完美主义

Karri： 我觉得有时候人们认为匠心就是把东西做到完美，以一种非常有序的方式、或者在非常早期就去完善它。这种完美主义思维的问题在于，有时候你会很难把任何东西推出来，因为没有什么是真正完美的。我们试图平衡这种思维——一方面我们应该总是非常快地把东西推出去，另一方面也要非常快地修复和改进。

这几乎是相反的思路，但我们试图将两者结合起来，我觉得效果一直不错。总体而言，公司里并没有很多审查流程，并不是所有要发布的东西都要经过层层审查，因为我们确实希望人们觉得自己可以把东西放进应用里，然后我们可以试用。更像是”先试试看”，但在面向所有人发布之前，我们确实需要再审视一遍。

给创始人的建议

Lenny： 很多创始人、很多产品负责人、很多设计师都希望为匠心创造空间，把产品做到真正优秀，做出自己引以为傲的东西。但在实践中，这非常难做到。真正能做到的团队和公司少之又少。关于如何为这种匠心创造空间、如何将它优先排序，你还有什么其他心得可以分享给正在听的创始人们吗？他们也在试图在团队中植入更多这种文化。还是说，你必须是像 Karri 这样设计师出身的 CEO，否则就很难做到？

Karri： 我不这么认为。这并不完全是从我这里来的。我觉得我们三个创始人——Jori 和 Tuomas 也是——他们的背景是工程，但我得说，有时候他们甚至比我花更多时间在细节上。我觉得在很早期的时候，就是我们三个人，我会做那些大框架的设计，比如 UI 是怎么运作的，某些功能是怎么工作的。而他们是那种会说”这里应该加个动画，这里应该有这个东西”的人。

我觉得这种 DNA 来自我们所有人。匠心这件事，始终始于人——人们需要真正在意它。如果在公司里这不被重视，那任何人都很难做到，因为人们会觉得这不被看重。我给过一位创始人建议，他来问我这个问题。在他们的案例中，几位创始人来自不同的公司，比如一位来自 Airbnb，其他人来自 Facebook 和 Amazon。比如 Facebook 和 Amazon 在品质、匠心或者发布节奏上的文化就非常不同。我当时跟他们说的是，你们需要对齐。你不可能以多种不同的文化来运营一家公司。我举了一些例子，说明为什么品质对某些产品很重要，你们都应该认同这一点，然后在招聘的每一个人时都把这个理念植入进去。另外我想说的是，我们公司其实没有太多 PM。

减少PM，赋予团队所有权

我们只有一个 PM，我们可以之后再聊这个。我觉得问题在于，当你组建团队并开始为每件事设置非常具体的角色时，PM 往往是那个负责理清事情、做决策、引导团队的人，但他们并不是在构建功能的人。他们不会整天盯着看这个按钮应该放哪里、这个功能应该怎么运作。对我们来说，匠心很大程度体现在我们给项目团队所有权——而项目团队只有工程师和设计师。

当他们开始构建功能的时候，他们就开始发现各种改进的机会。一个很好的例子是我们的工程师 Andreas。我们在做应用里的右键菜单时——你可以点击不同的选项，下面还有子菜单。Mac OS 在这方面做得很好：当你打开菜单后，把鼠标悬停在某个选项上，然后想进入子菜单，你只需要往右移，不需要精确地水平移动才能进入那个子菜单。

你可以斜着移动鼠标，不需要精确地到菜单项上。会有一个安全区域。但很多软件的实现方式就是，“行，做个菜单，再做个子菜单”，只有当你精确地悬停在菜单上时才有效。结果用户经常会差那么几个像素，错过了他们想选的目标。Andreas 做了一件我们完全没要求他做的事——他觉得”这样体验很差，我们应该改进一下。”

他找到了一种方法，能根据子菜单位置动态创建那些安全区域。现在操作起来轻松多了，你可以斜着移到你想去的目标。我觉得这些事情之所以会发生，是因为你给了人们更多项目所有权，也给了他们这样做的空间，同时公司的领导层和整体文化都重视质量和匠心。

招募唯一的 PM

Lenny： 我想顺着这个话题继续追问，有几个问题想问。你们有一位产品经理，你会称他为产品负责人吗？

Karri Saarinen： 对，Nan Yu，他是我们的产品负责人。

Lenny： 很好，是什么让你决定招聘他，甚至要设立 PM 这个角色的？

Karri Saarinen： 我们开始发现，产品功能和领域足够多了，团队规模也在扩大，很难让所有人对齐所有事情，甚至连追踪都变得困难。最初我们其实是把 Nan 作为承包商招来，帮我们做这个洞察数据工具。Linear 里内置了这个数据工具功能，你可以获取工作空间中正在发生什么的数据。对我们创始人来说，我们意识到团队里没有人在数据工具方面特别有经验，需要有人来帮忙。

幸好我们认识 Nan，他之前在 Mode 工作，那是一个数据工具。我们最初请他来是希望他帮我们搞清楚这个数据工具到底应该是什么、应该怎么运作。实现这种功能有很多种方式。最简单的路径永远是直接照搬其他公司的做法，但我们不想那样做。我们想搞清楚，什么才是真正有用的数据使用方式或数据获取方式。

他帮我们理清了这个问题，然后我们发现这种能力在其他更大的领域、甚至整个产品层面也可能有用——我们可能会面临类似的疑问：这里到底应该怎么思考？为什么？如何定义这个方向？然后帮助团队对齐。对我们来说，他的角色更像是确定产品方向、引导一些工作重心，而不是出现在每个会议里、做每个决策、写每份规格文档。

PM 的工作由谁来承担

Lenny： 沿着这条线再问一个问题，因为有很多 PM 听众会想说，“糟了，这些人不需要 PM，PM 要完了，产品管理已死。” 就是说，总得有人去做 PM 做的那些工作，对吧？产品经理在公司里有一堆事情要做，如果他们不在，其他人就得做这些事。我听到的是，你们基本上把这些职责交给了工程师、设计师，可能还有团队里其他职能的人。是这样吗？

Karri Saarinen： 对，我想这确实意味着——而且这里面确实有权衡。我觉得有时候公司大量细分角色，是因为这样更高效。如果工程师把 100% 的时间都花在写代码上，那就是把他们的技能发挥到极致。但我们认为，要打造高质量的东西、用特定方式构建产品，实际上更好的做法是让人们也花一些时间去思考，而不只是执行。

每个项目都有一个项目负责人。这个负责人可以是工程师也可以是设计师。这不是一个正式的角色，也不取决于你的级别或头衔——不是说你要达到某个职级才能担任。它更像是一个任务分配：现在你负责启动这个项目，和团队一起协作，把事情理清，然后沟通进展、同步变化。

这确实意味着工程师和设计师也要做这些事情，他们需要沟通，需要思考范围和各种问题。这是一种不同的做事方式。而且也不是每个人都想这样做，这完全没问题，但我们在招聘时会尽量找那些对更广泛领域感兴趣的人，而不只是专注于自己特定技能的人。

Lenny： 我觉得最后两点非常关键。第一，人们通常不想做这些工作，他们很乐意把它交给产品经理。事实上，工程师要做所有这些枯燥的 PM 工作——沟通时间线、保持 PR 和规格文档对齐、确保按期交付、主持会议——很多人不想做这些。但很多时候他们其实是愿意的，我觉得在你们的情况下，人们看起来确实想做这些事。第二，我认为你需要一支水平很高的团队，他们要有很强的产品意识，对工程师和设计师的招聘标准需要非常高，这样才能让他们愿意并且擅长做这些事。我觉得这是这种模式能成功的两个必要条件。

Karri Saarinen： 当然。

如何在没有 PM 的情况下运转团队

Lenny： 对于想尝试这种方式的团队，特别是刚起步、可能不太想招产品经理的创业公司，你觉得还有什么是对没有 PM 也能良好运转来说必不可少的？你们现在大概 50 人左右？

Karri Saarinen： 我们大约 50 人。我唯一想说的可能就是在招聘方面，你真的需要花更多时间。基本上，你不能只考察工程师的工程技能来面试他们，还得考察他们的产品技能。当然，你不能指望他们在这方面有多少积累——如果你用 PM 面试的方式去考他们，他们不会有相同的知识储备或概念理解。

我们过去的做法是，比如我会面试他们的产品意识。我本人严格来说不是技术人员。我只会问他们一些问题：你过去是怎么做某件事的？你怎么思考某个问题？这跟其他角色也类似。我们就看这个人有没有对产品的观点、对产品运作方式有没有自己的想法？他们能不能形成自己的判断？然后能不能把这些东西清晰地表达出来？

Lenny： 很好。我刚才在想一个很有意思的地方：一个不是专为产品经理设计的工具——本质上它是团队构建产品的基础设施——却是由一家只有一个 PM、PM 极少的公司构建的。

Karri Saarinen： 我想在某些方面，我会说 Linear 是想服务整个公司的，工程师可能是产品最大的用户群体。在某种程度上，我们想让 PM 的工作更轻松，因为他们不需要花那么多时间管理一切或处理日常事务——因为工程师确实在使用产品、在更新各种状态。对 PM 来说，了解事情进展会容易得多，也许也能更信任这些信息，因为大家确实在用这个产品。

设计作为差异化优势

Karri Saarinen： 在某种程度上，我想我们是在努力让所有人的工作都更轻松，让工程师也更轻松。他们可以更专注于自己的工作。对于 PM，我想我们在努力让他们也能更专注于其他事情，而不是仅仅——我不知道——管理他们使用的工具。我觉得那不是 PM 最重要的工作。他们应该更多地思考——怎么说呢——更大的图景，或者其他问题，或者去想清楚下一个功能是什么之类的。

Lenny： 沿着这个方向再问一个问题。我知道有些公司，比如 Stripe，我记得是等到两百人才招了他们的第一个产品经理。Snapchat 也以类似的做法闻名。你对这种趋势是否会改变有什么判断吗？你觉得什么时候可能会招更多产品经理？有没有一个计划，还是说就是随公司增长再看？

Karri Saarinen： 我觉得我们肯定会招更多。这就像我之前说的。我们希望看到 PM 的聪明才智在更高的层面上发挥作用。整个公司，我觉得我们的建设方式是人更少，但每个人水平更高，能够思考比当前角色更大的范围。我觉得我们就是在尝试构建更小但更高效的单元，PM 也是这个思路。他们的数量也会更少，不会在每个层级都有。我觉得未来随着公司增长、团队增长、产品增长，我们可能会有几个 PM，各自专注于或关注产品的特定领域、特定类型的事物、或者特定客户之类的。

Lenny： 太好了，这个有点跑题了，因为我忍不住往那个方向聊了。但我想回到设计和工艺的话题上。感觉 Linear 成功的原因之一就是设计和体验基本上是与其他产品的巨大差异化因素。一直存在一个问题：在特定市场中，设计能否成为足够的差异化因素？是否总有机会打造一个明显更好的产品体验，并真正有机会颠覆现有者？你对设计什么时候能成为足够的差异化因素有判断吗？这个问题也来自一个创始人的视角——我们应该在设计上大举投入，还是应该投资于分发渠道、新技术之类的东西？你有什么想法？

Karri Saarinen： 我的信念是，在任何领域或行业中，事情越重要，设计就越重要。我觉得这在不同的领域很容易看出来，不管是软件还是其他行业。情况就是，每当出现一个新的范式——比如移动端、Web 或者其他什么——那些产品在那个范式下的第一版迭代，不一定要设计得特别好，因为它们是先行者。但当你做出了成百上千个不同的邮件客户端之后，现在任何一个邮件客户端都必须相当不错才能被考虑。门槛已经很高了。我觉得今天的创业公司——如果你看看 Google 最初上线的网页，或者 YouTube 最初上线的网页，或者一些更老的公司——它们都非常简陋。如果你今天上线那样的网站，不会有人真正注意到你。所以我觉得设计现在几乎成了一件非常基本的事情，几乎从一开始你就需要相当高水平的设计，别人才会注意到你，才会认真考虑你。

而且我觉得这并不一定公平，因为有时候产品可能真的很好，但他们没有设计师，或者没有时间去做设计，然后人们就直接无视了，因为它看起来不像能引起兴趣的东西。所以我觉得第一点是，设计确实很重要，而且会越来越重要。但我也想说，设计永远不会是公司成功的原因。公司仍然需要有其他的东西。产品仍然需要是某种有价值的东西，它需要在某些方面更好，或者在某些方面与众不同。设计只是让这些事情成为可能。这跟技术类似——如果你有好的技术，做某些事情就更容易，产品在某些方面也会运作得更好，而不像你拥有糟糕的技术或基础设施那样。

设计也是类似的道理。如果你有好的设计，甚至好的品牌，人们就会被吸引过来，这会让用户获取、用户留存，甚至人们对产品的认知都更好。我觉得包装就是一个例子——Apple 或者很多公司花大量时间和精力在包装上，因为它已经在为收到产品的用户设定期望。就像在你使用产品之前，你就开始觉得这是一个高质量的产品，我会喜欢它。然后当你真正上手使用时，你可能真的会有那种感觉——除非产品真的很差，那就不会了。

所以我觉得类似地，对于创业公司或 SaaS 来说，你的着陆页或者其他一些东西——它们已经在向用户传达某些信息，在设定期望。我觉得这可以是非常有用的东西，尤其是在早期，当没有人真正了解你、了解产品，或者在意你的时候。所以我觉得设计在早期尤其能成为很好的杠杆。

Lenny： 我觉得这个洞见非常有意思，尤其是你说的第一点——一个空间被进入的次数越多、越拥挤，设计成为差异化因素的机会就越大。大致是这么理解的吗？

Karri Saarinen： 对。你想想，随便哪个产品品类，人们有很多选择，然后他们怎么做出选择？也许他们有特定的需求，但很多人并不一定知道自己想从这款软件中获得哪个具体功能。所以更多的是——哪个是最好的？哪个质量最高？如果你把东西放在一起，人们是视觉动物。设计就可以成为脱颖而出的那个因素——“嗯，那个看起来最好，或者对我来说看起来质量最高的产品，我就用那个。“当人们有很多选择时，他们很可能会选看起来最有趣的那个。

然后我觉得还有第二部分，就是品牌。如果你能建立一个品牌，那我觉得甚至产品本身几乎都不那么重要了，它变成了一种默认选择。再说 Apple 或者 Nike——对，你可以买各种各样的鞋，但人们有理由买 Nike 而不是某个随机品牌。即使那个随机品牌的鞋实际上更好，他们还是会买 Nike，因为他们——不知道——就是喜欢这个品牌。所以我觉得产品的设计以及品牌的设计，都可以成为非常强大的吸引力，把人们拉向你的公司或产品。

品牌建设

Lenny： 在构建 Linear 的过程中，关于品牌建设你有没有学到什么？有没有什么你觉得在真正建立 Linear 非常棒、非常出色的这种认知方面特别重要的东西？

Karri： 对我来说，我认为品牌应该始终是真实的，而且我觉得，即使人们无法明确表达出来，如果他们开始感觉有什么不对劲，那就说明品牌出了问题。我知道有些公司或创业公司会把品牌想成——哦，品牌就是 logo，就是网站的颜色之类的东西。然后他们照做了，其他公司也这么做了，他们就觉得，“好吧，我们现在有品牌了。“但实际上你并没有真正思考过你的品牌是什么，你想传达的信息或声音是什么？而且品牌也不是一夜之间就能建立的。

所以基本上就是从开始做起。当你创立一家公司的时候，你没有任何品牌，所以你必须去创造它。你通过你做的事情、你说的话、你说话的方式、你处理事情的方式、你对待客户的方式、你构建网站或产品的方式来逐步创造它。所有这些东西开始在人们脑海中构建起一个印象——这家公司对我来说意味着什么？

我知道我们俩都在 Airbnb 工作过，我觉得对 Brian Chesky 来说，品牌可能是最重要的东西。我都不知道他花了多少小时、开了多少会、进行了多少关于品牌的讨论。品牌始终是公司所做一切的一部分。因为事实就是如此。没错，你可以在网上很多地方预订住宿，但当人们想到”哦，我想住个酷的地方”时，他们会想到 Airbnb。他们不会想到其他那些地方。这就是品牌的力量——人们不再去想其他选择，或者他们开始理解，好吧，这个东西就是用来做这个的。

Lenny： 这也是 Airbnb 能够建立直达渠道的原因之一——人们不需要在 Google 上搜索”我想住民宿”，他们直接就去 airbnb.com 了。这给了 Airbnb 一个巨大的优势，不需要在 Facebook 和 Google 上投放广告，也不需要做 SEO。人们就是知道 Airbnb，直接就去那里了。很少有网站能让人们说”我就直接去那里找”，尽管他们知道也可以在所有其他网站上比较酒店价格。

简单回到设计这个话题，非常实际地问一下，你们怎么做设计评审？你们实际上是怎么审查正在进行的工作的？然后这可能是个太大的问题，但你能分享什么就分享什么——你怎么知道什么时候算完成了？你怎么知道什么时候可以交付、通过了审批，可以发布了？

设计评审流程

Karri： 我们一直在探索不同的方式。现在的话，我仍然在设计团队负责，所以我每周都会看一些设计。然后，或者其他联合创始人或产品负责人也会看——我们基本上是项目的 sponsor（负责人）。所以我们负责审查工作。我们可能就开个会，过一遍——好，我们来走一遍 demo，大家可以解释一下做了什么、怎么想的、为什么这么做。然后我们可能会给出反馈——这个看起来有点奇怪，或者什么地方需要调整——之后我就自己进产品里试用一下。在早期阶段，我们显然不会开始修复所有东西，更多是先把主要概念放进去，搞清楚它怎么运作。

但在发布之前，我可能就会进去试用，尝试不同的状态，到处点一点。有时候我会发现问题——比如我们在做评论的嵌套线程功能，在 demo 里看起来一切都很好，然后我去试用，尝试不同长度的消息，然后我就开始发现，哦，有时候动画有点卡顿，或者就是感觉不对。动画走的方向不对，滚动也不够精确。所以我就把这些问题截图下来发给团队。我们不得不稍微推迟发布，直到这些问题被修复。那个功能其实是个非常简单的概念，也是大家都很熟悉的概念——好吧，评论的嵌套线程就是这样工作的。所以那个主要是关于执行的——执行的品质如何？

但还有一些项目，我们不确定具体应该怎么运作，我们自己试用也不够，还需要看公司怎么使用它。比如我们做了”项目更新”这个功能。这是公司常见的做法——你需要写一个项目进展更新，状态是黄色、绿色还是红色？不同公司在不同工具有非常不同的做法。我们就想，我觉得如果这个功能集成在 Linear 里面会很棒，团队在做项目的时候可以直接写更新，Linear 也可以自动捕获一些实际数据，记录到底发生了什么。这个功能效果一直不错，但到现在我们也在探索——用了一段时间之后我们觉得，哦，如果有一种更完善的方式来跟踪这些更新呢？也许领导层可以直接通过邮件收到这些更新，或者当更新很多的时候，应该有搜索或过滤系统之类的。所以我觉得很多时候我们就是确定——好，目前的范围就是这样，我们对发布这个版本没有问题，执行品质也很好。但我们知道这不是最终完全想清楚的版本，我们还需要看人们怎么使用，收集反馈。

Lenny： 所以听起来，关于是否发布的决定，更多是你在实际试用过程中的一种直觉感受——凭直觉判断，这个可以了，还是这个还需要再打磨一下？

Karri： 是的，我觉得我们做的很多事情更多是这种感觉。我们不做 A/B 测试，我们也不针对特定指标去追踪或者设定目标。有时候我们确实有遥测数据，可以看人们怎么使用某些功能，我们有时候也会去看，但那通常不是我们的目标——比如”我们应该把这个数字提升多少”。更多是基于我们对问题的理解，以及基于我们的判断——我们认为什么是对的，这个解决方案对不对，以及这个解决方案是否足够好，可以发布给客户？

Lenny： 沿着这个话题再问一个问题——你们实际上怎么组织这些评审的？听起来你是直接去看原型。有没有一个正式的设计评审阶段？还是说都比较非正式，大家就是来评审——这是我们想让你反馈的东西？

Karri： 项目不一定有特定的阶段划分，但大致来说，我们通常确实从设计开始。会做一些设计上的探索，看不同的实现方式；有时候就一种方式，因为方向很明确。但就像我之前说的，我们会尽可能快地进入构建阶段，因为这样我们也能看到这个方向是否合理，它会不会导致什么问题，整体感觉怎么样。所以我觉得没有特定的评审阶段。更像是——好，我们每周或每两周检查一下这个项目，然后在发布之前，再做一次评审，认真测试一下，品质是否达到我们的要求？

Linear Method 与有主见的软件

Lenny： 很好。这是一个很好的过渡，可以聊聊我想花时间讨论的另一个话题——Linear Method。你们倡导一种产品构建方式，称之为 Linear Method，并且已经在线上公开了，我们会在 show notes 里放上链接。我想围绕这种产品构建方式问几个问题。第一个是，你们非常强调构建有主见的软件（opinionated software）这个理念。能不能谈谈这是什么意思，然后也许举一两个你们在 Linear 实际做到这一点的例子？

Karri： 先说 Linear Method，我们为什么要创建它？是因为我们相信存在更多现代化的软件构建方式和思维方式。我们想分享一些我们在这方面的思考。这也和 Linear 本身的构建方式相关。所以你可能就会理解我们为什么做出某些选择——因为这就是我们做选择时的思维方式。我们试图分享产品背后的思考过程，而不仅仅是把产品丢给你让你自己去摸索。

关于有主见的这一点，我个人有一个信念：生产力软件应该是有主见的，尤其是企业软件。我认为生产力软件要做的就是让人高效。而高效的含义是你真正做一些对公司有意义的事情——比如开发某个新功能、修复某个问题、设计某个东西。

这些事情最终都会为客户创造某种价值。我觉得世界上有一种观念认为灵活的软件是好的。我的看法是，灵活有时候确实可以很好。但实际发生的是，人们开始花大量时间去搞清楚事情该怎么做。比如这个功能怎么用？它可以以十种不同的方式使用，然后每个团队、每个人都摸索出不同的用法。

所以我们的想法是提供好的默认设置或好的主张。比如这个功能就是这样运作的，这个工作流就是这样走的。这样你作为用户或团队就不需要去想这些，可以把注意力集中在你实际的工作上。另外，我的设计信条始终是为某个人设计某个东西。要为所有人设计所有东西是非常困难的，因为你最终只会得到一个非常泛化的解决方案。所以我们试图用有主见的方案做到的是——提供我们认为最优的、至少是最优化的解决方案。

然后当你使用它的时候，希望你会认同，你能感受到它是经过优化的。所以有主见这个特点，我认为它给用户提供的价值就是——你不需要想太多，不需要在工具上花比实际工作更多的时间。

Lenny： Linear Method 的另一个核心要素是你们所说的周期（cycle）。我知道 Linear 的核心理念就是围绕创建周期、在周期中工作。能不能谈谈什么是周期，以及它在 Linear 是怎么运作的？

Karri： 比如周期这个功能，它是可选的，不是说整个团队或整个公司都必须使用它，而是你可以选择开启或关闭。但基本上，我认为我们创建周期的原因是——任何从事软件或其他产品开发的团队，总是有一个几乎无限长的待办清单，而且这个清单每天都在变长。这对个人或团队来说有时候会非常分散注意力——又来了一个新事项，我们应该做这个，还是做之前决定的那个？所以周期就是一种方式来表示：在接下来的一周或两周或任何时间范围内，我们要做这些事情，我们认为这些是这段时间的优先事项或焦点。

然后团队可以专注于这些事情。如果发生了什么状况，比如我们真的需要去处理另一件事，至少之前有一个初始状态——我们决定了要做这些事情，但现在发生了别的情况，所以我们不得不去做另一件事。这样当有人来问你”为什么你没做之前那件事”的时候，你就有了一个答案——“我们确实决定要做那件事，但后来发生了别的情况，我们不得不去做这件事。”

所以周期和冲刺（sprint）非常类似，但我们喜欢叫它周期，因为我们并不是真的在冲刺什么。周期也是按自动化计划运行的。所以你不需要想它哪天开始？或者每次都手动设置——它就是自动运行的。所以它就是帮助团队专注——让我们专注于这几件事，忘掉背景里无限长的其他待办事项。

不设指标目标

Lenny： 你之前提到你们不设指标目标，我想深入聊聊这个。这是真的吗？你们真的对功能发布、上线之类的事情不设数字目标？先从这里开始，然后我还有一个后续问题。

Karri： 我们有时候可能会有公司层面的目标，比如周活跃用户，这是我们想要提升的指标之类的。但具体到某个功能，我们不会为它设定目标。原因是，我觉得像我们这样的产品，一个被不同类型的公司使用的系统，它是由多个不同部分组成的系统，你没必要去优化其中某个特定的东西。而且各家公司也不太一样，所以他们对不同功能的使用方式可能不同——因为它们的运作方式略有差异，或者团队规模不同，或者团队配置不同，或者文化不同。

比如，我不太确定，像 Instagram 或者那些应用，确实——我们需要提升用户参与度，这是主要目标。每个功能都围绕这个核心指标。但我们其实没有这样的东西。我们只是认为应该有能帮助公司的功能，有时候我们可以在开始工作之前看一下指标——了解一下现状——但我们不一定要设定”我们需要把这个特定指标提升 X”这样的目标。更像是我们想要解决某个问题。理想情况下，成功的标志是客户认同这个问题的确被解决了，或者他们喜欢这个解决方案——而不是某个指标数字上升了。

产品团队如何运作

Lenny： 所以总结一下到目前为止的情况——你们没有指标，没有实验，基本上没有 PM，只有一位产品负责人。你们在设计和工艺上花大量时间，把东西做到极致。我很好奇，你觉得要让一家公司以这种方式运作需要什么条件？因为这和很多其他创始人的想法、很多其他产品团队的工作方式都相当不同。

Karri： 我们内部喜欢谈论这个，我喜欢这个魔力和科学的混合。就像我们描述的那样，我们确实也有一一定程度的科学成分。我认为有些公司在产品管理上非常科学化——他们喜欢测量一切，做大量测试之类的——但我们就是决定我们不认为那是必要的，也不认为那对我们是好的。所以科学对我们来说意味着——我们确实会大量地与用户交流。每个项目我们开始之前，都会做某种程度的用户研究。作为创始人，团队中的不同成员，我们可能每周都会和客户或用户通话。我们也鼓励团队中的每个人去客户 Slack 频道，回答大家的问题。我们与客户有共享的 Slack 频道。任何人——我有时候也会去那里回答问题。我也会看到他们抱怨什么。我认为第一部分是整个团队必须真正理解产品、理解客户、理解人们面临的问题，要有那种共情，同时也要理解当前的现状是什么样的。

然后我们会讨论这些发现。有时候我们可能会拉一些统计数据，看看是否存在某种模式——比如，哦，某类公司使用这个功能更多，我们怎么看待这件事？但通常是我们心里有某个具体的问题想回答，比如”我好奇这里到底发生了什么”，然后我们才会去看数据。而不是先拉一堆指标，然后决定我们应该提高某个指标。至于魔力部分，就是当你在构建这种理解的时候——公司里的每个人都在构建这种理解。不是说每个人的理解都一样，而是每个人都在建立更多对客户和产品的理解。然后我们讨论”我们应该做什么”或者”这里该做什么决定”的时候，每个人对客户和产品的真实情况都有了更充分的认知。

这样的话，你就可以更多地凭借直觉和思考来做决策，而不必用数据或指标来支撑。所以我认为关键在于，整个公司都必须和客户在一起、和他们交流，然后理解产品在哪里运作得好、在哪里可能不足。

Lenny： 这和我预想你会说的一致，我很高兴听到你这么说。如果有人想创建类似的文化，从战术层面来说，你有没有什么方法来判断你的员工、工程师、设计师是否掌握了足够的上下文，是否真正理解了问题？

Karri： 我觉得始终是这样的——公司里不同的人会有不同的理解程度。你不能指望每个人每天都去看所有东西、掌握一切。但我们确实偶尔会组织团队讨论会，或者录制与客户的视频，写笔记并分享给大家。我觉得，同样很明显的是——如果你了解你的客户和产品，你谈论它的方式和你不了解时是完全不同的。我觉得如果你完全不了解，你可能甚至不知道该说什么。

所以我觉得这很明显能看出来一个人是否有这种理解。也不需要每个项目都要求所有人都有这种理解。通常一两个人有这种理解就够了，或者不同的人对不同的事情有不同的理解。所以我觉得，再说一次，这是一种文化上的事情。另外一点就是你必须真正相信它。

我觉得有时候人们大量使用数据，甚至过度使用，是因为他们担心或害怕——万一我做错了选择怎么办？于是用数据来替自己做选择。但你可能仍然觉得这不是正确的选择，可数据告诉你是正确的——然后结果可能证明它是对的选择，也可能不是。但这更像是一种实践。我认为公司和你们自己都需要接受：有时候我们会犯错，做了错误的选择，然后我们去修正就好了。但至少那个选择是我们自己做的，不是数据替我们做的。

Lenny： 有意思的是——

Karri： 不是数据替我们做的选择。

不同的产品构建方式

Lenny： 这件事有趣的地方在于，如果你听过之前那期关于 Ramp 的节目，Geoff Charles 讲 Ramp 是怎么做产品的，你会发现构建产品的方式可以如此不同。Ramp 追求的是速度，不断地发布、看指标、测量一切。而你们的方式几乎是相反的。我觉得这里的一个启发就是——有很多种不同的做法，你必须几乎全力以赴地践行某一种，而且你需要非常特定的人。感觉上是，人们希望以某种特定方式工作。而且我觉得很大程度上，这种方式必须对创始人来说是自然的，符合创始人运营和构建公司的方式。

Karri： 是的，确实如此。如果你去看那些成功的公司，Amazon 和 Apple 的运营方式非常不同。两家都很成功，但不是以同样的方式成功。

所以我觉得这又回到了——作为一家公司或创始人，你要做一个决定：你想建什么样的公司。不过我认为也和所处的领域有关，那个领域和问题空间对公司有什么样的要求。对我们来说，我觉得——我们做的是留存和信任的生意。理想情况是，一家公司在很早期就开始使用 Linear，然后永远留在我们这里。而要做到这一点，我认为唯一的方式就是持续为他们提供高质量的产品，维持那份信任——不让他们失望，不在其他方面亏待他们。

而有些生意则更具交易性——比如，我们只需要完成这笔电商交易就行，交易完成后发生什么我们不在乎。

所以在我们的情况下，更像是我们需要长期地建立这段关系。正因如此，我认为我们做出的一些选择，更多是出于对客户的尊重，而不仅仅是为了推动公司收入。

Lenny： 太好了，这一点非常重要。

保持专注

（广告跳过）

我回来接着聊。你个人非常擅长的一件事就是专注。光是想把你请到这个播客上就费了我好大劲——“Hey Karri，你想过这件事了吗？“我知道很多 VC 一直在联系你，那些非常知名的 VC，就是想和你聊聊、想接近你。我知道你非常擅长抵制诱惑，保持极度专注，埋头做事。我一直想问你，你是怎么做到的？你有什么诀窍、系统、流程或方法来保持专注吗？还是说主要就是忽略收件箱？

Karri： 嗯，我觉得没有什么复杂的流程。我记得 2012 年我在 YC 的时候，他们说的最重要的事情之一就是：创业时你应该专注的事情就是——和客户交流、构建产品、锻炼。如果你发现自己在做这三件事之外的事，那很可能是不该做的事。

Lenny： 你刚才说的第三个是锻炼还是……

Karri： 对，锻炼。重点是你要保持健康，不要把自己耗尽。所以我觉得这是一种平衡。

Lenny： 好喜欢。

Karri： 所以我就做这三件事。

主线任务与支线任务

Karri： 我觉得这里的思路是这样的——我们公司内部也经常讨论这个问题，而且很早就在讨论。我个人是这样用的，我觉得公司也可以这样用。我认为，总有一些事是你”应该做的”，或者听起来是个好主意。比如，“来上这个播客吧”。实际上我觉得之前并不是……

我一直在问自己这个问题：这件事是现在必须做很重要，还是以后也许做就行？比如拿上这个播客来说，我不觉得之前来做很重要，因为那时候我们的阶段、规模还没到能让这期内容那么有意思的程度。所以我觉得晚一点做是更好的时机。

同样地，我们做产品的时候也是，最开始就非常聚焦在”这真的是一件重要的事吗？“总是有人说，“对啊，你可以去拿 SOC 2 安全认证。“我们知道迟早要拿到，但今天不需要。我们就说不做。如果客户问起来，我们就说我们还没有，总有一天会有，但不是现在。你会发现很多时候对方会说，“好吧，没问题。”

内部我们也会聊这个。你知道 RPG 游戏里有主线任务和支线任务吧。我们经常说，公司要避免支线任务。大家总是有很多想法，这本身是好事，但可能会变成，“嘿，我们做件 T 恤吧，搞个什么东西吧。“然后我们就说，“这对客户有帮助吗？对产品有帮助吗？“这听起来像是个支线任务，意思就是不该做。它不会推进主线任务——也就是打造这个产品，让它对这些客户来说足够出色。

对我来说也是一样的。我个人也按这个方式运转——我会想，“这对建设这家公司的主线任务重要吗？还是说我现在可以忽略它，或者以后做更合适？”

Lenny： 这个建议真的太好了。基本上就是问自己，“这件事现在做有多重要？这是主线任务还是支线任务？“非常棒。

招聘哲学

Lenny： 好，我们来聊聊招聘。和大多数领域一样，你在招聘上非常、非常、非常深思熟虑。Linear 的门槛高得离谱，而且你们招的人也非常少。沿着这个方向我有几个问题——第一个是，你在招人的时候，有哪些东西是你特别看重的，而其他人可能看得不够？你在哪些地方花很多时间？

Karri： 我觉得我们这些创始人在高速增长的公司里都看到过一件事：有时候高增长，尤其是在员工方面的高增长，并不一定是好事。它会制造很多混乱和一团糟。或者说就我过去的经验，在各家公司工作，几乎从来没有……和一个小而精的高质量团队合作，总是比和一个庞大但水平参差不齐的团队合作更容易。人少得多的时候，几乎总是更快、产出更好。

Linear 也是同样的信念，我们就是相信人少能比人多做出更好的东西。这是我们的基本信念。所以到了招聘上，我们一直走得很慢——第一年我们几乎没招人。第二年招了几个人，然后又招了一些。我们从没有在一年内翻倍过。这也是我们的准则：不要一年翻倍。未来也许我们会调整，可能实际增长比这更少。

但具体到招聘，有几件事。首先当然取决于岗位，但基本上每个岗位，我们都会说这个人需要有一些品味，或者说对事情该怎么做有一种理解，有一种超越自身岗位职责的更广的视角。

前面聊工程的时候我们说过，他们确实需要做一些 PM 类的工作。所以我们在他们身上寻找的是：他们有没有这方面的技能或产品思维？他们能不能清楚地说明为什么某些选择比另一些更好？在过去他们有没有不同意公司或团队决策的经历？我们希望看到——当然他们得是优秀的开发者——但他们是否也有产品层面的敏感度，是否有这方面的判断力？

类似的，比如招市场营销的人，我们会想：对，我们需要市场营销的技能，但我们也想看到这个人可能也是个擅长讲故事的人，或者对写作、对故事有鉴赏力，对什么有趣什么无趣有自己的品味。

招运营的人也一样，我们希望看到他们可能也懂一些 HR，也许那不是他们的本职，但他们理解。当你拥有这些能力超出自己头衔的人，公司我觉得会好管得多，因为大家更容易接手新事物，也更容易协作，每个人都有更多交集，你很少会听到有人说”这不是我的工作”。大家更像是，“好吧，我做运营的，但今天需要帮这个 HR 的事，没问题。“所以我们寻找的人是——他们能承担的职责范围超出他们技能集通常暗示的，或超出一般预期的。

Lenny： 所以本质上你在寻找不同职能和团队成员之间的韦恩图重叠部分。

Karri： 对。另一件事就像我前面说的，我们想建一个员工更少的公司，这意味着——我说过——我们不想要那么多专职角色，或者过于狭窄的职责领域。我们就是觉得我们可以用更少的人来建设，这些人可以承担更广的职责范围。

传统上，我感觉在很多公司里，你要获得更大的职责范围，就得在公司层级里往上升，因为有很多不同的团队和层级。然后你想获得任何范围的控制权，就得爬到更高的层级。我们想做的恰恰相反——你不需要那么多层级，人们从一开始就可以开始承担更多的领域。

我觉得这对很多人来说——虽然不是所有人——会更有意思。这就像我作为一个设计师一直以来的感受：我不觉得我的工作就只是看设计图。我也觉得我需要帮助这个业务，或者帮助其他领域。所以我觉得这对我来说也很自然。

带薪试用与产品敏感度测试

Lenny： 太好了。有一件事你没提到，就是你们有一种非常独特的面试方式——带薪工作试用。能聊聊那是什么吗？另外，既然聊到这里，你之前提到过测试产品敏感度，如果能分享一下你们具体怎么做就更好了。

Karri Saarinen： 我们对所有员工都会做带薪工作试用，具体形式和时长取决于职位，有时也取决于个人情况。在这之前，我们会进行比较标准的面试流程——有招聘经理的面试，也有技能面试或测试。整个流程的最后一步就是工作试用。

他们基本上是以”迷你承包商”的身份来到公司，我们会给出一些通常比较模糊的问题描述。如果你是工程师，我们会说：这个功能需要实现，你会怎么做？然后就去实现它。所以他们首先需要理解问题，然后把它缩小到在给定时间内能完成的范围，接着他们会获得代码库的访问权限，真正去构建一个版本，最后展示他们的工作成果。

我们这样做的原因是，这对双方来说都是一个很好的方式，可以看看我们能否很好地合作。对候选人来说，他们能看到：你要加入的是一家什么样的公司，在这里工作是什么感觉，以及我们是如何理解”所有权”的、我会怎么处理这些问题。

很多工程师也喜欢这一点，因为他们能看到代码库，会说：哇，代码真的很整洁，不是那种意大利面条式的代码。所以我觉得这也帮助候选人更好地理解他们将要签署的是什么，这一点有时候风险很大。尤其是创业公司，光靠面试很难判断公司的运营方式。在大公司，流程更标准化，彼此之间更相似，做选择相对容易。但创业公司的运作方式可能差异非常大。

Lenny： 这真的很独特，我很少听到有公司能这样招聘。我想你们能做到这一点——让人们在一段时间内没有全职工作来做带薪试用——其中一个原因是 Linear 是一个非常令人向往的工作场所。我想对大多数公司来说，他们可能做不到。不过你觉得，是不是有更多公司其实也可以做到这件事？

Karri Saarinen： 我觉得这就像——如果你不问，你就不知道。在我们这里，这已经是标准做法了，我们会和候选人一起想办法——也许可以安排在周末，或者安排在其他假期期间，总之尽量减少对候选人的影响。

我觉得大概只有少数几个人曾经拒绝过。其他人，至少事后来看，都很高兴自己做了这个试用，因为他们觉得自己对要加入的公司有了更好的了解。而且在试用期间，他们实际上可以参加我们的会议，获得我们的 Slack 和 Notion 的访问权限，还可以和团队中的其他人进行一对一的交流。

所以他们已经开始认识人了。这也是他们评估我们的一个好方式。而对我们来说，我们能看到的是——这个人如何在这种环境中工作，如何处理问题，如何思考，以及是否能在很短的时间内取得进展。我觉得这一点对创业公司来说非常重要。在大公司，你也许有无限的时间来做事情。但我觉得任何创业公司，即使我们有时候做事不急，快速执行的能力仍然很重要。需要快的时候，我们能做到快。

Lenny： 太棒了。关于产品敏感度这个话题，你能不能再分享一下，你们具体是怎么判断一个人在这方面的能力和优势的？

产品敏感度的评估方式

Karri Saarinen： 我不会说我们有什么非常科学或特别的方法来评估这一点。我觉得很大程度上就是通过讨论。我通常会问人们关于他们的项目，然后试着深入追问——比如这个决定为什么这样做？你觉得当时为什么做了这个决定？我可能会问：“你觉得这个决定对吗？你当时同意吗？“或者问你觉得你会怎么做、会有什么不同。

所以我更多是在试探，看他们在这个领域的思考深度。人们的回答可以处于非常不同的层次。有些人可能会说，“嗯，我不喜欢。“好吧，这是一种看法，但不是基于任何东西的——你只是不喜欢而已。你应该能够展开说明，比如：我不喜欢它，因为在这种情况下，它对这类用户不太好用，或者在这种场景下、或者用于这种目的时效果不好。

所以他们有更多的推理，或者某种理性的依据来支撑他们的想法，并且能够清晰地表达出来。我觉得我们经常测试的就是——他们能不能做到这一点，能做到什么程度。这方面人与人之间的差异可以非常大。当你遇到一个真正深入思考这些问题的人，你会很明显地看出来——他们可以就此永远聊下去，越聊越深。而那些可能没有这种经验或者不以这种方式思考的人，会说：“嗯，我不太清楚，我就是把它做出来了，看起来还行。“

Linear 的增长

Lenny： 我们来聊第三个我想花些时间探讨的话题——增长。我特别想了解 Linear 是如何增长的，以及在 B2B SaaS 领域你们有哪些发现。

第一个问题是，从开始做 Linear 到发布——比如说 V1，一个有一定数量用户可以用的版本——花了多长时间？

Karri Saarinen： 我们在 2019 年正式启动。在那之前的几个月里，我们已经在探索和做产品原型了。我们尝试了一些不同的设计方案。

我们当时特别想解决的一个问题是让应用真正快起来。我们想到的方式是采用一种偏本地化的数据结构——所有数据都存在客户端，然后通过 delta 同步的方式与后端同步。

当时我们调研了各种现成的解决方案和系统，但没有什么真正可用的，所以我们最终自己构建了一套。我们花了一些时间做原型。正式开始做公司大概是 2019 年 4 月，然后大约四月中旬公布了公司，做了一个简单的网站和一个等待列表。到五月我们自己就能用了，然后开始邀请一些朋友试用。

到了六月，我们开始更多地从等待列表中邀请用户。六七月左右，我们大概有 100 到 200 个用户，10 家左右的公司在使用。然后我们进入了一个持续将近一年的私有测试阶段。我们的做法就是维护一个等待列表，上面有几个调研问题——你现在用什么工具、为什么想用 Linear、公司规模是多少。

等待列表与邀请策略

Karri Saarinen： 我们邀请用户的方式是……我们优先邀请那些正在使用我们当前支持工具的小公司。同时我也会判断谁是真的感兴趣，而不是那种”我就随便试试”的人。一年后的六月，我们公开发布了产品。那时候大概已经有几百家公司在使用了。我们还同时公布了定价方案，我想几乎所有的公司……可能只有一家没有订阅，其余全都订阅了付费方案。

Lenny： 这里面有很多非常有趣的东西。第一个点是你们做了将近一年的私有测试，然后才公开发布。从开始酝酿、开始构建到进入私有测试这个节点，中间隔了多长时间？

Karri Saarinen： 我想大概只有几个月。就——

Lenny： 只用了几个月就做出了 V1？

Karri Saarinen： 对。

Lenny： 哇，好吧。我还以为要长得多。这太有意思了。你们那个团队真是厉害。

等待列表中的问卷设计

Lenny： 好的。然后这个问卷的部分也很有意思。我之前听说过这个故事的一些片段。基本的情况是你们在 Twitter 上发布了产品，创始人们本身有一些粉丝基础，所以这帮助你们积累了最初的等待列表。

但你们做的不仅仅是”嘿，来注册个等待列表”然后让大家填个邮箱地址。你们放了一份问卷，问他们现在用什么工具——是 GitHub 还是别的——还有公司规模以及他们的兴趣方向。这帮助你们基本上确定了优先邀请谁、优先让谁上手。是这样吗？

Karri Saarinen： 对。我们这样做的原因在于，我们知道自己并没有支持所有的东西，以及我之前提到的专注策略——我们希望集中精力，先做一个能满足一部分人、一部分公司需求的版本就好。在创业的头几个月里，我们不需要试图覆盖全世界所有人。之后也不需要。所以这是一个非常筛选性的过程。我觉得我们很幸运，能够让大家愿意在等待列表上注册，大概一个月之后，我们可能就有 4000 人在等待列表上了。

队列式邀请与反馈循环

Karri Saarinen： 我们内部后来有了一个……最开始其实就是一个非常手工的流程，但后来我们做了一个邀请工具，可以直接发送邀请。但在最开始，我会亲自去看表格里的问卷回复，然后复制邮箱地址，从我的个人邮箱给他们发邀请链接。过几天或者一周后，我还会再给他们发邮件问：“嘿，你觉得怎么样？”

我们之所以这样做，是因为我们觉得如果一次性邀请所有人或者一次性邀请大量用户，在这么早期的软件里，他们大概率会撞上同样的问题。比如同样的 bug，或者同样的使用障碍。然后他们都会给我们发反馈说：“嘿，这里有这个问题。“那我们就觉得这些反馈是重复劳动了。

所以我们采用队列的方式。先邀请一批人，然后他们说：“嘿，这里有问题，这个不好使，“等等。我们就去修复。修好之后，再邀请下一批人。下一批人会说：“嗯，这个功能需要，或者这个不好使，“我们再去修。

那一年里，我们就这么做了一批又一批的队列，每次都从队列中获取反馈——哪里不对、哪里不好用——然后修复。最终我觉得这比一开始就让所有人直接使用产品要高效得多。

早期付费实验

Lenny： 这里有太多值得借鉴的经验了。我想问你们是怎么获得前 10 个客户的。从你的描述来看，基本上就是通过这个等待列表——在 Twitter 上发布后有人注册，你们从中挑选用户让他们上手，用一年的时间跟他们一起打磨产品到他们需要的程度，最后开始收费。

Karri Saarinen： 对。最早使用产品的 10 家公司里，大概有一半多一点——可能有 3 家是朋友的创业公司在用。其余的大多来自等待列表。但他们当时并没有付费。我们在最开始和私有测试期间都没有定价。到了某个节点，我们开始开发支付功能，就在设置页面加了一个入口，你可以选择性地付费。

设置页面里有一个可以选择付费的入口，我们放了一个滑块，让你自己决定每个席位想付多少钱。我们就想看看……我知道有人付了 28 美元一个席位，也有人只付 1 美元，但这无所谓，我们只是想测试功能本身，看看大家怎么反应。一年后我们正式发布时，我们已经有……可能在发布的第一周内，就有几百个付费客户了。

Lenny： 我从来没听过这种定价方式——直接用一个滑块让用户自己滑动决定付多少钱。这有帮你们确定该收多少钱吗，还是说主要就是一个实验？

Karri Saarinen： 我不觉得它提供了足够的数据来做决定，但我觉得看到有一些人确实会去……我记得 20 美元大概是上限了，有一些人直接拉到了那个位置，他们的感觉就是：“说实话，我真的很喜欢这个产品，我很乐意付 20 美元。“我觉得至少这给了我们一些信心——如果我们对产品收费，而且价格在 20 美元以下，是会有市场的。

产品市场匹配的感受

Lenny： 我想听听你们是什么时候开始感受到产品市场匹配的——不管你怎么定义这个概念。你什么时候开始觉得：“哇，这真的能成，也许这会成为一个真正的生意”？

Karri Saarinen： 我觉得我们一直是……怎么说呢，有一种偏执，或者说偏执可能是个合适的词，关于产品市场匹配这件事。我们的偏执在于，我们总是在想：“我们真的有产品市场匹配吗？“以及”我们和谁之间有产品市场匹配？“我觉得在我们的业务里确实如此……我们很早就开始有那种感觉了。当人们开始使用产品，我们能观察到：“现在整个公司都在用了，他们看起来用得更开心，反馈也很好，他们可能还有一些额外的需求，“但我们开始感觉到，和某类客户之间确实存在产品市场匹配——这些客户更多是较小的、早期阶段的公司，创始人可能还在亲自管产品，他们在乎的是交付速度，或者在某种程度上有特定的价值观——所以跟他们的匹配度很好。

然后我觉得我们一直知道我们想要覆盖整个市场，而不仅仅是这些早期阶段的客户，但我们也清楚，如果一家财富 500 强公司当时来找我们，甚至现在来找我们，我们可能也做不到……我不觉得我们今天能为他们提供真正适用的解决方案，所以我认为那个匹配还不存在。对我们来说，我们的思考方式是：“我们在特定细分市场里是否有产品市场匹配？“以及这个匹配有多强。在公司发展的历程中，第一年我们只专注于”我们能不能在早期阶段创业公司这个细分市场里获得匹配……”基本上，目标就是”我们想成为创业公司的默认选择，创业公司默认会选择的工具”，我觉得我们做到了这一点，但我们纯粹就是专注于那个细分市场，把产品市场匹配做到位。

与此同时，我们开始接触到一些更大的公司，我们发现：“嗯，现在对你们来说确实还不太理想，但让我们继续努力，把它做得更好。“所以我觉得过去两年我们一直在专注这件事——“我们怎么让软件在更大的公司里运行得更好？怎么在几百人甚至上千人的大公司这个细分市场里让产品市场匹配变得更强？”

Lenny： 我觉得这种看待产品市场匹配的方式非常聪明。很多人把产品市场匹配看作一个二元的东西——“我有或者我没有”，然后问”我到底什么时候才能真正感受到产品市场匹配？“你描述的恰恰是我经常听到的说法：它更像是一个光谱，你对产品市场匹配的信心在不断增强。更具体地说，是你在市场的某些细分领域里获得了产品市场匹配。这就像一张世界地图，你在市场中一块一块地慢慢占领领地，然后随着时间的推移，版图不断扩大。

Karri Saarinen： 对，我觉得用光谱来思考也是个很好的方式。我记得过去有一篇博客文章讲的是你什么时候知道自己有了产品市场匹配，我觉得那可能……对于某些社交消费类应用来说确实是这样。如果它起飞了就是起飞了，你其实没有太多不同的细分市场可以去想，你也不会真的去细分——你有几百万用户，然后你看到它在增长，所以你知道自己有了产品市场匹配。但我觉得在更偏 B2B 的领域里，你总会有……你的客户规模不同，客户所在的领域不同，不同的类别里你可能在一个类别做得很好，但在另一个类别表现一般。

专注已经见效的细分市场

我觉得可能更正确的做法是，如果你在某个类别里做得真的很好，就应该在那个类别上加倍投入。这一点我在公司发展的某个阶段和 Zoom 的创始人 Eric 聊过，他说的也是同样的道理。他们在早期做 Zoom 的时候，会获得某一类客户——比如说可能是大学，产品对他们来说真的好用。然后他们就想：“我们怎么获得更多这样的大学？“他们总是会聚焦在某一种客户上，而不是说”我们试试让所有人都来用，所以让我们什么都关注”——这是不可能的。归根结底还是关于专注。如果你看到某件事做得特别好，那你几乎就应该专注于把它做得更多，直到你达到某个节点——“好吧，现在这个类别我们已经拿下了，或者说我们已经处理到我们想要的程度了”，然后再扩展到新的领域。

Lenny： 本质上就是寻找拉力，然后顺着拉力走，并且关注它。

Karri Saarinen： 对。我觉得对我们来说，有时候会出现一些……比如说，现在大部分 AI 公司都在用我们的产品，所以我觉得这总是……在之前，是加密货币公司，所以我觉得当我们看到这些现象的时候，就会开始想：“我们能不能做点什么不同的事情？我们能不能让更多 AI 公司加入进来？”

Lenny： 这真是一个很好的经验。再问几个问题就结束了。你之前提到你们在 Twitter 上发布产品，然后有了很长的等待列表，而且这个列表还在不断增长。在此之前你有没有做什么来积累这个关注度？这听起来太厉害了——“我们在 Twitter 上宣布了一下，就有了这么长的等待列表，然后我们不断增长，获得了所有这些客户。“你有没有在发布之前提前做了什么准备？你会建议人们在创业之前先在网上建立某种关注度吗？还是说只是”我们碰巧有这些关注者”，然后就奏效了？在这些问题上，你对现在的创始人有什么建议吗？

发布与早期关注度的建立

Karri Saarinen： 对。我觉得如果你有关注者的话当然有帮助，而且显然取决于什么样的关注者。我的背景是设计师，在 Airbnb、Coinbase 等地方工作过，也在会议上做过演讲、写过博客文章。我确实是有一定曝光度的，也有一批关注者，这确实有帮助，但也不是说我有几十万或几百万关注者。我大概就一万左右，这是一个不小的数字。但我觉得另一方面是……我们在发布公告这件事上，我觉得有一点做得不错——有时候创业公司会过度模仿那些成功的大公司，做一个非常花哨的发布，比如”嘿，我们现在要做这个很厉害的东西”，听起来非常官方。

我们的公告写得更直接、更真实——“这是我们要做的事，这是我们做的原因，这些是我们要做的一些事情。“在 Twitter 上也是一样的做法。我们几个创始人各自写了自己做这件事的原因，我觉得这样更……我觉得和我们类似的人更能产生共鸣，所以我们其实是在写给对的受众。我觉得这可能是你发布公司时首先要考虑的事——“我的第一批受众是谁？谁会是这个产品最好的早期用户？他们在哪里？“然后是”他们怎么思考问题？他们用什么语言？“对我们来说，这非常自然，因为我们自己就是这些人。

我们自己就在做软件开发，就在这些公司里工作，其他人也看到了和我们看到的类似的东西，所以我觉得我们发布的方式引起了很多人的共鸣。另外我觉得我们也确实有一些朋友……我之前说过我们做了一轮天使融资，拉了一些朋友进来。我们这样做的主要原因是，在早期阶段，你会觉得……有一种”我是一家真正的公司了”的感觉，你有需要交代的人。虽然投资人通常不会来运营你的公司，他们也没有那么多权力，更多的是一种”我拿了别人的钱，所以我需要让它值得”的心态。在发布的时候，我们同样可以借助这些人来传播消息。

公司文化与烘焙比赛

Lenny： 在我们对话结束之前，还有几个比较宽泛的问题。Linear 有一种相当独特的文化，我知道一件很有趣的事是你们有一个烘焙比赛。你能聊聊这个吗？你们具体是怎么做的？

Karri Saarinen： 因为我们是一家完全远程和分布式的公司，团队分布在欧洲和美国，很多集体活动都很难组织。远程集体活动本身就很有挑战，因为时差太大，所以像快乐时光这类基本的社交活动效果都不太好。而且 Zoom 快乐时光本身可能也没那么有趣。公司里很多人都看《英国烘焙大赛》（The Great British Baking Show），所以我们想，“要不我们也搞个类似的活动吧。“基本流程就是我们选一个食谱。一开始只做烘焙，后来扩展到了烹饪食谱。我们选一个在几个小时内比较合理可行的食谱，不需要大量设备或高超技巧。然后告诉大家，“去买食材，刷公司卡”——每个人都有公司卡——“然后在指定那天上 Zoom。”

对我来说，因为我在加州，时间大概是早上八点，所以我们就在那个时候开始烘焙或烹饪。我们做过蛋糕卷、柠檬蛋白派，还做过一些葡萄牙蛋挞之类的葡萄牙糕点。然后大家上 Zoom，各自忙各自的，跟着食谱做。有时候会有人问，“嘿，“比如”我卡在这一步了，“或者”我的面团看起来怪怪的，你们的面团也是这样吗？“大家可以互相帮忙，同时也能随便聊聊各种有的没的。做完之后，每个人拍照片发到 Slack 频道里，展示自己的成果。我们还有友好竞赛，看谁做得最好，所以有些人会在装饰和视觉效果上花很多心思。

在某种程度上，这又回到了我们喜欢的”手艺”这个主题。我觉得烘焙和烹饪这类事情也是一种手艺，所以我们很喜欢这种形式。基本上从公司成立之初，我们就每季度做一次。最近一次，我们有点……我觉得大家没那么多时间，所以决定做一个更简单的——夏季饮品食谱，大家做了抹茶饮料、椰子饮品、白冰茶之类的。嗯，挺有意思的。

Lenny： 你自己赢过这些比赛吗？

Karri Saarinen： 我不太确定我们有没有正式宣布过获胜者，但我确实觉得我……因为我是设计师，所以在视觉呈现上有一些优势，我觉得我在这方面通常表现不错。当然，在这种远程比赛中，这也差不多是你唯一能比的东西了。毕竟不关乎味道或口感，因为你没法通过 Zoom 品尝。

从设计师到 CEO 的领导力感悟

Lenny： 也许作为最后一个问题，同样是比较宽泛的——你从独立贡献者（IC）设计师，到设计师管理者，再到一家快速增长公司的 CEO。在 Linear 的这段旅程中，你学到了什么关于领导力的东西，是之前没有预料到的？

Karri Saarinen： 有点出乎我意料的是，做 CEO 或其他一些领导角色，你需要做那么多不同的事情。当我是一名设计师的时候，即使在某家公司担任高级设计师，你也主要专注于设计，那就是你的工作。但当你成为 CEO 之后，每周甚至每天都会有不同的事情冒出来。有时候是问题，但很多时候是，“嘿，我们需要想清楚怎么做这件事。我们怎么设计这个薪酬方案？“或者”我们怎么做这个市场计划？“或者”我们怎么安排这次团建？“对我来说，真正的挑战在于应对各种扑面而来的不同事务，同时还能在某些事情上保持一定的专注。

我觉得我还没有完全搞清楚这个问题，但我也想明白了一些——招聘和授权是有帮助的。如果你能找到其他领导者来承担特定领域的工作，那会很有帮助。主要就是这个——你需要处理的事情范围非常广，很多可能你之前没有经验，但另一方面，我觉得学习这些东西对我来说也很有趣。你学习财务知识，你学习法律事务，然后慢慢地你会觉得，“其实，我对这些东西也有了一些了解。“

Linear 的未来

Lenny： 真正的最后一个问题，在我们进入非常令人兴奋的快问快答环节之前——Linear 的未来是什么？会有什么新东西？未来会发生什么？有什么可以分享的吗？

Karri Saarinen： 我们一直都在开发和改进各种东西。一个比较新的功能是我们正在做的叫做 Asks 的功能。基本思路是——我们看到，在一家公司里，有很多不同的人需要和产品团队互动，或者需要和某个团队互动，但他们不一定在 Linear 里，也不属于这个团队。我们正在构建的 Asks 功能是一个与 Slack 的集成，你可以非常方便地进入一个 Slack 频道，然后提出你的需求。你需要某个团队提供一些东西，也许是 IT 团队，你需要一台笔记本电脑，或者是基础设施团队，你需要他们帮你处理什么。然后负责处理请求的团队可以非常方便地把它发送到 Linear，进入我们的分流（triage）流程，然后开始处理。

如果他们对实际的请求者有问题或补充问题，可以把消息通过 Slack 发回给那个人，所以请求者实际上不需要打开 Linear，也不需要成为 Linear 用户。我们认为这是一个很好的方式，让整个公司都能更多地参与到产品运营中来，而不需要成为 Linear 的重度用户，因为不是每个职能部门都需要或应该使用它。

Lenny： 太棒了。很有意思，提前看到了一个即将推出的功能，也许这期节目播出时就已经发布了。说到这里，我们进入了非常令人兴奋的快问快答环节。我给你准备了一堆问题。准备好了吗？

Karri Saarinen： 好了，准备好了。

快问快答

Lenny： 好的。你推荐最多的两三本书是什么？

Karri Saarinen： Christopher Alexander 的《建筑的永恒之道》（Timeless Way of Building）。他不算是严格意义上的建筑师，但我想他在伯克利教过书。他有一些建造事物的有趣思考，主要关注建筑、城镇和这类空间，但我觉得其中很多东西对构建软件也很有启发。另一本我喜欢的是《禅与摩托车维修艺术》（Zen and the Art of Motorcycle Maintenance），因为它也谈到了事物的品质，我觉得这是这本书的主题之一。有意思的是，品质这个东西很难定义。如果你真的开始思考它，就会发现，你怎么定义它？真的很难精确描述，但就像你去体验或看到某个东西的时候，你就知道它是不是有品质。

Lenny： 最近有什么喜欢的电影或电视剧吗？

Karri Saarinen： 电影的话大概是《疾速追杀 4》（John Wick 4）。显然，那部电影没什么剧情，但我认为它非常忠于自己的本质，我喜欢这一点。另外，我最近开始看 Apple TV 上的《羊毛战记》（Silo），我觉得挺好看的。它是一个很好的悬疑故事，而且它让我想起了《辐射》（Fallout）系列游戏，所以我也喜欢这一点。

Lenny： 我其实读过《羊毛战记》的小说，特别期待剧集上线，但我在之前的播客里提到过，这部剧和原著的关系太少了。核心设定是一样的，但剧里加了好多他们自己编的故事，所以我不看了，因为那不是我期待的——

Karri Saarinen： 有意思。也许我看完剧之后去看看原著。

Lenny： 对。一定要读原著，但一共三本，只有第一本是真的好看。其他两本其实不怎么样，我不该读的，因为后面就有点跑偏了。好了，下一个问题。你面试候选人的时候，最喜欢的面试问题是什么？

Karri Saarinen： 我通常会问，候选人最自豪的事情是什么，为什么？可以是职业上的，也可以是其他方面的，他们最自豪的事情是什么，以及为什么。然后我们可以深入聊聊这个，但我觉得这个问题能给你一些暗示，了解这个人看重什么，他们怎么思考问题。而且我觉得，让人们分享一些他们认为自己做得非常好的事情，我们把时间花在这上面，总比问一些偏负面的问题要好。

Lenny： 最近有没有发现什么特别喜欢的产品？

智能照明

Karri Saarinen： 不确定算不算最近才发现的，但最近在家庭办公室里，我装了一些 Hue 灯，非常喜欢。因为白天开会的时候可以用更亮的灯光，到了晚上又可以改变色温，调成偏红或偏橙的暖色调。我觉得很棒的一点是你可以让空间有一个过渡感——“好了，现在是工作时间”，“现在我在做别的事情”。你可以用灯光来标识这个切换。

Lenny： 太酷了。你是自动设置时间表还是手动换颜色？

Karri Saarinen： 我手动切换。在 Home App 里我设了几个场景……有夜间场景，还有日间场景和晨间场景，我点一下按钮灯光就切换了。

Lenny： 真的太酷了，我要自己试试。你有没有什么最喜欢的人生座右铭，会经常对自己说或者分享给别人的？那种你经常回到的东西。

人生座右铭

Karri Saarinen： “慢就是快”。我觉得对我来说就是这个意思。有时候人们倾向于急急忙忙地做事，尤其在创业公司里，但其他地方也一样，会有那种……我觉得紧迫感很重要，但有时候紧迫感过强，你就会赶工，结果就是赶完了又得回来修补。我觉得有时候应该花点时间好好想想，“你要做什么？“想清楚再做。最终这比反复来回修补要快得多。

Lenny： 你父母教给你的最有价值的一课是什么？

父母的教诲

Karri Saarinen： 我想是对人和物的尊重。尊重他人比较显而易见，但我觉得对你拥有的东西，也应该好好爱惜。用完之后清洗干净或者收好，下次用的时候就是准备好的状态。我喜欢这种感觉。与其把东西当成垃圾或者不值钱的东西对待，不如把它们当作有价值的东西来对待。

Lenny： 最后一个问题。你出生在芬兰，也是在芬兰长大的对吧。有没有一种芬兰食物，你觉得大家一定要尽快尝尝的？

芬兰美食推荐

Karri Saarinen： 一个是三文鱼汤。听起来可能有点奇怪，鱼汤嘛，好像不会那么有意思。但它是一种奶油浓汤，里面有土豆、胡萝卜和其他配料，还带一点点甜味。你可以在家自己做，或者如果去芬兰的话，总有几家餐厅会供应。

Lenny： 好的，听起来不错。这边能吃到吗，还是必须去芬兰？

Karri Saarinen： 我觉得在美国的餐厅里从来没见过，但自己做并不难。你大概搜一下食谱就行。基本就是需要三文鱼、一些基本调料、奶油和一些蔬菜。

Lenny： 好。下一期我们和 Karri 一起做烹饪节目。Karri，非常感谢你来这里。你在用一种非常独特的方式打造一家特别的公司，我认为很多创始人和很多产品人可以从你运营公司和打造产品的方式中学到很多东西。再次感谢你来到这里。最后两个问题。大家如果想联系你，可以在网上哪里找到你？听众怎样能帮到你？

Karri Saarinen： 我在 Twitter 上，名字就是 Karri Saarinen。我们还有 Linear 的账号，我觉得也挺有意思的，就是 @Linear。希望大家都能试试 Linear，看看它是否适合你们的公司，了解一下是否可以试一试。我们一直很乐意在这类事情上提供帮助，如果你只是想试试看、和团队一起试用，我们可以帮你搭建，帮你了解怎么使用这个产品。

Lenny： 好的。就是 Linear 这个 app 对吧？网址就是这个？

Karri Saarinen： 对。

Lenny： 好的，简单明了。Karri，再次非常感谢你来。大家再见。非常感谢收听。如果你觉得这期节目有价值，可以在 Apple Podcasts、Spotify 或你喜欢的播客应用上订阅。也请考虑给我们评分或留言，因为这真的能帮助其他听众找到这个播客。你可以在 lennyspodcast.com 找到所有往期节目或了解更多关于这个节目的信息。下期再见。

术语表

原文中文
A/B testingA/B 测试
AirbnbAirbnb
AmazonAmazon
AndreasAndreas
Brian CheskyBrian Chesky（Airbnb 联合创始人兼 CEO）
cohort队列
CoinbaseCoinbase
cycle周期
delta syncdelta 同步
Eric (Yuan)Eric（Zoom 创始人袁征）
FacebookFacebook
Geoff CharlesGeoff Charles
Hue lightsHue 智能灯
issue tracking问题追踪
JoriJori
Karri SaarinenKarri Saarinen（Linear 联合创始人兼 CEO）
LennyLenny（播客主持人）
Linear MethodLinear Method
local-based data structure偏本地化的数据结构
main quest line主线任务
net negative lifetime burn rate负的终身烧钱率
opinionated software有主见的软件
PMPM（产品经理）
private beta私有测试
product-market fit产品市场匹配
RampRamp
scope职责范围
seat席位
show notesshow notes（节目附注）
side quest line支线任务
sliding scale滑块定价
SOC 2SOC 2（安全合规认证）
sponsorsponsor（项目负责人/担保人）
sprint冲刺（sprint）
telemetry遥测数据
TuomasTuomas
V1V1（第一个版本）
VercelVercel
wait list等待列表
weekly active users周活跃用户
YCYC（Y Combinator）

此文档由 AI 分片翻译（translate_long_document）