Linear 打造备受喜爱的 B2B 产品的秘密

摘要

本期播客邀请 Linear 产品负责人 Nan Yu，深入拆解 Linear 如何在竞争激烈的项目管理工具赛道中脱颖而出，成为最受用户喜爱的 B2B SaaS 产品之一。Nan Yu 首先颠覆了"速度与质量不可兼得"的常见认知，主张真正的专业能力意味着既快又好——关键在于在前 10% 的时间预算内产出可验证的工作原型。随后他阐述了 Linear 拒绝功能膨胀的核心原则：绝不为了中层管理者的报表需求而牺牲个体贡献者（IC）的工作流体验。在用户洞察方面，Nan Yu 提出了独特的方法论——他追求的不是"五个为什么"式的逻辑追问，而是与客户产生共情，感受他们工作中的情绪低谷，以此驱动产品创新。他还分享了 Linear 系统化的创意方法：先构建某个维度的极端版本，再探索对立极端，最终找到两者的精妙平衡，草稿自动保存功能便是此方法的经典案例。此外，他强调 B2B 软件不仅是工具，更是在传递一种工作方式；产品经理应作为"双三角"的核心，连接构建侧与销售侧。最后，Nan Yu 就求职策略和截止日期管理提出了极具操作性的建议。

正文

速度与质量：颠覆"二选一"的迷思

在产品开发领域，"好、快、省——三者选其二"几乎被视为公理。Nan Yu 却认为这是一种危险的误解。他指出，当人们谈论速度时，往往将"快"等同于"仓促"或"粗糙"，而真正应该关注的指标是"专业能力"（Competence）。观察任何领域的顶尖从业者——无论是厨师、程序员还是建筑师——你会发现，他们的产出质量越高，工作速度反而越快。这不是因为他们偷工减料，而是因为这些技能对他们而言已是第二本能。

在软件开发中，迭代次数直接决定了最终产品的质量。唯一能够完成大量迭代、尝试不同方案、感受不同变体的方式就是快速推进。Stripe 创始人 Patrick Collison 在同一天发推表达了完全一致的观点："'好、便宜、快——选两个'这句格言是缓慢者散布的阴险谎言。根据我的经验，缓慢和昂贵通常相伴而生。"Nan Yu 用装修房屋的例子加以佐证：如果工程拖延不决，业主不仅要长期住酒店，账单还在不断累积。

尽早发布：10% 时间法则

那么，"又快又好"在实际操作中是什么样的？Nan Yu 给出了一个精确的量化框架：假设你为某项功能设定了一个粗略的时间预算，那么在仅过去 10% 的时候，你就应该拥有一个可以运行的工作方案。不是在项目进行到一半时才有了一个"也许可以试试的候选方案"，而是在第一周结束时，就有了一个能够验证关键假设的可用产品。只有这样，你才能判断方向是否正确，还是存在根本性的错误假设。如果等到 80% 才做出判断，那就太晚了——你只能推迟截止日期，让市场团队陷入困境。

实现这一目标需要多方面条件：首先，拥有优秀的人才至关重要——工程师不应被每一个细小的设计选择阻碍，他们愿意先做出一个可用的方案，即便自己对那个方案并不完全满意。其次，团队需要在意图层面达成共识：第一版不需要完美，它是我们对正确方向的最佳猜测。有时第一版出乎意料地好，稍作调整即可发布；但没有任何人需要追求完美主义、把所有细节打磨到极致——它只需要能够工作、能够验证或否定主要假设。

Lenny 分享了他在 Lenny's Podcast 订阅者中开展的"你的技术栈里有什么"调查结果：当被问及"如果你的 IT 部门允许，你最想切换到哪个工具"时，排名第一的答案远超其他——人们想从 Jira 切换到 Linear。用户评价 Linear"使用起来是一种享受"、"简单却强大"、"设计是行业标杆，而性能和速度更是巨大的生产力提升"。

拒绝功能膨胀：守护 IC 的体验

