Linear打造令人喜爱的B2B产品的秘密

嘉宾：Nonan（努南）｜ Linear产品负责人｜领域：B2B SaaS产品设计

背景与引子

在B2B企业软件领域，产品的口碑往往两极分化严重——要么被用户吐槽“难用、慢、笨重”，要么干脆被遗忘在角落。然而有一个产品，却让无数人爱不释手，甚至在“没有IT部门批准”的理想条件下，最多人想要切换过去的工具，竟然是从Jira换到Linear。

Linear是什么？它是近年来增长最快的项目管理和团队协作工具之一，以其极致的速度、优雅的设计和让人“用起来心情愉悦”的体验，俘获了大量工程师和产品经理的心。在Lenny Rachitsky的播客访谈中，Linear产品负责人Nonan深度分享了这家公司的产品方法论——从如何处理速度与质量的矛盾，到如何做产品决策、如何做用户研究，以及如何在求职中脱颖而出。这不仅是一篇关于工具优化的文章，更是一套关于如何打造真正令人喜爱的B2B产品的思考框架。

一、嘉宾是谁

Nonan现任Linear产品负责人，曾先后在Everlane（时尚电商）、Mode（数据分析工具）等公司负责产品工作。这一路走来，他积累了一个重要的认知：越是竞争激烈的行业，越需要在别人看不到的角度寻找突破口。 而Linear正是这种思路的极致产物——项目管理工具早已是红海，但Linear用惊人的速度、极简的体验和对细节的执着，硬生生撕开了一道口子。

他在访谈中展现出的几个特质值得注意：其一，他极其擅长在用户访谈中“深挖”，直到找到用户真正感到糟糕的那个瞬间；其二，他对于产品决策有一套系统化的方法论，从不凭直觉拍脑袋；其三，他对团队协作模式有独到的见解，构建了一套“Double Triangle”的跨职能协作机制。这些共同构成了Linear独特的产品文化。

二、核心观点TOP10

速度和高质量并不矛盾——人们常把“速度”等同于“敷衍潦草”，但真正的高手反而是最快的，因为他们早已把能力内化为本能。
用10%的时间验证核心假设——给一个功能分配一个月的时间，在第一周结束前就应有一个可运行的版本，能测试关键假设。
先让内部用户验证，再逐步扩大beta测试圈——从内部团队到早期用户群，一层层放大，确保数据不被污染。
对中层管理者的定制需求坚决说“不”——任何以牺牲一线员工体验为代价来满足管理层报告需求的功能，一概不做。
找到“IC视角”与“管理者视角”之间激励错配的地方——在这些节点做决策时，要格外审慎，尽量找到双赢解。
听到功能请求时，要追溯到具体的人——不是“很多用户要这个功能”，而是“Bob从某公司有这个具体的工作流”，用真人锚定决策。
用户告诉你的不一定是他们真正需要的——他们会说“我要自定义字段”，但真正的问题可能是“我需要追踪客户请求”。要挖到那个情绪痛点。
在开发前，先构建极端版本——先把最安全的方案和最快的方案都做出来，感受两个极端，再找到真正的平衡点。
用“感觉有多糟糕”来衡量优先级——不只是问“目标是什么”，而是要感受用户在当前流程中哪里“感觉不好”。
把PM视为连接“建造侧”与“销售侧”的桥梁——产品经理不仅要懂工程和设计，还要深度参与营销和销售信息的提炼。

三、关键洞察

1. 产品速度的秘诀不是压缩时间，而是从第一天就开始验证。

大多数团队的开发流程是：研究 → 设计 → 开发 → 测试 → 上线。等开发到80%，才发现方向错了。这种延迟验证是致命的。

Nonan提出的解法是：当你给一个功能分配了一个月时间，那么在第一周结束前，就必须有一个能用的东西。这个东西不需要精美，只需要足够验证核心假设。它的目的是让你知道：“我们方向是对的，还是有一个完全错误的假设？”如果错了，尽早止损；如果对了，后续有充足时间迭代和打磨。

Patrick Collison（Stripe CEO）的一条推文精准地概括了这一点：“好的、便宜的、快的——这个三选一的格言是狡猾的假情报。实际上，缓慢和昂贵通常是一对孪生兄弟。”当你被迫慢慢做的时候，成本也在叠加。

2. 识别激励错配，是防止产品臃肿的关键。

Linear收到的功能请求中，有一类他们会坚决拒绝：来自中层管理者、以牺牲一线员工日常体验为代价、用来让报告更好看的定制功能。

