基本信息
阅读时间：约 16 分钟
字数：约 6436 字
摘要：Linear团队的故事是我一直以来就想分享的。他们不仅是本系列中最受读者期待的初创公司，更是众多团队在构建自己产品时选择的项目管理工具。而且他们的工作方式独树一帜： Linear 在银行的现金比他们的过往风投融资还要多。他们已连续盈利超过两年（这在之前很少见），而且公司自成立以来，在付费营销上只花了3.
全文语音
Linear团队的故事是我一直以来就想分享的。他们不仅是本系列中最受读者期待的初创公司，更是众多团队在构建自己产品时选择的项目管理工具。而且他们的工作方式独树一帜：
Linear 在银行的现金比他们的过往风投融资还要多。他们已连续盈利超过两年（这在之前很少见），而且公司自成立以来，在付费营销上只花了3.5万美元。公司只有两个人离职过。他们的CEO，Karri Saarinen，是位设计师，他很少对外接受采访。正因为如此，我很高兴能深入分享 Linear 是如何构建产品的。如果你希望了解更多，可以访问 Linear.app，在 X 平台找到 Karri，他们现在正在招聘！
你们详细计划到多久以后，这一情况多年来有何变化？
一开始，只有我们三个创始人的时候，我们按周做计划。我们会考虑最重要最迫切要解决的事情，然后着手解决。如果你翻阅我们初始的更新日志，你可以看到我们每周发布的内容。我们的目标一般是找到那些最阻碍我们吸引更多的用户的因素，并根据测试用户的反馈进行完善。
如今，Linear 大约有 50 名员工。我们只有一个产品团队，这意味着我们的规划过程高度集中，整个产品只有一条路线图。这使得所有人都非常清楚我们在做什么。此外，每个人都对整个产品以及它们如何协同工作负责。
至于做规划过程本身，这是一种双向流程。首先，由创始人和核心领导团队确定公司接下来12个月的大方向。与此同时，我们邀请团队中的每个人在 FigJam 会议上或通过问卷调查分享他们的看法和建议，以深入了解我们可以进一步优化或解决的问题领域。
一旦我们确定了战略，我们会基于此制定下半年的高级路线图。例如，该策略可能是“专注于大公司的需求”。我们没有使用复杂的方法来对项目（需求/功能）进行评级或投票。相反，我们认为，只要领导层和整个团队花费时间与客户沟通并经常使用该产品，需求和机会自然会浮现。接下来只是关于项目的优先级和确定范围。
下面这张图是我们今年第二季度和第三季度的高级产品路线图。我们有两个战略工作流：规划与路径设定，以及问题的发掘。另外两个工作流主要关注高优先级的用户反馈，这样我们能迅速地回应客户的需求，同时还有一些基本维护项目（如下文的“其他”工作流所示）。
在这些工作流中，我们将加入新的特性和功能，并对现有特性进行升级。我们试图为接下来的两个季度做详细规划，为之后的半年做初步规划，并保留一份相当完备的待办事项。对于特定的工作流，其路线图将随着任务拆分为各个项目而变得更加详细。
我们按照我们认为的最佳路径为项目进行优先级排序。“最佳路径”意味着我们看到在Y之前做X的理由，因为他们会相互支持，或者我们想到了团队中的某位特定人员，他们更适合处理某个特定的项目，但不能并线进行。我们希望在可能的情况下将项目与个人优势匹配。例如，当我们知道项目功能需要更高级的前端时，我们会配备技术最好的前端人员。
项目计划从文档或清单开始，我们只是在其中初步写明设想。随后，我们会要求项目团队为该项目撰写详细的需求文档。以下是我们“Triage”功能的一个需求说明示例：
编写后，我们将项目添加到 Linear 的 Roadmap 中。这是我们“规划与路径设定”工作流的内部工作视图，以及团队在构建过程中如何管理他们的工作流程。
你们有多少个 PM？
只有一个。大约一年以前，我们雇佣了Nan Yu，当时我们只有25个人。他是产品负责人，目前是唯一一个拥有“PM”头衔的人。我这样说的原因是，我们还有其他人，这些人也一定程度上扮演了传统意义中属于产品经理的的工作角色。
我们的计划并不是为每个项目或团队都雇用产品经理。我们之所以聘请 Nan，是因为我们认为需要有人来指导和推动构建整个产品。与其为产品的每个团队或项目都指派一个产品经理，我们更希望看到整个团队共同思考产品设计以及如何交付功能，而不仅仅是产品经理。
你们是否使用某种形式的 OKR？
我们没有使用OKRs。在设定目标时，我们更喜欢简单明了，有时会设定更多的战略性目标，如“成为初创公司的首选工具”或“吸引xxx数量的公司”，然后我们根据这些目标来设定路线图。我发现这类目标有助于我们团队统一方向，同时无需对如何实现目标做过于详细的说明。这样做更能鼓励并解放团队。
我们也没有为产品或任何项目设定具体的指标目标，但我们的确有一个作为公司导向的北极星指标目标。对于B2B工具而言，企业在采买这种工具或任何新功能时通常需要一段时间。设定过于具体的指标并密切跟踪它们可能并不那么有效，反而容易导致偏离正确方向。在我看来，产品的真正目标应该是如何为现有客户增加更多价值或触达新的客户群体；也就是说，我们应该更加专注于如何更好地满足客户需求。
对于特定的项目，我们可能会收集某些数据或指标以获取更深入的理解，但这并不是我们的主要决策方法。我们不进行A/B测试。我们更倾向于验证基于品味和看法形成的观点和假设，而不是让测试驱动我们的决策。我们不过于关注具体的参与率或其他数据。我们会进行beta测试，收集反馈，然后进行迭代。当我们确信某个修改或功能已经达到最佳状态时，我们会发布它，观察其在大规模应用中的表现。
你是如何组建团队的？是基于产品、用户类型、用户旅程、预期结果，还是某种中间方式？随着时间的推移，这种方法有所变化吗？
我们只设有移动（Mobile）和基础设施(Infrastructure)这两个专业团队，因为这两个领域需要专门的技能和高度专注。产品团队的其他成员负责处理规划中产生的项目，这些项目涵盖了产品的各个方面。我们刻意避免了针对特定产品模块的团队架构（如“路线图”产品团队或“周期”产品团队等），因为在我看来，这可能会让人们过于专注于自己的特定产品领域，从而忽视了更大的背景，或开始在细节上雕花，而收益却越来越少。当然，有些人可能对某些问题或领域更为熟悉，他们可能会多次处理与该领域相关的问题，但这并不是一个固定的角色。
我们的产品团队是按照地区（美国和欧洲）进行划分的。很早我们就意识到，跨时区远程团队合作是颇具挑战的，因此我们决定让欧洲和美国的成员各自组成独立的团队运行。此外，我们还有营销、数据、销售、客户成功、技术支持以及人力团队，他们都与产品团队保持紧密的协作。
在进行路线图规划时，我们会在美国和欧洲的团队之间分工。在这些团队内部，每个项目都会配备一位项目负责人和其他团队成员。项目负责人可以是工程师、设计师或项目组的任何其他成员。鉴于我们除了产品负责人外没有设定任何产品经理职位，所以项目负责人从不扮演传统的产品经理角色。项目负责人的主要职责是启动并跟踪项目的进展。通常情况下，对于我们构建的几乎所有功能，我们都会组建一个由一名设计师和两名工程师组成的小型团队。按照我们目前的规模，大约有六个这样的项目团队在并行运转。一旦团队完成了自己的项目，他们就会解散并转到另一个项目。
在进行规划时，我们可能会围绕某类客户、领域或我们希望开发的功能类型设置主题，但我们不会据此设置固定的组织结构。
你们的产品/设计评审会如何运转？
我们的目标是让每个项目团队都对其项目拥有完整的所有权，因为我们坚信，当团队对自己的工作负有全部责任时，他们能为用户带来更好的解决方案。
我与我的联合创始人Jori Lallo和Tuomas Artman以及我们的产品负责人紧密合作。每个人都会领导或参与项目的各项会议，作为项目的支持者，根据实际情况提供反馈和指导。我们团队中的某个成员最终会对项目成果承担责任。比如，我们有一个专门致力于新用户的入职体验的项目团队，其中Jori会负责领导该项目和相关的团队会议，并针对项目团队在Slack上异步分享的更新提供反馈。
我们没有进行正式的产品或设计评审。我们的流程更偏向于灵活和迭代，使我们能够更迅速地推进。比如，我们的设计师会在与项目相关的Slack群组中分享初步的设计，这样可以从多个人那里得到非正式的异步反馈。
从一开始，我们就构建了一个强大的功能开关系统，因此我们会尽快把新功能推入内部测试，有时仅仅是项目开始后的几天或几周。在此阶段，每个人都可以尝试这个新功能，检查是否存在问题，或者分享关于如何改进的建议。得益于这些功能开关，我们没有理由延迟产品上线。
我们有一个名为“Linear Origins”的Beta客户测试计划，允许我们的客户更早地体验新功能，并为我们提供早期反馈。有时，这可能在我们准备正式发布功能的前一到两个月进行，而有时则可能在几天前。例如，当我们正在开发一个重要的新功能版本时，我们会与部分客户进行沟通，引导他们体验产品。对于那些愿意试用的客户，我们会为他们开启新功能，并收集他们的反馈，尽最大努力进行优化。尽管我们会针对某些产品这样做，但我们并不总是认为将功能推送到Beta版本是发布的必备步骤。我们始终重视迅速发布，这意味着并非所有功能都会经过Beta测试，但当我们觉得额外的反馈有助于产品改进时，我们会采用这种方式。
6. 产品和设计是同一组织的一部分吗？PM最终向谁报告？这些年来，这种情况发生了变化吗？
是的，产品、开发和设计都是产品团队的重要组成部分。产品和设计直接向我（首席执行官）汇报。我们有开发负责人，但最终开发部门的汇报是由我的联合创始人负责：Tuomas主管基础设施和欧洲的开发团队，而Jori负责美国的开发团队。尽管开发和设计有各自的功能会议，但在大部分时间里，我们都是从整体角度出发，讨论“产品”，而不是单独针对开发、设计或产品进行讨论。这种组织结构从创立之初就一直保持至今。
7. 你用于任务管理和Bug跟踪的主要工具是什么
嗯，当然是Linear。我们最近分享了一篇关于如何使用 Linear 来管理用户的 bug 反馈和功能需求的博客文章。
简单来说，对于 bug 跟踪，我们主要依赖我们的“分类”功能，它就像团队的收件箱。我们的支持团队、销售团队，甚至我自己也会经常将问题提交到“分类”中，然后我们的“守门员”工程师会将这些请求转发给合适的人员或当场修复它。这里的“守门员”是每周轮换的角色，工程师在此期间帮助支持团队处理问题、修复错误，并对新的请求进行分类处理。
大多数的任务通常都属于某个项目的一部分。工程师和设计师为自己创建任务，并在项目进行过程中处理这些任务。项目团队使用我们的项目更新功能每周跟踪并报告项目的进展。这些更新也同步发布到 Slack 的 #product 更新频道，以便所有人都可以实时关注。
你创造的产品是当今市场上最受欢迎且最成功的产品之一。你认为产品策略中哪些独特或核心的方面，促使了这一产品的巨大成功？
Linear 的一个独特之处在于，我们希望项目团队成为 PM。
在其他公司，我经常看到PM成为或逐渐转变为团队事实上的决策者。在这种模式下，好像所有的创意和想法都是由 PM 提供的，而团队中的其他成员——例如工程师和设计师——仅仅是执行这些想法的执行者。我认为这种方式未能充分利用团队的机会和才能。
我觉得对某些团队来说，这种方式是可行的，但我更看好那种团队既能思考又能执行的项目模式。我喜欢以苹果如何在其M1芯片中集成CPU、GPU、RAM和其他功能为例，使其运行更加高效。
我认为如果没有这样的安排，我们不可能实现如此高的产品质量或创造出我们现有的一些特性。任何参与过创造过程的人都会明白，当你真正开始构建某样东西的时候，会涌现出诸多的创意和可能性。
例如，我们团队中的工程师Andreas创建的上下文菜单就是一个很好的例子。我们并没有特定要求或为它设定明确的规格，但他弄清楚了如何确保用户鼠标悬停时上下文菜单不因移动几个像素而关闭。他认为这是有必要的。这种细微之处很难通过需求文档或计划来描述，特别是你不真正的创造它，或者如果你感觉对它没有所有权。
我个人认为，这也是为什么我们现在看到的很多软件在理论上看起来完美无缺，但在实际应用中却不尽人意的原因之一。作为一个行业，我们过度强调了流程优化，进而建立了一个类似亨利·福特生产线的产品工厂，每个角色都高度专化，大家更看重生产效率而非产品的工艺和质量。（A/B测试也是另一个原因）。
值得注意的是，这种方法存在局限性。这要求工程师和设计师同时扮演PM的角色，包括与用户和其他利益相关者进行沟通与对话。这意味着工程师和设计师的工作不再局限于纯编码或设计，这有时会给人一种感觉，好像这种做法会拖慢进度。然而，就我而言，我认为有时适当放缓速度会带来更佳的效果，这也意味着我们通常能够在首次尝试时完成项目，并在后续进行最小的修正。另一个挑战是，要找到适合这种角色的人才是很困难的，因为很多人缺乏这种工作经验。
我认为招聘优秀的团队成员对于你的成功起到了关键的作用。在你的产品团队招聘中，你最为重视的是什么（可能与众不同）？能大致描述一下你的面试流程吗？
无论是开发还是设计，只要是与产品相关的职位，我们都非常重视员工对产品的感觉、品味和判断力。当然，对于那些非产品类的职位，我们不仅仅看他们具备的基本技能。就像在市场营销这一块，我们非常看重一个人讲故事的能力。而在运营层面，我们更希望他们能深入理解并洞察用户的真正需求。
总的来说，我们要打造的公司不仅仅是一个工作的地方。在这里，每个人都不应该局限于自己的岗位职责，而是要主动关心他人，发掘自己更大的潜能，带领大家一起前进。
我们的招聘流程针对不同的职位有所差异，但还是有一些普遍的面试环节，包括与招聘团队的初试、与管理层的面试、技能评估，以及一些深度或‘跨界’的面试。事实上，对于众多的工程师候选人，我个人都会对他们进行‘产品思维’的面试。
在这里，所谓的‘产品思维’或‘品味’，实际上是指这个人对于某个产品或功能的深入理解和独到见解。比如说，如果一个候选人之前在Airbnb有过经验，我可能会询问他对于Airbnb的某个产品或功能的看法，以及背后的原因。而这些观点不仅仅是基于个人的喜好，更重要的是，他们需要能够给出具体的分析和解释。
最后一个环节是‘实际工作体验’。这是一段时间的带薪试用，期间，候选人会参与一个与他们应聘岗位相关的实际项目，与我们的团队紧密合作，并最终呈现他们的工作成果。在这个过程中，他们可以无障碍地访问我们的各种资源，包括文档、代码库、设计稿和沟通工具，甚至参与一些关键的团队和公司会议。例如，我们可能会为工程师提供一个具体的技术任务，或者为领导岗位的候选人布置一个管理挑战。
这个‘实际工作体验’对于我们和应聘者双方都极为有益。我们可以直观地看到候选人如何面对和解决实际问题、如何应对挑战和与团队成员沟通。同时，候选人也可以更加深入地了解 Linear 以及他们未来要入职团队的工作环境和氛围。”
在你的产品团队或整个公司中，有哪些有趣或特殊的习惯和传统？
- 没有产品经理，只有一个产品负责人。产品经理的职责被均匀分配给开发和设计团队。
- 没有固定的跨职能团队。团队会为了一个项目而组建，一旦项目完成，他们便会解散。
- 没有基于数据指标的目标。他们只设定了一个公司层面的“北极星”指标。
- 没有 A/B 测试。决策更多地基于直觉和观点。
- 求职者要经过带薪试用期。他们将与团队一同工作1-5天，并参与真实的项目。
- 整个团队都是远程工作。 从始至终都是这样。
任何产品，都不可能完美无缺。在 Linear，我
们每一周都在努力修复这些小问题和疏漏。但是，我们还在每年年底设定了一个特殊的“打磨季”，在这个时间，我们会集中精力彻底解决这些问题。最重要的是，我们倾听用户的声音，让他们告诉我们哪里需要改进，哪里可以为他们的生活增添更多便利。每次我们进行了改进或修复，都会第一时间告知给予我们反馈的用户，并在我们的公开页面上做出更新。以下就是我们在2022年的“打磨季”的成果：
FAQ
1. 关于「你创造的产品是当今市场上最受欢迎且最成功的产品之一。你认为产」，核心要点是什么？
Linear 的一个独特之处在于，我们希望项目团队成为 PM。
2. 关于「我认为招聘优秀的团队成员对于你的成功起到了关键的作用。在你的」，核心要点是什么？
无论是开发还是设计，只要是与产品相关的职位，我们都非常重视员工对产品的感觉、品味和判断力。当然，对于那些非产品类的职位，我们不仅仅看他们具备的基本技能。就像在市场营销这一块，我们非
3. 关于「在你的产品团队或整个公司中，有哪些有趣或特殊的习惯和传统？」，核心要点是什么？
任何产品，都不可能完美无缺。在 Linear，我们每一周都在努力修复这些小问题和疏漏。但是，我们还在每年年底设定了一个特殊的“打磨季”，在这个时间，我们会集中精力彻底解决这些问题。
评论(0)