面对"Linear 终究会变成臃肿的企业软件"这一常见质疑，Nan Yu 的回答清晰而坚决。这个问题在面试中频繁出现——候选人总是问："你们如何避免重蹈覆辙？"Nan Yu 将功能请求分为两类：可以辩论的，以及必须拒绝的。必须拒绝的那类，恰恰就是导致软件臃肿、让个体贡献者（IC）痛苦不堪的元凶——为中层管理者提供更便捷的报表功能，却以牺牲 IC 的工作流为代价。

这类功能请求有一个非常具体的模式：中层管理者需要更多可定制的字段、更多下拉菜单、更多必填项，目的是让报表更"完整"。然而，工程师的绩效考核基于代码贡献，而非是否正确填写了所有工单。他们要么完全不配合，要么敷衍了事，在九个选项的下拉菜单里随机选择第一个。报表数据因此毫无准确性可言——用这种数据做决策，后果可想而知。

Nan Yu 强调，这是 Linear 的核心承诺之一：绝不在此类需求上做丝毫妥协。对产品经理而言，说"是"太容易了——他们面对的是采购决策者，销售团队在施压，对方承诺"只要加这个功能我们就买"。但 Linear 需要说服客户，这是一个虚假的权衡：一旦开始侵蚀 IC 的体验，他们就会脱离参与，所有报表数据都会变得不可靠。

客户需求的优先级排序

对于大客户的需求，Nan Yu 采取了一种务实策略：客户通常带着一份清单而来——十项需求。但当你问他们"这十项对你同样重要吗"，答案往往是否定的。真正重要的只有前三项。Linear 的任务是以前三项远超竞品的方式解决它们——如果前三项通过原生功能而非可定制字段来交付，质量深度将远非竞品可比。而剩下的七项，可以协商。

在企业市场拓展方面，Linear 的增长态势良好，企业版增速甚至领先其他版本。Nan Yu 认为这触及了一个临界点：软件采购决策很大程度上是一种品牌认知——"这是适合我们的吗？"许多企业选择所谓"企业软件"，尽管所有人都不喜欢用它，但"这是给我们用的"。Linear 已经在大型企业中建立了足够的品牌渗透率，让决策者能够感受到"Linear 适合我们——我们是一家希望像初创公司一样行动的大公司"。

情感驱动：感受用户的痛苦

Nan Yu 在用户访谈中有一套独特的方法论。他的目标不是简单地执行"五个为什么"（5 Whys）的逻辑追问，而是要"用客户感受痛苦的方式去感受痛苦"。客户提出需求时，背后总有某种驱动力——你可以用分析框架拆解"你的目标是什么""作为某个角色你想达成什么结果"，但你可能错过他们真正感到痛苦的根源。

Nan Yu 的方法是进行足够长、足够深入的对话，与客户建立起信任和共鸣。随着你越来越多地从他们的视角看问题，他们也越愿意向你敞开心扉。例如，一位客户讲述了自己的经历：他在项目上标注了 12 月 30 日的交付日期（因为这是一个 Q4 项目，他想把日期放在最末尾），结果市场团队炸了锅——"12 月 30 日大家都放假了，怎么可能发货！"这位客户说，"这让我感觉糟透了，我再也不想在任何事情上标注日期了。"理解了这个情绪之后，Nan Yu 就能设计出解决方案——在 Linear 中，你可以在项目上指定任意粒度的目标日期：可以说这是一个"12 月的项目""Q4 的项目"或"2024 年下半年的项目"——无论你愿意承诺多大的精确度，都可以标注，而不必给出虚假的精确度从而导致一连串的沟通失误。

Nan Yu 指出，在竞争极其激烈的行业（他在 Everlane 做过 DTC 服装，在 Mode 做过 BI 工具，现在又在项目管理赛道），那些浅层的目标导向方法早已被各家公司反复挖掘。你必须从别人未曾审视的角度出发——那就是工作日中的情感体验。他认为这个角度之所以未被充分开发，是因为产品经理和工程师都是偏理性思维的人，倾向于回避情感层面。Paul Graham 将这种现象称为"苦差盲目"（Schlep Blindness）——人们深陷于日常的不便之中，却对此浑然不觉。你需要一个局外人来观察他们全天、全周的情感节律，标记出那些可以大幅改善的时刻。