Nonan举了一个很具体的例子：有人会说“我需要自定义字段来追踪这个信息”。但问题是，一线工程师根本不知道那个字段的含义，每次填都要花五分钟搜索。他们要么随便选一个填，要么直接忽略。数据变得不可信，报告也毫无价值。而Linear的做法是：直接问清楚这些人真正想解决什么问题（往往是“追踪客户请求”），然后用更优雅的原生方案来解决——比如自动关联CRM、邮件来源分析——让工程师无需任何额外操作，就能实现同样的目的。

这个原则的核心是：不能为了让管理层“感觉更好”而牺牲实际干活的人的体验。这不是一个商业决策，而是一个价值观声明。

3. 找到用户“感觉糟糕”的那个瞬间，而不是他们“要求”的那个解决方案。

Nonan在用户访谈中有一个独特的技巧：他不是问“你想要什么功能”，而是让自己“跟用户一样感到糟糕”。

他说：“我通常会听销售人员问问题，然后AE在旁边看，心里想’你到底在干什么，为什么要问这种角度刁钻的问题？‘但我的目标是：我要像用户一样感到难过。他们来找我，说’我想要X’，但X背后一定有某种动机——某件让他们感到不舒服的事。”

他举了一个很生动的例子：有人抱怨“周一的报告很烦人，要收集很多数据”。追问之后发现，问题不是报告本身，而是因为营销团队和销售团队永远无法在截止日期上达成一致——有人把发布日期设成12月30日，销售团队抓狂，因为所有人都在休假。解决方案不是更好的报告模板，而是让日期可以更灵活——可以设成“Q4项目”或“2024下半年”，不需要给出具体日期。这种设计彻底消除了那个“糟糕感”。

Paul Graham称这种现象为“schlep blindness”（苦差盲目）——人们每天在痛苦中工作，却意识不到这是可以改进的机会。好的产品团队需要有人从外部视角，帮助用户看到这些盲点。

4. 测试极端版本，是找到正确解法的最快路径。

Linear在设计“草稿保存”功能时，用了一种非常有趣的方法：他们不是先讨论一个折中方案，而是先做了两个极端版本。

版本A（最快速方案）：保存草稿后直接关闭，不弹任何确认框。工程师不需要做任何操作，流程最快。但实际体验时，感觉非常不安全——用户会担心自己没保存成功。

版本B（最安全方案）：每输入一个字就自动保存。这样确实安全了，但问题是：用户创建了大量根本没有完成的内容——“未命名文档”堆积成山，造成视觉噪音。

最终他们找到了两者的平衡：如果是新创建的内容，关闭时弹框确认；如果是已经存在的草稿再次编辑，就自动保存。这个方案本身并不直观——如果不是先测试了这两个极端，根本想不到会有这种特殊处理方式。

Nonan的方法论是：先探索可能性空间的边界，而不是一上来就做折中。找到极端之后，你才能真正理解问题的全貌，然后找到那个最优雅的解法。

四、精彩金句

“速度和质量之间没有真正的权衡。当你想到’速度’时，你过度关注的是仓促和潦草。你应该关注的是能力本身。”

解读：真正的高手不是在“更短时间内做完”，而是他本身就具备极高的专业度，所以产出既快又好。Linear的团队就是由这样的人组成的。

“我想让自己跟用户一样感到糟糕。”

解读：产品经理最大的能力不是分析数据，而是真正代入用户的处境，感受他们的痛苦。只有真正理解那种糟糕，才能做出直击痛点的产品。

“好的、便宜的、快的——三选一，这是缓慢者散布的狡猾假情报。在我的经验里，缓慢和昂贵往往是一起的。”

解读：这是Stripe创始人Patrick Collison的观点。Low-quality + slow + expensive是真正的恶性循环。

“你在采用一个工具的时候，不只是解决一个问题——你同时也在买入一种工作方式。”

解读：选择一套软件，就是选择一套默认的工作哲学。如果软件的默认值不是适合你的，那就是在强制你的团队用一种别扭的方式工作。

五、实战案例

案例：客户请求功能的设计

Linear最近推出的“客户请求”（Customer Requests）功能，背后就是一个典型的Nonan式问题解决过程。

他们收到大量请求：“我需要自定义字段，因为我要追踪每个客户的需求。”Linear团队没有直接去设计自定义字段系统——那样会让界面变得臃肿。相反，他们深入问了40%的用户，发现他们真正想要的是：在工程任务和具体客户之间建立关联，以便在季度复盘时能看到“我们为这个客户做了什么”。