Linear 的分流管理（Triage Management）功能正是基于这一方法论诞生的。Nan Yu 发现了两种截然不同的痛苦感受：一些人手动执行分流，每天在大量工单之间搬运、路由，感觉"完全被淹没了"；另一些人则放弃了管理，工单"越墙抛过来"，完全失控，提交者也不知道自己的工单会怎样。两类人的痛苦根源相同：缺乏自动化、有组织的分流队列。分流管理功能由此而生。

从具体的人出发

在功能决策的讨论中，Nan Yu 坚持一个原则：每个功能请求都必须追溯到具体的真实用户，而非假想的"Alice"或"Bob"。当讨论是否扩展一个现有功能或新增一项服务时，关键问题是：究竟谁会用它？现实中的真实用例是什么？他要求"这里有名字、有姓氏、有邮箱——你可以去问他们"。

Nan Yu 警告产品经理容易掉入的陷阱：做出一个美观优雅的方案，却忘了检验"现实是否也同样美观优雅"。现实有时是丑陋的——如果你的方案与现实不匹配，无论它多么漂亮，都不会有长期生命力。

至于需要听到多少次反馈才值得投入，Nan Yu 区分了两种情况。第一种是"认知修正"——发布一个功能后收到反馈，发现某方面的假设错了。这不是数量问题，而是"我们想对了还是想错了"的问题。他将此过程称为"跪压"（Kneeling）——一个东西形状不太对，放到真实场景中就能发现哪里不匹配，一两份反馈就足以揭示。第二种是面对大量用户请求某个大功能时，需要深入挖掘：虽然表面上是同一类需求，但实际用例可能有 100 种变体。此时应当寻找用例最集中的方向，把它做深做透，而非试图覆盖长尾。

客户请求（Customer Requests）功能的诞生就是一个经典案例。Linear 反复收到"完全可定制字段"的需求，但增加 100 个自定义字段只会让 IC 苦不堪言。Nan Yu 深入追问"你到底想用自定义字段做什么"，发现 40% 的需求本质上是因为"我有一个客户"——比如沃尔玛提出了一个功能需求，需要所有人知道这一点，需要追踪它，需要汇报过去一年为沃尔玛做了什么。用户原本打算手动打标签（就像在电子表格里做的那样），而 Linear 的方案是与客服工具和 CRM 集成，自动从邮件中提取反馈，将功能升级自动关联到请求方——无需 IC 做任何额外操作，所有信息自动呈现，工程师在构建功能时可以直接看到真实的用例和原始邮件。

创新方法论：推向极端再折中

Nan Yu 有一套系统化的创意方法。当人们谈论创造力时，面临的困难往往是无法外推——眼前的东西看得见，但两三步之后呢？可能性太多，不知该往哪个方向走。他的方法是：沿某个维度，把方案推向最极端。

这类似于 Brian Chesky 在 Airbnb 提出的"11 星体验"——不是问"什么方案可行"，而是问"这个维度的最极端版本是什么"。在这个过程中，你需要抛弃成本、可行性等一切约束，目的是探索可能性空间。Nan Yu 强调，产品决策中最大的风险不是在已有选项中选错了，而是根本没有看到正确的选项——它藏在某个你没有审视的角落。

以草稿保存功能为例。Linear 作为一个以速度为核心承诺的产品，团队首先构建了"最快速"的极端版本：保存草稿时直接保存，丢弃草稿时点 X 直接丢弃，不弹出任何确认对话框。这个版本确实极快，但团队立刻感受到了它的代价——极度不安全。关掉一个窗口，内容可能就没了。

于是团队转向了对立的极端——"最安全"的版本：自动保存一切。你开始创建一个新议题，输入第一个字符就开始自动保存。这个版本确实让人感到安全，但带来了另一个问题：大量"未命名文档"的纸屑痕迹——你每次点"新建"，系统就开始保存，而你可能根本不是认真的。

经过两个极端的亲身体验，团队找到了平衡方案：创建全新议题时关闭窗口会弹出确认（因为你可能还没来得及保存），但编辑已有草稿时则完全自动保存（因为不会创建新对象，只是就地修改）。这个看似微妙的区分，正是通过走极端、感受极端、再在极端之间寻找交点才得出的。Nan Yu 总结道："最好的解决方案总是在事后看来显而易见——但你需要一个过程才能走到那里。"

B2B 软件传递的是工作方式

Nan Yu 提出了一个常被忽视的洞察：采用一款 B2B 软件不仅仅是采用其功能，更是在采用它所承载的工作方式。许多 B2B 产品的起源都是某位大公司员工实现了某种高效流程，于是将其工具化，推广给同事，最终独立为创业公司——这个过程重复了成千上万次。所以当你采用一款营销工具时，你不仅获得了"发送邮件"的能力，还同时采纳了组织营销活动、衡量点击率、计算获客成本等一系列实践——无论你此前是否了解这些最佳实践，工具的默认设置就是你组织能达到的最低能力基线。

最鲜明的例子是 ERP 产品的实施——这是一场深度手术，企业不得不重塑所有内部流程和资源管理方式。他们愿意承受这种痛苦，因为这是经过实战检验的资源管理最佳实践。正如 Lenny 所指出的，这解释了 Linear 为何如此坚持避免过度定制——Linear 有一套关于高效产品团队应当如何运作的主张（即 Linear Method），它不只是提供工具，更是在传递一种工作哲学。

Nan Yu 进一步澄清了"有主见"（Opinionated）的含义。有些人认为"有主见"只是主观偏好，你的观点和我的观点没有对错之分。但 Linear 做的是找到高绩效团队之间真正的共识实践，然后将其自动化——对于已经在手动执行这些实践的公司，提供一键自动化；对于尚未意识到自己需要这些实践的公司，提供一个按钮来激活它。

双三角协作：产品经理的新定位

Nan Yu 分享了 Linear 独特的内部协作模式。他提出，产品管理不仅是一个构建侧的职能，同样也是一个走向市场（Go-to-Market）的职能。传统的"工程-产品-设计"铁三角固然重要，但产品管理、销售和营销之间的协作同样关键，却常被忽视。在很多组织中，产品团队与销售、市场团队之间甚至存在对立。

在 Linear，PM 团队中有一位全职的产品营销人员，她的职责包括撰写所有更新日志和发布说明，以及为即将发布的功能打磨语言。她直接与构建团队合作，确定如何谈论产品。当营销团队随后制作宣传物料时，核心语言已经就绪。而销售团队则在前线验证这些信息——他们对客户说出这些话，反馈哪些表达有效、哪些无效，形成三个职能之间的良性反馈循环。

Nan Yu 将这种模式称为"双三角"（Double Triangle）：产品经理居于中心，一侧连接工程和产品设计（构建侧），另一侧连接销售和营销（销售侧）。PM 的职责是将构建侧的可能性和机会，与销售侧的商业动机和目标对接，确保产品构建真正服务于商业目标。Nan Yu 认为，如果 B2B 领域的 PM 们在影响力上有所遗漏，那最可能遗漏的就是销售侧——他们很可能已经在与工程和设计的协作上做得不错，但在走向市场一侧还有巨大的提升空间。

他给出的具体建议是：PM 应该参与发起面向受众的核心信息。营销有许多 PM 未必会触及的工作（如需求生成、渠道策略等），但在选择用词和强调重点上，PM 由于深入的客户发现和需求调研，对客户的原生语言有着最深刻的理解——帮助营销团队写出最地道的措辞，这是 PM 能够产生显著增量的领域。

求职策略：做问题的解决方案

Nan Yu 在求职方面有着独到的方法论。产品管理是一个独特的角色——因为涉及面极广，你不会被人沿单一维度与他人比较。而每位招聘经理都希望新人来解决某个亟待解决的问题。因此，求职者的核心任务是用做产品发现的方法找出招聘经理的"待办任务"（Job to Be Done）：他们到底在为什么问题而焦虑？

一旦你识别出这个问题，并证明你就是解决它的人选，那么雇佣你就变成了一个二元选择：雇佣问题的解决方案，还是雇佣另一个人？相比之下，大多数求职者只是在展示自己各方面都很好、没什么弱点——但每个人都在这样说，你只是众多候选人中的一员。