他们意识到，问题的本质不是“字段”，而是“语境”。于是Linear设计了一套方案：自动对接用户的CRM和客服工具，邮件中的客户提及自动关联到对应项目。工程师在工作时，任务卡片上就直接显示“沃尔玛需要这个功能”，附带原始邮件。他们不需要手动添加任何信息，还能自动生成客户维度的报告。

结果：IC（工程师）的工作体验完全没有变差，反而因为获得了上下文而更有信心；管理层的报告需求也得到了更好满足。这不是妥协，是找到了一个双赢的解法。

六、行动建议

建议1：从第一天起就验证核心假设

为什么要做：推迟验证意味着你在用最多时间去验证最不确定的方向。越晚发现问题，修改成本越高。

如何开始：当你开始一个功能开发时，在项目计划表上明确写出“第一周结束前需要验证的核心假设是什么”。可以是“这个交互方式用户能理解吗”，也可以是“我们解决的是真正的痛点吗”。不要等到demo day才验证。

能得到什么结果：如果你发现方向错了，可以在只投入了10%时间的时候转向，避免浪费80%的时间在一个错误的方向上。

建议2：当听到功能请求时，追问三个层级

为什么要做：用户说的往往是解法，而不是问题本身。如果直接按照他们说的做，你可能会制造一个功能来解决一个根本不存在的问题。

如何开始：层级1：“你想要X功能，具体要解决什么问题？”层级2：“这件事让你感觉有多糟糕？”层级3：“如果你完全没有这个问题，你现在会做什么？”通过这三个层级，挖到真正的痛点。

能得到什么结果：你的产品团队会越来越擅长做正确的事，而不是做被要求的事。

建议3：每季度至少做一次“极端版本”设计练习

为什么要做：好的解决方案往往不在你以为的选项里，它藏在你没有探索的角落里。极限定向思维能帮你扩大搜索空间。

如何开始：在下一个重要功能设计时，先明确这个问题最重要的单一维度（比如“快vs安全”“简单vs强大”“精准vs灵活”），然后分别设计该维度上的极端解法。用Figma草图、代码原型都可以，不需要完美。体验完两个极端之后，再找平衡点。

能得到什么结果：你会发现很多原本想不到的解法，而且这些解法的边界会更加清晰——你知道哪些维度是你愿意牺牲的，哪些是必须坚守的。

建议4：每季度和用户做一次“感受糟糕”对话

为什么要做：用户不会主动告诉你“我在这里感到糟糕”，他们会说“有没有XX功能”。你需要主动去找那些情绪锚点。

如何开始：选取3-5个活跃用户进行深度访谈，核心问题不是“你需要什么”，而是“这个工具里，哪个地方让你最烦躁？你上一次感到’我真的很讨厌用这个’是什么时候？”认真倾听，记录那个瞬间。

能得到什么结果：你会发现产品路线图之外的真实痛点——那些才是真正值得投入的方向。

建议5：把PM定位为“建造侧”和“销售侧”的连接点

为什么要做：大多数产品团队只关注与工程、设计的协作（Triple Triangle），忽略了与销售、营销的信息联动。而B2B产品的成功，恰恰取决于能否用客户的语言说话。

如何开始：产品经理参与每一次重大发布的内容策划——写change log、构思release note、参与campaign文案。用你与客户深度沟通的经验，帮助营销团队提炼出“客户的原生语言”。同时，在销售跟进中收集反馈，验证你的信息是否真正打动人。

能得到什么结果：你会发现产品团队的影响力大幅提升——不只是输出代码，而是影响市场认知和客户决策。

七、我的总结

Linear的成功，本质上不是“做了一款好产品”，而是构建了一套独特的操作系统——在产品层面，他们用早期验证和极端测试来确保方向正确；在决策层面，他们对中层管理者的定制需求说不，对一线员工的工作体验坚持保护；在文化层面，他们把PM定位为连接建造者和销售者的桥梁，让产品信息和用户语言保持高度一致。

Nonan在访谈中反复强调一个核心思路：做产品不是满足用户告诉你的需求，而是解决用户没有意识到的痛苦。 这需要同理心，需要深度挖掘，需要勇气对错误的请求说不，更需要一套系统化的方法来确保你始终在正确的方向上快速前进。

如果你也希望做出一个让人“哪怕不被允许切换也心心念念的产品”，Linear的方法论值得认真研究——不是学他们的界面设计，而是学他们思考问题的方式。

📺 播客信息

发布时间：2025-01-30
时长：1小时21分钟8秒
播放量：42991 次观看
原版视频：『YouTube』