Nan Yu 在应聘 Mode 时就实践了这一方法。一位朋友给他的建议是"假装你已经在那工作了——你会做什么？"按照这个思路，当面试官问"你有什么问题吗"时，你可以直接问"你这个季度的 OKR 是什么？某人怎样帮助你实现这些目标？"这种具体到季度目标层级的提问，远比泛泛地问"公司的目标是什么"更有价值——它让面试变成了一次真实的协作模拟。

Nan Yu 还建议，在面试流程中，不要犹豫去要求与更多相关人交流。如果你认为某个工程经理的工作与你要解决的问题直接相关，可以说"能否安排我与负责同一问题的工程经理聊聊？"没有其他候选人会提出这样的要求——而这个工程经理在面试复盘时的一句"这个人问的问题很好"，就是你独有的加分项。

关于截止日期的哲学

Nan Yu 对截止日期（Deadline）有着强烈而具体的观点。他观察到，工程师普遍对截止日期感到沮丧——"截止日期完全是编造的"。而让截止日期真正有效的唯一方式，是将其提升到 P0 级别：当截止日期存在时，其他一切都必须让位。工程师不能被拉去做别的事，PM 的职责是尽可能削减范围（Scope），确保在需要做出"发布还是不发布"决定的时刻，手里有一个可以发布的真实产品——它可能不是你最初设想的那款产品，但它是一个功能完整、可以正常使用的产品。

Nan Yu 主张"不要有太多截止日期，但一旦有了，就必须当真"。截止日期通常与外部营销活动相关——而与客户的沟通机会是有限的：一年 365 天，12 个月，约 50 周，4 个季度。每一次你本应传递信息却错过了的窗口，都不可逆转。你无法穿越回去重新发布 Q1 的消息。

有趣的是，在如何达成截止日期的问题上，Nan Yu 给出了一个反直觉的回答：Linear 几乎不做估算。他们的策略是尽早发布——在前 10% 的时间预算内就产出可用版本，然后用剩余时间决定是继续迭代还是打磨至可发布状态。这为未来的自己创造了决策空间。你不可能在最后一刻才开始认真对待截止日期——必须从第一天就贯彻"快速推进、早期迭代"的过程，把自己放到能够对产品说"发布"或"不发布"的位置上。

闪电问答

推荐最多的书：《设计心理学》（The Design of Everyday Things，Don Norman 著）。Nan Yu 在大学的人机交互（HCI）课上首次读到这本书，它让他从此以产品的视角看待身边一切——每一支铅笔、每一扇门都是某人设计的产品。他分享了一个亲身经历：在社区咖啡馆看到一个小孩把门把手拽了下来——那是一扇推门，却装了一个看起来可以拉的把手——这正是书中的经典案例。

最近喜欢的影视作品：Netflix 的《外交官》（The Diplomat），轻松有趣的剧集，有《白宫风云》（The West Wing）的氛围。

最近发现的好产品：Sakura Micron 针管笔。这款日本产绘画笔本为漫画家设计，Nan Yu 用来写日记。他在亚马逊上发现了一个标注为"圣经学习套装"（Bible Study Kit）的官方包装版本——因为这款笔不洇墨，非常适合圣经那种薄纸页。同一款产品，通过重新定位目标受众和关键词，打开了全新的市场。

人生座右铭："正确的量 = 过量减一"（The correct amount is too much minus one）。这与"先试极端再折中"的方法论一脉相承——想知道吃几片披萨合适？先吃到觉得多了，减一片就是正解。有时你必须先走到边缘，才知道边界在哪里。

Everlane 的爆款故事：Nan Yu 在 Everlane 工作期间，见证了一款畅销女士 T 恤的诞生。一批男式 T 恤出了生产事故——全部短了一英寸半，根本没法卖。为了挽救库存和现金流，设计和营销团队联手将衣服再裁短两英寸，作为"女士短款箱型 T 恤"（Box-Cut Tee）推出。原本只是止损之举，结果一周内售罄——这款产品至今仍在销售，已扩展到 20 种颜色。Nan Yu 感叹，产品市场契合（Product-Market Fit）有时以最意想不到的方式出现——很难说清这是设计的功劳还是营销的功劳，但当团队聚在一起，以正确的方式解决正确的问题，奇迹就会发生。