Linear 打造备受喜爱的 B2B 产品的秘诀 | Nan Yu（产品负责人）
Linear 打造备受喜爱的 B2B 产品的秘诀 | Nan Yu（产品负责人）
速度与质量并非对立
Lenny Rachitsky： 我认为你在 Linear 团队身上看到了很多人看不到的一点——速度和质量之间其实并不存在取舍关系。
Nan Yu： 人们谈论这个问题时，仿佛它就是一种取舍，因为当他们想到速度时，过度关注的是匆忙行事或敷衍了事。他们真正应该关注的是足够专业胜任。如果你看看那些站在各自技艺巅峰的人，你基本上可以根据他们的速度判断出他们的工作成果会有多好。
Lenny Rachitsky： 当你说可以既快又高质量地完成时，这种速度具体是什么样的？
Nan Yu： 具体来说，你会对某件事大概需要多长时间有一个粗略的时间预算。当 10% 的时间过去之后，也就是第一周结束时，你已经有一个能跑起来的东西，可以内部验证某种关键假设。
如何避免软件臃肿
Lenny Rachitsky： 我想象你们会受到一种批评——随着时间推移，你们大概也会变成一个臃肿的软件。
Nan Yu： 当我们审视这个问题时，我们会看”哪些功能需求是可以讨论的，哪些是必须绝对拒绝的？“那些我们必须绝对拒绝的，恰恰就是导致软件臃肿、让 IC（Individual Contributor，个人贡献者）们痛苦不堪的东西。
深挖客户真实感受
Lenny Rachitsky： 你们销售负责人跟我分享过，他对你在客户电话上提问的方式印象深刻——你不停地追问、追问，直到挖出真正有价值的东西。
Nan Yu： 我的目标是用和客户同样的方式感受到痛苦。
嘉宾介绍
Lenny Rachitsky： 今天的嘉宾是 Nan Yu。Nan 是 Linear 的产品负责人。Linear 是当今最受喜爱、设计最精美，同时也是增长最快的 B2B SaaS 产品之一。你很少能看到人们对任何一款企业级 B2B SaaS 产品表现出如此程度的喜爱，而 Linear 却享有这样的待遇。所以，Linear 的运营方式和产品打造方式有太多值得我们学习的地方。在与 Nan 的对话中，他分享了他用来激发创意、为客户问题寻找非显而易见解决方案的一套方法；为什么当 PM 告诉他速度和质量之间存在取舍时，他觉得这是一个危险信号；他如何与客户对话，先找出客户想要避免的情绪，再找到避免那种情绪的解决方案；以及一些关于如何求职的绝佳建议，包括他如何获得在 Linear 的工作以及此前在 Mode 的职位，还有更多内容。
如果你想打造一家像 Linear 一样备受喜爱的公司或产品，这期节目会给你大量具体的策略，改变你和团队的工作方式。如果你喜欢这档播客，别忘了在你最喜欢的播客应用或 YouTube 上订阅关注。这是避免错过精彩节目的最佳方式，也对播客帮助极大。好了，下面有请 Nan Yu。
Linear 的用户为何如此热爱它
Lenny Rachitsky： Nan，非常感谢你来参加节目，欢迎来到播客。
Nan Yu： 谢谢邀请。我是长期以来的听众和读者，所以能来这里真的很荣幸。
Lenny Rachitsky： 我想先跟你分享一件事，一件我还没跟你、也没跟任何人分享过的事。这期播客播出时，这些结果可能已经公开了。我现在正在运行一个调查，我把它叫作”你的技术栈里有什么？“。我让所有订阅者回答：你日常最常使用哪些工具？你最喜爱哪些工具？你最讨厌哪些工具？其中一个问题是，如果你的 IT 部门允许，你最想切换到什么工具？排名第一的答案远远甩开其他选项——人们想从 Jira 切换到 Linear。
Nan Yu： 哇。我是说，希望这意味着我们做得还不错。
Lenny Rachitsky： 我觉得这正是它所意味着的。我读几条评论，让你感受一下人们在怎么说 Linear。我猜这些对你来说并不意外，但这能让大家了解为什么邀请你来，以及为什么我迫不及待想从你身上尽可能多地汲取智慧。几条评论是这样的：“Linear 用起来令人愉悦，在与工程团队协作时，我从它的设计中获得了灵感。""Linear 简单易用，却功能强大。""Linear 的设计显然是行业标杆，但更重要的是，它的性能和速度带来了巨大的生产力提升。”
Nan Yu： 听到这些真的很高兴，因为在很多方面，这正是我们想做的事情。回想 Linear 创立的初衷，是因为 Karri 曾在 Coinbase 和 Airbnb 这些地方工作，看着周围所有人都在使用手头可用的工具——都是些既有工具——艰难挣扎，眼睁睁看着这些工具让人们对自己的日常工作多了几分厌恶。而我们所有人当初之所以投身技术、设计和工程这些领域，都是因为觉得它有趣。我们都从搭建那些傻乎乎的 MySpace 页面开始，年轻时做各种各样的小项目，最初都是觉得好玩，然后感慨”哇，我们居然能把这个当作职业”。结果所有这些东西在我们日常工作中设下了一个个巨大的减速带，真的令人难过。所以这就是我们创立 Linear 的原因——打破所有这些障碍。
速度与质量并非此消彼长
Lenny Rachitsky： 我之所以喜欢 Linear，是因为我觉得它是一个令人振奋的商业范例。很多人想说”我要做一个比别人好得多的版本”，但往往这并不奏效。往往没有人在乎到愿意为之买单的程度，有各种障碍和理由。人们不会仅仅因为某个东西更好就切换过去，而 Linear 则是打造出色产品并真正取得成功的绝佳案例。这其中可能远不止是做一个优秀产品那么简单。所以这正是我迫不及待想要深入挖掘、了解你们如何运作的原因。而且从这些反馈来看，对我而言这就是产品市场契合度的终极标志——尤其在 B2B 企业软件领域，人们竟然会因为用不了一个产品而感到难过。我们开始吧。
Lenny Rachitsky： 我想聊的第一个问题是，我觉得你和 Linear 团队看到了很多人没看到的一点：速度和质量之间实际上并不存在权衡。很多人认为这是一个不证自明的事实，而我听你谈到过这其实并不成立。我恰好看到 Patrick Collison 也发了一条推文，说的正是这个观点，我稍后会读一下。不过先想听听你的想法——关于速度和质量之间也许并不存在这种权衡，你有什么心得？
Nan Yu： 人们谈论这个问题时，几乎以一种天真的方式假设存在权衡，因为当他们想到速度时，他们过度关注的是赶工或粗制滥造，而他们真正应该关注的是能力的精通与专业程度。如果你观察那些站在各自领域巅峰的人，不管是厨师、程序员还是建造房屋的人，你基本上可以通过他们的工作速度来判断产出的质量。如果他们动作非常快，而且显然不是在敷衍了事、留下一地鸡毛，那你会觉得”没错，他们能达到这个水平是因为这一切对他们来说已经如同第二本能”，他们能够以极快的节奏推进、尝试各种东西。而我们在构建软件时，产品最终好不好，很大一部分取决于你能完成多少次迭代。所以，想要进行大量迭代、尝试不同方案、真正摸索各种变体的唯一途径，就是以非常快的速度推进。
速度的具体表现
Lenny Rachitsky： 关于速度，这里的速度是指每次迭代都能快速推进吗？当你说”可以既快又好地完成”时，速度具体是什么样的？
Nan Yu： 速度……具体来说就是，你对某件事大概需要多长时间有一个粗略的时间预算，而当 10% 的时间过去时，你就已经有了一个可用的方案。不是说”哦，到一半的时候我们才有一个也许可以试一试的候选方案”。不是这样的。第一周结束后，你就应该有一个能运行的东西，能测试某个关键假设，从而让你判断这个东西是否真的在按照预期发展，还是我们的某个假设完全错了。你不想等到完成了 80% 才来做这种判断，因为那就太晚了。到那时你只能推迟截止日期，让市场团队非常难过。
Lenny Rachitsky： 很好。所以你的思路是，“我们要在这个功能上花一个月。在前几天，基本上第一周之内，我们就要拿出一个可用的东西，可以开始让潜在用户甚至在内部进行测试”？
Nan Yu： 对，是的。
Lenny Rachitsky： 那你们是怎么做到的呢？因为大多数团队做不到这一点。大多数团队需要调研、设计、构建，然后”好的，我们终于有东西了”，一个月就这么过去了。是什么让你们能够做到这样？
Nan Yu： 这其中有很多因素。我觉得拥有真正优秀的人才确实很有帮助。拥有那些不会被每一个细微的设计选择卡住的工程师，他们乐于先做出一个能用的东西。即使他们对某个具体方案不太满意，他们也会直接推进，把事情搞定。另一部分是心态。我们从不期望第一版就是完美的，那根本不在考虑范围内。第一版只是我们对最终想要交付的方向做出的最佳猜测。有时候结果不错，“哇，这第一版已经相当好了，做些小调整就可以上了”。但并不对此抱有期望。所以没有人觉得自己必须做一个完美主义者，把所有细节都打磨得光光滑滑、完美无缺。它只需要能运行、能完成任务、能验证或推翻我们的主要假设就够了。
“好、便宜、快——选两个”是谎言
Lenny Rachitsky： 我来读一下 Patrick Collison 的这段话。他在我准备这次访谈的今天发了这条推文。他是 Stripe 的 CEO 和创始人，如果你不太熟悉的话。他的推文是：“我越来越确信，‘好、便宜、快——选两个’这句格言是那些行动缓慢的人散布的恶意误导。根据我的经验，慢和贵往往如影随形。”
Nan Yu： 没错。用装修承包商的例子来说，如果有人在对房子进行改造，而且拖了很久，一方面你还得住酒店，另一方面账单也在不断累加。
Lenny Rachitsky： 你之前和我聊这个话题时还用了象棋选手的例子。我想到了 Magnus Carlsen，除了常规棋之外，他在快棋赛中也是排名第一。这恰好是这个观点的一个绝佳缩影。
Nan Yu： 是的，Magnus、Hikaru 以及那些处于顶尖水平的棋手都是如此，他们的速度可以快到令人难以置信。事实上，这也是通常的做法——我不想在象棋方面说得太超出自己的知识范围——但通常让比赛变得公平的方式是，给这些顶尖棋手比实力稍弱的选手少得多的时间，而他们依然会赢下大部分对局。
如何开始提速
Lenny Rachitsky： 那么，也许为了给这个话题做个收尾，给听众一些可以实际操作的建议——如果他们想在保持质量的同时开始加快速度，你觉得他们可以做什么？有什么是他们可以着手尝试并改进自己工作方式的？
Nan Yu： 我觉得这更多是一种态度和视角的转变——去理解并接受一个近乎可控的风险：第一版不会是完美的。这实际上在很多方面反而降低了成本。这意味着你不需要像素级完美的设计，也不需要确保所有微小的 UI 缺陷都已解决，因为这些都不重要。重要的是你有一份可以交互的可运行的软件，你可以感受它是否顺手，是否真正解决了用户面临的核心问题。你可以把它拿回给用户，甚至可以让他们加入早期 beta 之类的方式获取真实的验证。核心是专注于获得最小的、可交付的单元——这里的”可交付”不是指”能上线到生产环境”，而是指”我可以从这里开始学习了”。
Lenny Rachitsky： 我猜很多人心里都有一个疑问：你们拿这个第一版——不是丑陋，而是尚未完善的初版——怎么处理？是在内部使用来看看效果？还是有 beta 设计合作伙伴？
Nan Yu： 我们有一个逐步扩大的用户圈子，每个功能都会经过这些不同圈子的用户使用。所以等到正式发布（GA）的时候，它已经被很多不同的用户使用过了。第一个圈子就是内部用户。我们每天都在用 Linear 来写软件、做自己的工作，所以我们有这种天然的优势。然后当我们觉得质量足够好了，就会把它放到一些 beta 客户群体中，而且会尽可能早地在流程中引入。我们要确保不会损坏用户的数据，界面也不会难看得受不了之类的，但只要达到了那个质量水准，我们就可以发布给早期体验客户，让他们给我们好的反馈，也尝试用它来解决自己的问题。如果没有人参与使用，那就是一个很好的信号，说明我们没有真正命中目标。然后我们会有几个不同的 beta 用户群体逐步扩大，最终的发布当然是 GA，所有人都能用。
Lenny Rachitsky： 这个回答太棒了。好的，所以 Linear 成功的第一个秘诀——我来记一下笔记——就是尽早把新功能、新产品想法交给用户，比如说在你分配的时间的前 10% 就拿出来，然后逐步向越来越多的人发布来获取反馈。我觉得这里的隐含意思是，大部分被浪费的时间都花在了构建那些最终没有人真正想要或使用的东西上。所以越早获得方向感——你是不是在朝一个好的方向走——整个过程就越快，对吗？
Nan Yu： 对，完全同意。
应对”臃肿化”质疑
Lenny Rachitsky： 我想象你们会收到一种批评。人们会说：“是的，Linear 很棒，很漂亮，比过去几十年的东西好太多了，但随着时间推移，你们也会变成一款臃肿的软件。这就是企业软件的命运。你们得勾选所有的复选框。IT 团队需要所有这些功能。“所以总是会有这种说法：“哦，是的，当然，你们现在可以这样运作。你们现在有一款了不起的产品，但它终将变得又丑又臃肿。“你们怎么思考避免这个问题？我知道这是你们花了很多时间思考的事情。也许可以让我们窥见一下，当有功能需求出现时——比如”我需要这个东西的单点登录”或者”这里需要加一个按钮”——你们内部的对话是怎样的？你们如何决定加什么、不加什么，以及怎么加这些功能才能不让它变得臃肿？
Nan Yu： 这个问题其实我们面试候选人的时候经常被问到。当你说”你有什么问题想问我们吗？“的时候，这就是我们会收到的问题。所以我们听到的次数非常多，而且他们问这个问题非常合理，因为他们看到历史上到处都是试图在这个领域竞争却没有成功的初创公司的”尸体”。我觉得当我们审视这个问题的时候，我们会看：“什么样的功能需求我们可以讨论，什么样的功能需求我们必须坚决说不？“而我们必须坚决说不的那些东西，恰恰就是导致臃肿、让 IC 痛苦不堪的罪魁祸首。而且非常具体——就是中层管理者为了让自己做汇报稍微方便一点而提出的定制化功能需求，代价是让 IC 的工作流变得更糟糕。
如果符合这个描述，我们就直接说”不”。没有什么好讨论的，因为我们已经想过了，这是我们不能迈出哪怕一步的路。所以我认为，说实话，这是 Linear 的核心承诺之一：我们不会做这种交易。所以当你看到人们说”哇，Linear 快了好多，太好用了，让我的工作变得愉快多了”——这就是原因，因为我们在这个方向上一步都没有迈出去。一个 PM 很容易对这种需求说好，因为他们通常在和采购方交谈。在任何 B2B 类型的领域里，他们都在和把关者打交道，销售在给他们施加压力，他们说：“嘿，我们真的很想要这一个功能，它会让我们的汇报更好看。”
总监看到这个会非常兴奋，我们肯定会因为这个做出采购决定。而我们必须要说服他们，这是一个错误的权衡。整个前提就是错的，因为一旦你开始走这条路，让 IC 的用户体验变差，他们就会脱离。没有人必须得这么做。如果我是一个工程师，我拿工资是来写代码的。我的绩效考核基于我的代码贡献，不是基于”我有没有把所有工单填对”。所以我就不会去做那部分，或者我会非常随意地做，然后专注于我真正的工作。
然后你所有的汇报都是错的，因为所有数据都是错的，而且是稀疏的。你会遇到这种情况——人们会说：“这里有个下拉字段，是某人加的，而且是必填的。有九个选项，我不知道它们分别是什么意思，所以我就随便选一个。我就选第一个吧。同时我会祈祷我老板不是真的在用这个数据做任何汇报。“这就有后果了，因为数据不可能是正确的。所以我觉得对我们来说，当涉及这类特定的功能需求时，这是一个非常容易做的决定。
Lenny Rachitsky： 我喜欢这个回答的简单和清晰。基本上你们有一个原则：我们会优先考虑 IC 而不是中层管理者。尤其是——我喜欢这跟汇报有关这一点。几乎总是听起来像”我想追踪进展”。
Nan Yu： 对，就是这样。永远是”我想追踪进展”。那你想追踪什么？“我想根据某个字段信息来追踪这个东西关联的是产品的哪个版本。“好的，那做这个工作的人怎么才能知道这个信息？那每次都要花五分钟像寻宝一样。我觉得他们不会去做的。
拒绝短期交易的长期信念
Lenny Rachitsky： 我想象会发生的是——我认为这对大多数公司来说很难做到——这意味着你们在拒绝交易。你们不加那个能签下百万美元大单的功能，这非常难做到。我猜想这很大程度上是因为……我猜 COO 非常认同这一点，有一种”我们将在长期赢得胜利，守住这条底线”的共识。是这样吗？
Nan Yu： 是这样的，但我同时也觉得，做这类事情的压力并不像你想象的那么大。有一些基础性的扩展工作，比如我们得做 SAML 和 SCIM 之类的东西。这些就像”好的，我们当然会做这些维持运转的基础工作”，但当涉及到与应用价值主张的实际业务逻辑相关的工作时，采购方关心的是：这能不能让他们的团队更高效？这才是他们做出采购决定的原因——他们觉得”我们目前的情况……”特别对大公司来说，对吧？“我们目前的情况一团糟”，如果我们能说服他们，正是这类东西才是造成一团糟的原因，那我们就能真正引导他们从一开始就不想要这些东西。
Lenny Rachitsky： 明白了。所以这里有一个要素是——你觉得你需要这个东西，但事实证明你不加这个东西反而会更成功，得到你想要的一切？
Nan Yu： 是的，但问题是，那并不是你想要的一切，对吧？因为人们会带着一长串清单来，清单上有10个想要的东西。你问他们：“这10个东西对你来说同等重要吗？“他们会说：“不，其实不是。“排前三的才是我们真正在意的。如果我们把前三项解决了，剩下的可以再谈。所以我们的工作是，把前三项做到比任何人都好得多——如果他们通过某种可视化编程、自定义之类的方式勉强搞定前三项，那永远也达不到我们通过原生功能所能提供的质量水平和深度。
Lenny Rachitsky： 回想你提到的那份调查，人们如果 IT 部门允许的话最想切换到的工具是 Linear，一方面你可以说，“好吧，IT 因为种种原因不让他们用 Linear。“但另一方面，你们在企业市场的增长非常快——你们是一个新业务，最初从中小企业和初创公司做起，现在一路往上走。所以我觉得不能说这在企业市场行不通，它显然运作得很好。我不知道你有没有什么数据可以分享，但看起来势头很好，在不断向上拓展市场。
企业市场的品牌渗透
Nan Yu： 是的，增长一直不错。企业市场的增长甚至领先于其他细分市场，因为我觉得今年，尤其是我们到达了一个临界点——对于软件来说，很多采购决策几乎是一种品牌认知，比如：“这个适合我们吗？“很多时候人们会选择”企业级软件”，你问为什么，他们说”大家都不想用这个”，他们说”是的，但它是给我们用的。”
Lenny Rachitsky： 买微软的东西不会被开除，诸如此类。
Nan Yu： 对，没错。我觉得我们开始在企业中建立了足够的品牌认知度，让人们可以产生那种感觉了。他们会说：“Linear 是给我们用的。我们是谁？我们是一家想像初创公司一样行动的大公司。“这就等于在说——“谁不想这样呢？谁不想跑得更快呢？”
Lenny Rachitsky： 是的。我之前请 Jeffrey Moore 上过播客，这正是跨越鸿沟的样子。他谈到，基本上你需要的是一个已经跨过鸿沟的后来采用者，而不是那种”我热爱新事物、我是早期采用者布道师”的人。你需要的是一个传统的、老派的、花时间才开始采用的人，这样大家才会觉得：“哦，好吧，也许我真的应该认真对待它了。”
Nan Yu： 我也觉得，对于这类工具，以及很多其他 B2B 软件，“不”的意思是”不是现在”，对吧？不是现在——因为预算不合适，因为变革管理的时机不对，“哦，我们有位高管特别执着于另一个工具”。但这些情况会变的，对吧？所以我们和他们保持联系，他们在我们的 CRM 里，我们会跟进。我们有很多这种情况——两年前被拒绝过，现在我们有了新功能，再去跟他们说：“哦，看起来你们已经到了我们这个规模了”，诸如此类。
复杂的产品辩论
Lenny Rachitsky： 你提到当这些辩论和问题出现时，有些功能是大公司想要的。有一类是”我们知道不会为中层管理者去建报告和自定义功能，让他们只是追踪发生了什么”，而另一类是 IC 想要提高效率、取得成功所需的功能。能不能给我们讲讲一些更复杂的辩论，不属于那个类别的？
Nan Yu： 我觉得复杂的辩论往往是：当我们确实要添加一个新的原生功能时，是扩展现有功能让它更强大，还是添加一个全新的服务？这里面很大一部分工作是搞清楚到底谁会用它，我们了解的实际真实用例是什么？比如我知道 X 公司的 Bob 有这样一个工作流，这个功能对他来说是这样运作的。还有哪些不同的变体场景也适用。所以把一切追溯到真实的人身上是——
Lenny Rachitsky： 比如一个具体的人？
Nan Yu： 对，具体的人。没错。不是假设的人。不是你编造出来的 Alice、Bob 之类的。而是——“不，这是他的名字、姓氏，这是他的邮箱，你可以直接问他。“我觉得能够这样把一切追溯到现实，是我们思考和讨论这些事情的一个重要方式。
Lenny Rachitsky： 这跟我做 newsletter 的思路很像——我总是尝试回答一个非常具体的、真实的人提出的问题，而不是一个笼统的”人们可能感兴趣”的东西。那个非常具体的问题，它暗示了有需求——不是暗示，它证明了至少有一个人需要这个东西，而不是你凭空想象某个可能想要这个东西的人。
产品决策的方法论
Nan Yu： 是的。我觉得 PM 们常常会掉进一个陷阱——他们会做一个东西，在里面做一些选择，也许是因为它很美、很优雅，但他们没有走完那一步去验证：“现实也同样美而优雅吗？“因为现实有时候是很丑陋的。如果你有一个优美优雅的解决方案，但它和现实不匹配，那就没什么意义了。人们可以看着它啧啧称奇，但如果他们不用它来完成工作，它永远不会有长期的持久力。
Lenny Rachitsky： 你有没有一个经验法则——你大概需要听到多少次才会确信”这值得投入”？人们听到这里可能会说：“哦，一个 Bob，Bob 想要这个功能。“这不合理吧，就一个人。你怎么判断什么时候是”好的，我们真的该投入这个了”？
Nan Yu： 一部分情况是你听到了什么，然后觉得：“天哪，这确实……”不仅是对的，而且意味着我们之前对此的思考方式有点问题。我把这个过程叫做——我不知道这样描述对不对——“打磨”：你有一个东西，它的形状不太对，你把它放到真实环境中去。这种情况通常发生在一个功能生命周期的早期。你发布了一个东西，然后开始收到反馈，说它和现实不太匹配，然后你问自己：“我们有没有测试过那个方面？我们有没有真正把那部分和现实对齐过？“如果没有，那就是那种你其实不需要太多反馈就能发现问题的部分。这不是一个数量问题，而是”我们想对了还是想错了”的问题。这是一类情况。
另一类情况是，你收到一个对某个很大功能或功能集的需求，来自很多不同的人，但你深挖进去，试着问：“好吧，跟我说说你想怎么用这个”，结果发现有100个不同的用例。所以你有选择：要么构建那个覆盖所有长尾用例的大功能，要么尝试看看这里面有没有真正集中的、高密度的用例，值得作为一等功能来采纳。所以我觉得这是我们最常采用的两种策略：一是”我们是不是想错了，现在正在学习它如何与现实匹配”；二是”对于人们要求的这个大的通用功能，是否其实有更具体的用例是我们应该去解决的，而且应该解决得非常好”。
Lenny Rachitsky： 到目前为止，这些例子中有一条贯穿始终的线索——就是找到具体使用这个功能的那个真实的人，让他们满意，确认这个需求确实能解决他们的实际问题。比如在 IC 和中层管理者之间做选择的时候，做法就是”让我们去跟真正提出这个需求的人谈谈”，而不是”大概有100个人在要这个东西，那我们来建一个通用解决方案”。
Nan Yu： 对。我给你举个例子，把我们说的这些都串起来。我们刚发布了一个叫 Customer Requests 的功能，基本上它在 Linear 中引入了一个新概念——客户。对于 B2B 公司来说，这非常相关。我们做这个功能的原因是我们不断收到完全自定义字段的需求，我们就问：“你们想要自定义字段来做什么？“因为问题在于，你加了100个自定义字段，所有的 IC 都会开始讨厌它。所以我们不想走那条路，但你们到底想实现什么？其中40%的回答是：“嗯，因为我有个客户”，比如 Walmart 之类的，对吧？“Walmart 要了这个功能，这非常重要。我需要所有人都知道 Walmart 需要这个。我需要追踪它。我需要看我们怎么汇报……”
我们可以汇报过去一年我们为 Walmart 做了什么，这样当我的 CSM 和客户代表一对一沟通的时候，他们能有一些证据表明我们一直在为他们做事，诸如此类。我们说：“好的，很酷。“这听起来是你们想做的非常有用、非常强大的事情。你们期望人们怎么给这些东西打标签？回答是，手动打标签，因为他们在电子表格里就是这么做的。我们说：“与其这样，我们要对接你们的客户支持工具，对接你们的 CRM。我们会自动从这些公司导入反馈，分析邮件的来源，然后如果有人请求了一个功能，这个请求被提交到工程团队，它就会自动打上标签，标注是谁提出的。你不需要做任何事情，但你也能知道，也能对这些数据进行汇报，而且这一切不会让 IC 的生活变得更困难。”
事实上，这反而让他们更有信心，因为当他们构建这个东西的时候，他们能真正理解是谁在要求它，以及邮件里具体说了什么。所以当他们在做设计或处理细节的时候，他们能看到真实的用例，并直接针对这些用例来解决。
Lenny Rachitsky： 听到这里我就觉得，“好吧，这看起来是很显然的解决方案。当然，40%的人告诉我他们有客户。“但现实中，大多数时候如果你听到一群客户说”嘿，我需要这个自定义字段”，有时候听到这个，有时候听到那个，大部分情况下你就会去建这个自定义字段。你们的销售负责人跟我说过，他对你在客户电话上提问的方式印象深刻——你会不停地深挖、深挖，直到找到一个对你来说有价值的洞察，然后你才开始尝试为他们解决问题，思考产品应该是什么样的。我觉得这是 PM 非常重要但又被低估的一项技能。你能不能分享一些建议，关于你是怎么做的，怎么提问的，怎么看待这些客户电话的，从而走到”好的，现在我明白我们该建什么了”，而不是”就把他们要的东西建出来”？
深挖情绪动机的提问方法
Nan Yu： 说起来挺有意思，因为从外面看，我在这些销售电话上问问题，AE 或者其他人在旁边看我提问，我觉得他们经常在想：“你在干什么？你从一些我连目标都不知道是什么角度在问问题。“而我的目标是和他们一样感到难受。客户带着需求来找我们，“嘿，我们想要 X”，背后是有动因的。你可以用常规的分析方法，“连续问五个为什么”，试着弄清楚：“好吧，你的目标是什么？""作为一个某某角色，我想达到什么结果。“你可以这样做，但你可能会错过他们真正因为缺少这个东西而感到难受的原因——“我没法完成这个目标。那又怎样？""那我就升不了职。”
好的，太好了。我现在理解了你问题的严重程度。但驱动你告诉我这些的，那个真实的情绪究竟是什么？要走到那一步需要一些时间。你可以直接问别人”你感觉怎么样？“他们不一定会告诉你，但如果你跟他们的对话足够长、足够深入，你开始和他们站在同一层面，开始从他们的视角看问题，而你越多地从他们的视角看，他们也越知道你在这样做，就越愿意对你敞开心扉，告诉你：“好吧，说实话，我遇到了这样一件事——我把这个项目的交付日期标成了12月30日，因为这是一个 Q4 项目，我想把它放在最后，然后我的市场团队就疯了，因为他们说’我们不能在12月30日发布东西，大家都在休假’“，你就……然后他们说：“对，这件事让我感觉非常糟糕。”
所以我不想再给任何东西标注日期了。所以我说：“好的，很酷。我们可以帮你解决这个问题。如果这就是你的感受，那我就可以开始做一些东西来确保你再也不用体验那种糟糕的感觉了。”
Lenny Rachitsky： 人们谈论共情的时候会说，“作为 PM 你需要有共情能力。你需要建立共情，最优秀的产品领导者都具备共情能力。“我觉得你描述的是产品领导者的共情到底是什么样的一种非常精炼而有力的方式——就是我想在听到他们讲的故事时，感受到和他们一样的难受。听起来你的做法就是不断提问，去理解他们因为某件事感到难受的那个瞬间。在这个例子中，就是那个截止日期。
Nan Yu： 而且如果你问上一个故事里那个人，你遇到的是什么样的问题？他们会说：“哦，市场部和我永远对不齐任何事。“这其实没有告诉你到底发生了什么。它告诉你的是，你经历了一次糟糕的沟通时刻，所有信息都错位了，然后你觉得：“这种事只会一次又一次地发生。“所以我们为了解决这个问题做的具体事情是，在 Linear 的项目中，你可以以你想要的任意粒度来指定一个目标日期。你可以说这是一个12月的项目，你可以说这是一个 Q4 的项目，你可以说这是一个2024年下半年的项目。只要是你有把握承诺的范围，你就可以直接标上去。这样你就永远不用给出一种虚假的精确感，从而导致后面一连串的沟通错位。
Lenny Rachitsky： 我能明白为什么人们喜欢 Linear 了——它就是让人们不那么频繁地感到难受。这里面有很多关联。我知道情绪和”感到难受”这个想法是你思考如何构建产品的核心部分，你在寻找人们感到难受的时刻。关于你怎么看待情绪钩子、情绪瞬间，以及如何决定要构建什么，还有什么可以分享的吗？
Nan Yu： 先说一下背景，我一直工作在竞争非常非常激烈的行业里。我在 Everlane 做过，那是一个直接面向消费者的服装品牌。我在 Mode 做过，做的是 BI 工具，市面上的 BI 工具多得不计其数，然后当然就是 Linear，我们做项目管理，项目管理工具也很多。我觉得行业竞争越激烈，那些显而易见的、以目标为导向的东西就越是已经被摘走了，因为这些公司的每一个 PM 都在问，“你的目标是什么？你要完成的工作任务是什么？“诸如此类的问题。所以你必须从一个别人可能没看过的角度去审视事物。对我来说，对我们来说，这个角度就是——在日常工作过程中、在使用我们产品的过程中、在使用竞品的过程中，你在哪里经历了情绪上的钩子？
我觉得这个角度可能是被低估了的，因为……我不知道。我觉得 PM 和工程师，我们都是特别偏理性思维的人，会回避那些情感层面的东西。所以我认为这就是机会所在。你可以去发现，一天当中你在哪些时刻感到难受，而你自己甚至都没有意识到？你可能会想，“我讨厌周一。""为什么讨厌周一？""因为周一我得去收集一大堆东西来写这份报告，真的很烦人。""哦，那如果我给你一个按钮，一键就能生成报告，会不会好一点？""对啊，那我可能就不那么讨厌周一了。“我觉得 Paul Graham 有一个词形容这个现象，叫作 schlep blindness（苦差盲区），对吧？就是我在生活中不断做着各种苦差事，却对此完全视而不见，这确实是真的。你需要一个局外人来观察你一整天、一整周情绪的节奏起伏，然后标记出那些真正可以大幅改善的节点。
具体的情绪钩子案例
Lenny Rachitsky： 有没有具体的例子？我已经分享了几个，但你有没有注意到别人在使用竞品甚至 Linear 时存在这种现象，然后你把它解决了的？我知道你举了日期的那个例子，还有别的吗？
Nan Yu： Linear 有一个用户非常喜欢的功能，叫作 Triage Management（分流管理）。它做的事情是把这样一个流程系统化：如果我向另一个团队提交了一个 issue——不管是请求他们做什么，还是向他们报告一个 bug——这个 issue 会停留在一个专门的区域，通知到正确的人员，这些人员按轮值排班，能够以有条理的方式进行处理。我觉得这种自动化、这个功能，来源于两种不同的糟糕感受。一种是，人们试图手动实现这些流程，需要大量的来回操作，他们确实在做，但感觉”我完全应接不暇”。“为什么应接不暇？""因为我得把所有这些工单丢来丢去，正确地分配路由之类的东西。“他们没有意识到这是一个可以让工具专门来管理分流队列的机会。
因为他们是在手动管理……他们虽然还能应付，但感觉非常糟糕，因为需要投入大量的注意力。然后还有另一类人，他们根本不做这些。他们的感受就是，“完全失控了。别人就是把工单隔墙扔过来，我不知道该怎么处理，不知道它们在哪儿，最后它们散落在各个角落。“而另一边的人则是，“我把工单扔过去了，完全不知道后面会怎样，也不指望有人会回复。“所以人们所有这些糟糕的感受，根源都是同一个——没有一个自动化、有组织的方式来处理分流队列。
Lenny Rachitsky： 营销人员，我知道你们喜欢 TLDR。让我直奔主题。Wix Studio 给你提供了一站式所需的一切，满足任何规模的任何客户。你的工作流可以是这样的：用动态页面和可复用资源轻松扩展内容。借助 Meta、CAPI、Zapier、Google Ads 等内置营销集成快速推进项目。用直观的设计工具在几天而非几周内完成落地页 A/B 测试。连接 Google Analytics 和 Semrush 等追踪分析工具，无需手动设置即可捕获关键业务事件。从统一仪表板管理所有客户的社交媒体和沟通，然后创建、排期并发布跨渠道内容。如果你在做内容密集型网站，Wix Studio 的无代码 CMS 让你无需触碰设计即可构建和管理。当你准备更进一步时，Wix Studio 会随你一起成长——添加自己的代码，用 Wix 提供的 API 创建自定义集成，或利用强大的原生商业解决方案。用 Wix Studio 驱动真正的客户增长。访问 wixstudio.com。 [广告，已跳过]
Linear 成功秘诀的总结
Lenny Rachitsky： 我来试着总结一下 Linear 迄今为止成功的一些秘诀。第一，尽快把东西做出来，比如在你有时间构建这个东西的前 10% 的阶段就把它做出来，先给内部用户用，然后逐步扩大到越来越多的 beta 用户和那些知道自己正在使用早期产品的人。第二，优先关注 IC 和用户，基本上就是优先于买家或那些想要报表和各种自定义功能的中层管理者。所以本质上是聚焦用户，我觉得这个说法你经常听到，但我很喜欢这个非常具体的例子。第三，当你听到功能需求和请求时，要找到那个真正在用这个东西的具体的人，而不是笼统地想，“好的，这个我听过一百遍了。“找到那个真正需要这个东西的人，搞清楚到底怎么回事。然后第四，去寻找人们在使用产品工作时感到难受的那个瞬间。还有什么我遗漏的重要内容，或者你想补充什么细节吗？
Nan Yu： 你说的聚焦用户那部分，我觉得可能比那更微妙一些。有一个细微之处是，要找到用户群体中激励真正错位的地方。有一个中层管理者想要非常详细的报表，而一个 IC 真的非常不想走那么多额外的步骤，他们想要的东西的激励方向就是非常……非常错位的。你需要找到这些情况，并且非常审慎地做出权衡判断，找到能够实现双赢的地方。
用户心智模型
Lenny Rachitsky： 这是一个非常重要的细微之处。你谈话中还反复出现另一点，也让我想起 Patrick Collison 曾经发过的一条推文，一直留在我脑海里，就是关于在脑中建立一个用户心智模型的想法。他的描述方式，以及你描述的方式是这样的——人们常常是，“好，我们来决定做什么。做一堆研究，找用户聊，这些会告诉我们该做什么，然后我们去做。“而你所描述的，以及他所说的，是你做一堆研究，看数据，和人聊，这些会塑造你对客户生活中到底需要什么的心智模型，然后心智模型再指导你做什么。所以每次你做更多研究、找客户聊的时候，都是在修正你对这个人的认知，然后你会想，“哦，这跟我之前想的不一样，“或者，“哇，这跟我们在想的完全吻合，那就做这个。“这方面你还有什么想分享的吗？
Nan Yu： 是的，我可以跟我们管理 backlog 的方式说起，我觉得这其实跟这个话题直接相关。在任何时候，我们大概都有 20 到 30 个可能去探索的机会——纯粹的产品机会，比如可以解决的问题、可以为用户改进的地方——但它们还没准备好。我们对怎么切入还缺乏足够的信心。所以我们就在不断积累对这些东西的理解，周期性地再积累一些新的认知，然后重新评估：“好，基于我们目前的理解，最好的切入方式是什么？“我觉得很多人挣扎的一点是，他们脑子里可能确实有这个模型——比如一个 PM 脑子里有关于用户行为方式的模型——但很难把它分享给别人。你几乎是得用心灵感应把它投射到别人的大脑里，这太难了。所以我们努力做的，一方面是找出我们可以用产品去攻克的领域，另一方面是对每个领域保持一份最新的分析，这样所有人都能参与进来，也能贡献自己的想法。
Lenny Rachitsky： 你们 roadmap 上有没有什么例子？我不知道你能不能分享这类东西——就是那种搁在 backlog 里、“我们还没准备好动手，但已经在关注”的东西？
Nan Yu： 好的，当然可以。资源容量规划（Capacity planning）就是一直搁在我们 backlog 里的一个东西。这是我们看到管理者一直在头疼的问题——我的人员和资源有限，需要以某种方式分配，理论上能完成 roadmap，同时又不会因为某个瓶颈而卡住，不会因为某个工程师卡在某个信息问题上就把所有项目都堵死。这是人们一直在挣扎的事情。目前市面上所有的解决方案都不好用。最好的方案就是某个人做的非常定制化的电子表格，而且维护成本很高。所以我们有一些想法，关于怎么把这个自动化，怎么利用 Linear 里已有的数据来真正帮助解决这个问题，但我认为我们还没有完全破解它。
还有一些细节需要进一步深入探索。所以我们一直在持续开发这方面的理解，当我们听到有用户在为这个问题苦恼的时候，我们会跟他们约个电话，坐下来聊透彻。
Lenny Rachitsky： 这里的思路就是不断充实这个心智模型，不断丰富”这个东西可以是什么”，直到到达一个点：“好，我觉得我们找到了能用一种优雅的方式真正解决这个问题的方案”？
Nan Yu： 对，而且我想强调一个细微之处——我们的目标不是要解决整个问题。整个问题非常大，但其中有一部分是特别适合 Linear 去做的，能帮人们获得一个很好的起点来思考这个问题。所以我认为建立信心这件事，很多时候甚至不是”我们有没有一个可行的方案”，而是”我们到底应该接下这个问题的多大部分”。因为如果我们接得太多，最后就会过度承诺，交付不了。
Lenny Rachitsky： 我觉得这里还有一点很有意思的——你们一直刻意保持团队非常小，这种约束也让你们不会过早地接下这些东西，因为没有那么多工程师和设计师去做。
Nan Yu： 确实，我之前其实没把这一点联系起来想，但我们用这种方式做的原因之一确实是因为我们没有带宽去落地所有东西。所以我们维护这个 backlog，确保当真正动手的时候，我们已经为成功做好了相当充分的准备。
系统化的创造方法
Lenny Rachitsky： 是的，这很有意思。我觉得越来越多的公司开始意识到，用更少的团队可以做出更好的产品、行动更快。我想换个方向，聊聊你们实际上是如何思考打造新产品的。我从你这里听到的一件事是，你们有一套系统化的创造方法，我觉得这是很多人的梦想——“我怎么才能更有创造力？怎么想出新的创新概念？“你有一个非常有趣的流程。能聊聊吗？
Nan Yu： 当然可以。我觉得当人们谈论创造力的时候，很多时候他们的困难在于外推。他们能看到眼前的东西，但两三步之后会怎样呢？然后就变成，“可能性太多了，我不知道该往哪个方向走。“所以我们尝试的方式是问一个问题：“好吧，你能把它推到多极端？你在设计一个产品，你在尝试想出一个解决方案。沿着某个维度，最离谱的版本是什么？“我不知道你们在 Airbnb 有没有做过这个，但我觉得 Brian Chesky 谈到过”什么是 11 星体验？“你们做过这个吗？
Lenny Rachitsky： 这是他说过的一个概念。是的，大家总是在推——“某个想法的 10 倍版本是什么？”
Nan Yu： 当你用这种方式思考的时候，当你在说”什么是 11 星体验？“的时候，你真正在问的是，“什么是这次酒店入住最奢华的版本？或者我们能给人们什么样的最难忘的体验？“你会把成本之类的东西抛掉，把实用性之类的东西抛掉，因为这些不是有趣的点。有趣的是我想要真正探索可能性空间。我觉得这一点非常重要，因为目的就是让你看到你的默认选项之外的东西。我们在各种约束下运作，这些约束在心理层面深植于我们脑海深处，我们甚至意识不到自己有这些约束。所以先突破所有这些约束，然后你才能真正看清你的选择有哪些。因为大家谈论产品决策的时候会说：“哦对，你有这些选择，你要怎么决定？“有各种各样的决策理论。
但最大的风险是你从一开始就没看到正确的选择。你有三个选项，但没一个是正确的。真正的答案在角落里的第四个，但你没往那个角落看，所以从来没发现它。所以我觉得这整个方法的目标，就是尽量扩展你的搜索空间。
Lenny Rachitsky： 所以你的意思是，人们往往因为想得不够激进、不够跳出框框，所以没有充分打开思路。他们做的选择只是一些平庸的选项，而这个流程能帮你突破出去。我觉得有人听到这个可能会说：“行吧，我可以花 10 分钟想’嘿，最疯狂的版本是什么——”
Nan Yu： 对。
Lenny Rachitsky： 但你的意思是，你们真的会这么做，而且效果真的很好？
Nan Yu： 是的，而且你真的会把它建出来。你可以想出一个非常极端的产品版本，然后说：“好，我们先做……”第一个版本，我们刚才说过，你知道它不是真正的正确答案。有时候你知道它太难了，因为这是最极端版本的答案。那就让我们尽快把这个版本建出来，感受一下，然后我们会从中学到很多关于真正正确的答案是什么，因为我们已经看到了产品空间中的这个区域，并且真正体验过了。
Lenny Rachitsky： 太棒了。我们来聊聊一个具体的例子，因为这个方法听起来太棒了。
Nan Yu： 好，我可以讲个例子。其实，我能不能直接 demo 一下？
Lenny Rachitsky： 当然可以，来吧，边展示边说。
Nan Yu： 好，我现在就演示。
Lenny Rachitsky： 好的，我们来共享屏幕。
Nan Yu： 好的。这是一个 Linear 的 demo 空间。我记得很清楚的一个功能，因为做得很近，就是我们做了 issue 草稿保存的功能。Linear 作为 issue 追踪工具，如果我新建一个 issue，比如说我在报告一个 bug，我写了一个 bug 报告，然后就开始想：“好，复现步骤是什么？“然后开始打字，这种情况经常发生。你在工作中做这件事的时候，总有人来打断你。有人在 Slack 上 ping 你，或者你得去开会之类的，你就想：“我得先把这个放一放，待会儿再回来。“心里记着：回头再想清楚真正的复现步骤。
草稿保存的极端版本探索
那你能怎么办？你想把它存为草稿。所以我们说：“好，这就是问题所在。“这个功能的第一个版本，我们想：“我们要做什么？Linear 的核心是快。“所以我们不想挡你的路。我们想的是：“最快的草稿保存体验是什么？“如果你想保存为草稿，就保存为草稿。如果你决定不要了，想扔掉，直接按 X 按钮就行，它会直接丢弃。我们不会弹出一个对话框问你”是否保存更改”之类的任何东西。我们会以最快速度完全让开。那风险是什么？可能会让人觉得很没有安全感。
你关掉这个，我们也不问你”是否保存更改”，你可能会觉得：“糟了，我不小心把内容丢了。“我们一开始就知道这一点，但还是这么做了，结果确实感觉很没有安全感。事实证明我们的那个直觉是对的，我们真真切切地感受到了它有多不安全。然后我们就说：“好，那我们能做的最安全的方式是什么？“最安全的方式就是自动保存所有内容。你新建一个 issue，开始打字，每输入一个字符就自动保存。这确实感觉很安全。很好，但这也留下了一堆你后来改主意的东西的痕迹。你可能在使用文档工具时遇到过这种情况，你的空间里出现一大堆叫”无标题文档”或”新文档”之类的东西，就是——
Lenny Rachitsky： 太多无标题文件夹了。
Nan Yu： 对，太多无标题文件夹了，因为你说”新建文件夹”的那一刻它就开始保存了，但你其实并不想这样。所以我们做了这两个极端版本，最后我们的方案是两者之间的平衡。具体来说是这样的：如果我正在创建一个新 issue，就像现在这样，然后我关掉它，系统会打断我——我们必须打断你，否则感觉太不安全了。我可以保存草稿，然后去我的草稿列表里找。但如果我打开一个已有的草稿，进去继续编辑，说：“好，我继续写，“然后又被打断了，那我就会自动替你保存。没有必要再问了。我不会再问你一遍。
我始终会自动保存，因为我不是在创建一个新对象，而是在原地修改。所以我们做了这样一个非常具体的选择：对于全新的 issue，我们会打断你；对于你正在编辑的已有草稿，我们就自动保存所有内容。如果有人做一个分析，详细拆解这些决策，他们可能会说：“哇，他们在这里做了非常精确的选择。“但到达那个答案的路径是先在一个方向上做到完全极端，再在另一个方向上做到完全极端，然后找到它们真正交汇的地方。
从产品承诺推导极端选项
Lenny Rachitsky： 真是个好例子。你描述的方式是——这是最安全的路线，这是最快的版本。你是怎么想出这些选项列表的？对于那些想在自己公司推行这种方法的人来说，这些是……因为”我们要非常快”是 Linear 的原则。你觉得大多数公司都应该围绕这类属性来运作吗？还是说这取决于什么让他们的产品与众不同？你怎么看这个问题？
Nan Yu： 我觉得对于很多公司来说，你要问的是：“你的产品或你的业务对用户做出的承诺是什么？“可能是在你需要的时候总能有车可用，如果是这样，也许我们就得实施搜索定价来实现这一点。车始终可用。所以这是我们不得不做的取舍。这样做是一个很极端的立场。或者你可以说价格始终是可预测的，但有时候你根本就订不到车。这些都是你可以做的选择，你必须决定，基于你公司的承诺，在这个光谱上的哪个位置是合理的？
Lenny Rachitsky： 很多人谈论”逆向工作”这个理念。Brian Chesky 在 Airbnb 有一个重要的概念就是从理想状态逆向推导。先设计最好的场景，再往回推。我喜欢这个方法的地方在于它更加具体——就是选择某个特定属性的极端版本。这个极端版本可能并不理想，但它会给我们提供关于理想版本的洞察——哪些元素有效，哪些不行。对，我在 Airbnb 的时候其实经常这样做，就是测试极端情况。所以这个想法非常引起我的共鸣。那你说”测试”，是把它做出来然后自己试用？还是会推送给一些用户圈子，还是通常只是内部测试，然后学习迭代？
Nan Yu： 我们把其中一些版本推给了用户。
Lenny Rachitsky： 哦，真的。好的。
Nan Yu： 那个超级快但很不安全的版本，只停留在内部，所有人都觉得太不安全了。然后我们想：“好，那就试超级安全的版本，“然后把它推出了，结果大家开始留下一大堆……”这么多人到底创建了多少草稿？“我就觉得：“太多了。“用户留下了这些疯狂的痕迹。好，我们得想一个不同的方案。
Lenny Rachitsky： 太棒了。所以这和你说的第一点紧密相关——尽快把东西做出来，而在这里就是做极端版本。它们可能不会长期有效，但会教会你很多东西。
Nan Yu： 对，完全正确。
Lenny Rachitsky： 太精彩了。而且看到它在实际中运行的效果，我就觉得：“好，显然这就是正确的方案。“而且这就是它应该给人的感觉。而且正如你所说，当你开始思考这个问题的时候，这个方案并不是显而易见的。
Nan Yu： 是的。我的意思是，最好的解决方案事后看来总是显而易见的，而你需要做的是建立一套内部流程，最终找到通向那里的路径。
B2B 软件不仅是解决问题，更是教人工作
Lenny Rachitsky： 你之前和我们聊天时还提到过一个观点，和我们讨论的一些话题有关——你有一个视角：B2B 软件不仅仅是在解决人们的问题，它同时也在教人们如何工作，是一种信息的积累。你能聊聊这个吗？因为我觉得这一点非常有趣。
Nan Yu： 如果你想想很多 B2B 软件是怎么诞生的——通常是因为某个大公司中间有个人实施了一套流程，然后他发现”哇，这套流程在我们这儿真的很有效，也许我们应该让它更容易使用”，于是内部做了个小工具，所有同事现在只要按几个按钮就能搞定事情。然后他们把这套流程和工具剥离出来， spun off 成一家创业公司。这个过程重复了成千上万次。所以，当你采用那个工具时，你不只是在采用软件本身，你也在接受一个理念：这个实践本身就是你应该做的。如果你是做市场的，采用某个市场营销软件，你不仅仅是在说”好吧，现在我可以写邮件发给别人了”。
围绕这件事有一整套流程：你要把内容组织成 campaigns，要衡量点击率，要计算获客成本——所有这些东西大概率都是跟工具一起来的，因为这些就是做这类市场营销时应该遵循的正确实践。不管你之前是否了解，还是从工具中学到的，作为这类产品的买家，我实际在做的事情是：“我要把这个基础水平的市场营销能力引入我的组织，有了这个工具的默认设置，我们再差也不会差到哪里去。”
Lenny Rachitsky： 有意思。所以你本质上是在说，当你采用一款软件时，你是在接受一种工作方式，而不仅仅是”我有个问题需要解决”。
Nan Yu： 对，没错。我觉得最鲜明的例子是，如果你见过一家公司上 ERP 产品，那是最痛苦的事情你能想象的——等于在做深度手术。他们得重做所有内部流程，重新管理库存等等，但他们愿意承受，因为他们知道这是一套久经考验的方法，能确保你真正做好资源管理。他们会说”我们现在长大了，该采用这些最佳实践了。要做到这一点，我们就得采用这个工具，并且我们会按照这个工具的最佳方式去运转。“
Linear 的理念驱动与”Linear Method”
Lenny Rachitsky： 这跟我了解到的关于 Linear 的几件事有关联。一是你之前提到的，拒绝那些定制化请求。你们有一套非常鲜明的理念——关于如何运营才能打造出运转良好的产品团队、组织和公司。我只是在把线索串联起来：一是我们不让人们过度定制，因为我们知道那样他们的体验会很差；二是我们对你的工作方式有明确的主张，你们有一套叫”Linear Method”的东西，基本上就是说”基于我们见过的所有成功实践，产品团队应该这样运作”。
Nan Yu： 对，确实是有关联的。我觉得有时候人们谈论”opinionated”的时候，感觉上几乎像是在说”嘿，这很随意”，就像你的观点和我的观点，它们就只是观点而已，没有对错之分。我们试图做的是找到那些真正在许多不同高绩效团队之间存在共识的实践，然后把这些实践拿过来说：“好，对于一个还没在践行这套做法的团队，我们能不能给他们一个按钮，让他们开始践行这个？”
当我们看到有些公司在 triage 队列管理上做得非常好，但完全是手动的，我们就会想：“好，能不能把这个自动化？然后对于那些真正需要但还不知道自己需要的公司，能不能就给他们一个按钮激活它？“这样他们的组织里也就有了这个实践。
Lenny Rachitsky： 所以我觉得这里的启示是：当你选择一个工具时，要认识到它会改变你的运作方式，要认真思考”这真的是我们想要的工作方式吗”，而不是仅仅”我们有个问题需要解决”。
Nan Yu： 对，没错。
产品管理即 go-to-market 学科
Lenny Rachitsky： 我想回到一个话题，在我们的聊天中已经出现过几次——你们内部的协作方式。感觉有一种非常独特的模式。你说过你参加了所有的销售电话。关于你们内部如何协作、不同职能之间如何配合，有没有什么是与其他公司做法不同、可能值得别人学习的？
Nan Yu： 有的。有一个对我们非常、非常有效的做法是，我们把产品管理部分地视为一种 go-to-market 学科，就像销售和市场一样。当你问别人”嘿，跟我说说你们公司的产品管理是怎么运作的”，他们大概率会说”嗯，有工程、产品和设计，他们以三人小组的形式协作，这是我们互动和配合的方式”。我们都理解为什么这有用、为什么有帮助。但产品管理、销售和市场之间的另一种协作形式，我觉得是一个很可能被严重忽视的领域。而且我常常觉得在组织中，你甚至能看到产品和销售、市场之间存在某种对立关系，我觉得这很可惜，因为当我们真正走到一起时，我们对销售的理解是——尤其因为我们的客户是非常专业的从业者，他们对 BS 非常敏感——所以我们要做的很大一部分工作，就是帮助我们的市场团队挑选最准确的用词和表述，让我们的语言听起来像客户自己说的话一样。
Lenny Rachitsky： 你说的是工程师，我感觉是吧？
Nan Yu： 对，工程师是很大的一块，但产品经理也是。
Lenny Rachitsky： 嗯。
Nan Yu： 产品经理知道这份工作是什么样的。所以当你走进来说错了话，别人会给你脸色看。
Lenny Rachitsky： 别叫他们 project manager。
Nan Yu： 对，就是这个例子。所以我觉得这是我们要做的很大一部分。我们的 PM 团队里，实际上有一位全职的产品市场人员，她的工作是……具体来说，所有的 changelog 都出自她手，所有的 release notes，而且她一直在为即将发布的版本打磨措辞，直接跟各团队协作，想清楚怎么讲述这个功能。然后当我们出去做 campaigns、制作素材之类的时候，很多语言都是从她这里来的，都来自她做的工作。然后跟销售这边，他们在一线验证所有这些信息——他们直接把那些话说给客户听，告诉你这些话有没有 stick，然后这三个学科之间就能形成非常好的反馈循环。
Lenny Rachitsky： 我看到你把这种工作方式叫做”double triangle”（双三角），我觉得它是 PM、工程师、设计师这个三角的补充。聊聊这个，给我们一个直观的画面，它是什么样的。
Nan Yu： 我觉得 PM，就是 product manager，我们经常很难解释”你的工作到底是什么”，因为什么都有点涉及。我们认为这份工作的本质是——把组织里负责构建的那一端和负责销售的那一端拉到一起。你要把公司所有的商业动机和目标整合起来，确保你构建的东西真正服务于这些目标，同时又要根据实际可行性和机会所在来做平衡。所以对我来说，PM 在中间，一边是工程和产品设计，另一边是销售、市场和产品管理。
Lenny Rachitsky： PM 永远在中间——
Nan Yu： 没错。
Lenny Rachitsky： 但我觉得从 PM 的视角来看确实如此，我非常喜欢这个画面——PM 把 builder 和 seller 连接起来，同时介入两个世界。这和 Brian Chesky 关于 PM 应该做市场的那套说法直接相关。他们改的方式是，每个 PM 同时也是 PMM，不再分……他们就是 product marketer。这是他们给的头衔，基本上是你所描述的方式的极致版本。
Nan Yu： 对，我觉得 Apple 一直以来也是这么做的。
Lenny Rachitsky： 明白了。所以这里的建议是，如果你是 B2B 企业的 PM，要积极介入销售和市场的一面，积极介入 go-to-market。
Nan Yu： 对，实际上，如果你在工作中还有什么影响力的提升空间没有利用的话，那很可能就是这个方面。你跟工程和设计的协作大概率已经做得不错了，但在销售这一侧，你很可能还有更大的发挥空间。
Lenny Rachitsky： 为了让那些心想”好，我想这么做，我想学 Linear 的做法，我要变得更懂销售”的 PM 有更具体的抓手——当一个人在这个双三角模型中更紧密地与销售合作时，具体是什么样的？你提到过参与销售电话，还有什么可以分享的？“试试这些事情”之类的。
Nan Yu： 我觉得要亲自产出你向受众传递的信息。市场团队做的很多事情，你不一定需要碰——demand gen、channel strategy 之类的，这些是纯市场关注的事情。但在选词和强调重点这件事上，你应该对客户有很深的理解，可能比公司里任何其他团队都深，因为你在做需求收集和 discovery 的那类工作。所以你更了解客户的原生语言，能帮助你的市场团队产出那些措辞。
Lenny Rachitsky： 明白了，基本上就是深度参与产品市场相关的工作——文案、邮件、标题、网站？
Nan Yu： 对对，正是如此。我知道”产品市场”这个词也严重过载了，他们做的事情太多了，但就是内容创作这一块，你确实有很大的贡献机会。
Lenny Rachitsky： 我喜欢这个建议的具体程度。不要去想”产品市场”这个概念，就想想你的潜在客户和现有客户看到的那些文字。好，接下来我想花大量时间聊的最后一个领域，完全不同的话题——关于找工作。
Nan Yu： 哦，好。
PM 的求职策略
Lenny Rachitsky： 你找工作的方式很独特。Mode 的创始人跟我提到过你当初去他们那里求职时非常独特的做法。我猜 Linear 应该也是类似的情况。对于那些正在找工作、可能不太顺利的人，你有什么建议？你当初在找下一份工作时哪些做法是有效的？
Nan Yu： 产品管理是一个很独特的角色。因为我们什么都做，你不会被局限在某个单一维度上和其他人比较。每个招聘 PM 的人，就像招聘高管一样，都希望招进来的人能帮他们解决某个迫切的问题。所以在面试过程中，你的任务就是搞清楚那个迫切的问题是什么。戴上你的 discovery 帽子，去搞清楚招聘经理招一个新的 PM 进团队，真正的 job to be done 是什么？如果你能做到这一点，然后有力地证明你就是解决那个问题的人，那是否录用你就变成了一个二选一：我是录用我的问题的解决方案，还是录用另一个人？
我觉得很多时候，面试中你只是在尽力展示自己最好的一面，努力说自己什么都擅长、没什么弱点，可能太拼了之类的——但每个人都会这么说。所以你只是 n 个人中的一个，你要做的是把自己从这个群体中区分开来——你是某个问题的解决方案，其他人只是一次掷骰子。
Lenny Rachitsky： 所以你描述的方式是——公司有一个 job to be done，比如说推动某个功能的增长。拿 Linear 来说，就是打造一个杀手级的、成功的 B2B 产品。不过这个太宽泛了，通常你不会面试的是 head of product 的角色，所以可能太宽泛了。应该是——这个 PM 岗位在公司里的 job to be done 是什么，然后帮他们确信你是做这件事、解决这个问题最合适的人。
Nan Yu： 对，而且当你采取这种方式时，会感觉你已经在那儿工作了。我当初的做法是——一个朋友给了我一些建议。我当时正在面试你提到的 Mode 那个工作，我问他”我该怎么准备？“他说”就当自己已经在那儿工作了，你会怎么做？“然后我就想，“好，这我能做到。“所以当你在面试过程中，有人问你问题，然后说”你有什么问题想问我吗？“你可以问他们：“你们这季度的 OKR 是什么？有人能怎么帮你实现这些？“你可以问得这么具体，然后他们会说”哦，好，我可以告诉你我这季度正在做的具体事情。“这样你就对人们真正想解决的问题有了更深入的了解。因为我觉得我们经常卡在非常高层、非常笼统的问题上，比如”公司的目标是什么”之类的，但其实你可以问得非常具体。如果你在工作中要和那个人协作，你会对他们说什么？
Lenny Rachitsky： 我喜欢这个建议的可操作性。显然这需要投入时间和精力。很多人同时在面试很多家公司，在找工作——你的建议是不是也包括，挑出你最感兴趣的那些，然后用这种方式投入大量时间？
Nan Yu： 你可以在那些你确信自己能够超额交付的公司上投入大量精力。如果你理解他们真正想解决的问题，你就知道自己在哪既有最高的被录用概率，同时在入职后也能做得出色。
充分利用面试过程获取信息
Lenny Rachitsky： 你谈到在面试过程中假装自己已经拿到了这份工作。但作为一个局外人，你往往没有足够的信息来形成一个真正好的解决方案，而且部分想法可能会完全跑偏，因为你可能会想”我其实不了解，我没有数据。“你真的会去联系团队里的工程师和设计师来了解情况吗？你会走多远去尝试解决这些问题，展示你的能力？
Nan Yu： 你本身就在面试流程中，这些人就是你未来要密切合作的人。所以从他们开始。做你的 discovery 提问，如果你觉得某个领域值得深挖，你完全可以问。问一句”能不能帮我引荐一下正在做同样问题的工程经理？“没有任何坏处。如果其他候选人没有这样做，你就又会多一条来自那位工程经理的反馈——“这个人的问题问得很好，看起来真的很有感觉。“没有其他人能获得这条反馈。所以在最终的 debrief 环节，你会多一份加分。
Lenny Rachitsky： 而且光是问出这个问题，就已经能展示你思考得有多深入了。
Nan Yu： 对。
关于截止日期的理念
Lenny Rachitsky： 太棒了。Nan，在我们进入非常令人期待的闪电问答之前，还有什么我们没聊到、你想补充或者觉得对听众有帮助的内容吗？
Nan Yu： 我对截止日期有一个非常具体的观点。我不知道这是不是你想聊的话题。
Lenny Rachitsky： 来吧，尽管说。
Nan Yu： 我觉得经常发生的情况是，人们对截止日期感到沮丧。就是”好，这是发布日期”，然后你永远赶不上。我不知道你有没有过这种感觉。
Lenny Rachitsky： 绝对有，某些截止日期确实如此。
Nan Yu： 你之前也是工程师，对吧？所以工程师基本上就是那种”哦，对，截止日期，完全是捏造的东西”的态度。而让截止日期变真实的唯一方法，就是把它们看得如此严肃，基本上当作 P0 问题来对待，相比之下其他一切都不重要了。因为只有这样，你才能向团队以及所有利益相关者发出信号：你是真的在认真对待它。所以我对截止日期的看法是——不要设太多，而一旦设了，它就是 P0。负责这个的工程师，不能做任何其他事情。什么”哦，我需要他来做这个”——不行，不行。你不能把他们拉走。我们在做这件事。作为 PM，你的工作就是尽可能多地砍范围，让达成截止日期变得可行。到底哪些东西在阻碍我们？因为你想要的是，在必须做出”发布还是不发布”的决定时，你手上能有一个你可以说”好”的产品。它可能没有你想要的所有功能，但你可以做选择。你想让自己处于一个真正能说”是”或”否”的位置上。因为经常发生的情况是——我们想要这个东西，但它根本还没接近完成，所以我们不可能说好。我没法发布，它是半坏的。不行，你想要达到的状态是——它能用。它可能不是你理想中的产品，但它是一个你可以真正考虑发布的、实际存在的产品。
什么值得设截止日期
Lenny Rachitsky： 你说了不要设太多截止日期，但一旦设了，就要确保所有人都明白这是真正的截止日期。那你怎么判断什么时候值得设一个截止日期？是类似市场营销发布之类的事情吗？在你的经验中，什么配得上一个截止日期？
Nan Yu： 通常与你需要配合的某种外部市场推广活动有关。
Lenny Rachitsky： 明白了。
Nan Yu： 我觉得另一件事是——作为 builder，我们经常看发布日期之类的东西，会觉得”哦，晚一点有什么关系，或者我们跳过这次 changelog”，不管是什么。说实话，每次听到有人这样说，我真的会抓狂。在做市场推广和客户沟通时，你拥有的机会本质上是有限的。一年 365 天，12 个月，每个月大约四个星期。存在某种节奏——你有大约 50 个星期，每周可以向你的受众说一次话；或者 12 个月，每月可以传达一个重要的信息；或者四个季度，每季度可以说一件大事。如果你错过了其中一个机会，它就回不来了。你不能穿越回过去说”好吧，让我们重做第一季度，把我们希望传达的信息补发出去。”
Lenny Rachitsky： 这个观点非常有力量。我能感受到你工作中销售、市场和 go-to-market 那一面的经验在这里展现出来了。我猜那个领域的每个人都会说”没错，完全正确。“关于这条线也许最后再问一个问题。我很喜欢这个认真对待截止日期的理念。但与此同时，正如你指出的，知道有一个必须达成的截止日期会造成很大压力。你提到的一个杠杆是砍范围。另一个就是让人们花更多时间做估算，从而有更准确的截止日期。你会在这方面投入。你怎么看待一个工程团队面对截止日期时，应该在降低风险和估算上花多少精力，还是说”我们就尽力而为，到时候再砍再调整”？
快速迭代胜过精确估算
Nan Yu： 这可能是我的一个热门观点——为了赶上截止日期，我们几乎不做任何估算。我们的做法是尽可能早地发布。就是我们之前聊到的——如果 10% 的时间过去时，你已经有一个能跑的东西了，那你接下来就可以把剩余的时间用来决定是再做一轮迭代，还是把它打磨到可以发布的标准。你是在为未来的自己创造做决定的空间。所以这一切的关键在于——你不能拖到最后一刻才说”好，现在我们必须认真对待截止日期了。“你必须从一开始就投入，commit 到快速推进、尽早迭代的流程中，然后让自己处于一个能对产品说”是”或”否”的位置上。
Lenny Rachitsky： 非常有趣，和大多数公司的运作方式截然不同。Nan，这一期完全达到了我的期望。我想这会帮助很多人构建出更好的产品——如果世界上有更多像 Linear 一样的产品，那对世界是好事。那么，我们进入了非常令人期待的闪电问答。准备好了吗？
Nan Yu： 好了，开始吧。
闪电问答
Lenny Rachitsky： 好，开始。第一个问题：你有哪两三本书是最常推荐给别人的？
Nan Yu： 我推荐最多的一本书是 Don Norman 的《设计心理学》（The Design of Everyday Things）。我最初是在大学里一门 HCI 课上读到的，在我所有读过的东西中，它是让我从”你接触的每样东西都是一个产品”的视角去看世界的那一本。你用的每一支铅笔，你开的每一扇门，都是某个人设计的产品。
Lenny Rachitsky： 那这就是那本书最大的收获吗？因为这本书经常被提到，而且年头已经很长了。对于没读过或者没时间读的人来说，你最大的收获是什么——每样东西都是被人设计的，很多东西不好用是有原因的，而且它们可以被改进。
Nan Yu： 对。前几天我就在自己家附近的一家咖啡馆里看到了一个真实的例子。我看到一个小孩把门把手拽下来了——咖啡馆门上的把手。他用力一拉，直接拉掉了，因为那扇门是推开的，但装了一个看起来像是可以拉的把手。这正是那本书里最经典的例子之一，因为门就是个谜。
Lenny Rachitsky： 太棒了。下一个问题。你最近有没有特别喜欢的一部电影或电视剧？
Nan Yu： 我在 Netflix 上看了《头号外交官》（The Diplomat），觉得非常棒。轻松好看，很愉快。如果你当年喜欢《白宫风云》（West Wing）的话，这部剧有类似的感觉。
Lenny Rachitsky： 你看第二季了吗？
Nan Yu： 看了，第二季看完了。
Lenny Rachitsky： 我对第二季没有那么兴奋，说句实话。第一季真的很好看，然后稍微有点……”好吧，也还行吧”，就那种感觉。
Nan Yu： 对，第二季变得有点间谍惊悚的味道了。
Lenny Rachitsky： 好的，不过整体还是很好的，在 Netflix 上可以看。好。你最近有没有发现什么特别喜欢的产品？
Nan Yu： 不算发现的，但我发现了一个很有意思的版本。有一支笔——其实我桌上就有一支——叫 Sakura Micron。不知道你用没用过，是一种毡尖笔，非常好用。它最早是在日本为漫画家画漫画之类的场景发明的，但什么都能用。我用来写日记之类的。有一次我在 Amazon 上想多买一些，发现有一个包装上写着”Bible Study Kit”（圣经学习套装）。我就想，为什么叫 Bible Study Kit？其实就只是同一支笔的四种颜色套装，因为这种笔不会洇墨。如果你有一本圣经——圣经通常用的都是那种很薄的新闻纸页面——用它写的话不会透到背面去。
我觉得这件事很有意思：有人把一包普通的笔包装成 Bible Study Kit 来营销，专门针对搜索那个关键词的人群。而且是官方的，不是什么民间拼凑的，而是正式的官方包装。
Lenny Rachitsky： 太厉害了。真是独特的选笔品味。还有两个问题。你有没有一个经常回到的、在工作或生活中觉得有用的人生座右铭？
Nan Yu： 正确的量就是”太多了”再减一。我觉得这也跟之前说的”先试极端版本”的思路有关。比如一个很蠢的例子：你想吃多少片披萨？五片太多了，吃完不舒服。那四片大概就是合适的数量。如果你想找到正确的数量，有时候就得先冲到最边上，发现什么是太多了，然后你就知道正确的量到底是多少了。
Lenny Rachitsky： 我喜欢这个方法如此具体可操作。这让我想到 Elon Musk 关于砍掉东西的说法。他关于高效做事的方法论之一，就是在尝试优化和自动化之前先砍掉东西。他的建议是，如果你没有把砍掉的东西中的 10% 加回来，说明你砍得还不够。
Nan Yu： 对，没错。
从缺陷中诞生的爆款
Lenny Rachitsky： 最后一个问题。你在 Everlane 工作了好几年，你之前提到过一件衬衫的故事的大致经过——关于一件现在可能是他们畅销款的衬衫，以及你是如何参与创造这件畅销女士衬衫的。能分享一下这个故事吗？
Nan Yu： 好的。先说清楚，我只是目睹了它的诞生，我觉得我自己并没有直接参与创造。但确实，前几天我在 Instagram 上看到了一个广告——那款叫 Women’s Box-Cut Tee，是一款宽短款的女式 T 恤。我看了一下，它有 20 种颜色，卖得非常好。我记得当初创造这款产品的时候，起因是一批有缺陷的男式 T 恤。它们全部做短了一英寸半。没法卖——穿上肚脐都露出来了，没人想穿那样的东西。但我们得挽救这批库存，因为当时公司还很小，需要现金流，不能直接报废。
所以设计团队和市场团队坐在一起，说：“好吧，我们这样做——再把下摆裁掉两英寸，让它变成真正的短款，然后以女性短款箱型 T 恤的轮廓向女性市场推广。“我们就这么做了。当时想的是，希望能把这批库存处理掉，不用做资产减值。结果一周就卖光了。我们想：“好吧，看来我们刚刚做出了一个爆款。“这种事情就是这样——很难说这到底算营销的功劳还是设计的功劳。我不知道，但你就是大家一起凑在一起，用最奇怪的方式找到了产品市场契合度。
Lenny Rachitsky： 我太喜欢这个故事了，而且它到现在还在卖。
Nan Yu： 对，还在卖。最初只有白色，现在有 20 种颜色了。
Lenny Rachitsky： 天哪。我真的很喜欢你工作过的行业之丰富：时尚、数据分析、项目管理。不知道下一个会是什么。我想还会有更多。Nan，这次对话太棒了。真的非常感谢你抽出时间。就像我说的，我想这一期会帮助很多人构建更好的产品。最后两个问题——大家如果想在网络上找到你、联系你，去哪里找？听众怎样才能帮到你？
Nan Yu： 我在 X/Twitter 上的账号是 @thenanyu，就是 T-H-E 加上我的名字。如果大家对 Linear 有任何反馈，我们非常欢迎，尤其是日常使用 Linear 的人。我们真的很希望听到用户的声音。
Lenny Rachitsky： 他们分享反馈最好的方式是什么？是在 Twitter 上 @你们？还是去网站？你推荐哪种方式？
Nan Yu： 都可以。你可以在 Twitter 上 @我们，也可以在 Twitter 上私信我。我的私信是开放的，都没问题。
Lenny Rachitsky： 太好了。Nan，非常感谢你来参加节目。
Nan Yu： 当然，谢谢 Lenny。
Lenny Rachitsky： 大家再见。
术语表
| 原文 | 中文 |
|---|---|
| 11-star experience | 11 星体验（Brian Chesky 提出的设计思维方法，指想象极致用户体验） |
| AE | AE（Account Executive，客户经理） |
| Airbnb | Airbnb（公司名称，保留原文） |
| B2B | B2B（企业对企业，保留原文） |
| backlog | backlog（待办事项队列，保留原文） |
| Brian Chesky | Brian Chesky（Airbnb 联合创始人兼 CEO，保留原文） |
| Capacity planning | 资源容量规划（根据可用人员与资源进行项目分配的规划方法） |
| changelog | changelog（变更日志，保留原文） |
| channel strategy | channel strategy（渠道策略） |
| COO | COO（首席运营官） |
| CRM | CRM（Customer Relationship Management，客户关系管理系统） |
| crossing the chasm | 跨越鸿沟 |
| CSM | CSM（Customer Success Manager，客户成功经理） |
| Customer Requests | Customer Requests（Linear 功能名称，保留原文） |
| demand gen | demand gen（需求生成，市场获客手段） |
| discovery | discovery（探索/发现，产品管理中指需求调研和问题发现的过程） |
| double triangle | 双三角（double triangle，Linear 内部协作模型，指产品-工程-设计与产品-销售-市场两个三角） |
| Everlane | Everlane（品牌名称，保留原文） |
| GA | 正式发布（GA, General Availability） |
| go-to-market | go-to-market（推向市场，指产品从构建到交付给客户的完整过程） |
| Hikaru | Hikaru（国际象棋特级大师 Hikaru Nakamura，保留原文） |
| IC | IC（Individual Contributor，个人贡献者） |
| Jeffrey Moore | Jeffrey Moore（ Crossing the Chasm 作者，保留原文） |
| Jira | Jira（产品名称，保留原文） |
| job to be done | job to be done（待完成的任务，产品管理中常用的需求分析框架） |
| Karri | Karri（Linear 联合创始人 Karri Saarinen，保留原文） |
| Linear | Linear（产品名称，保留原文） |
| Magnus Carlsen | Magnus Carlsen（国际象棋世界冠军，保留原文） |
| Mode | Mode（产品名称，保留原文） |
| MySpace | MySpace（产品名称，保留原文） |
| OKR | OKR（Objectives and Key Results，目标与关键结果） |
| opinionated | opinionated（理念鲜明/强主张，指软件有明确的使用方式引导，而非无差别满足所有需求） |
| Patrick Collison | Patrick Collison（Stripe CEO 及联合创始人，保留原文） |
| Paul Graham | Paul Graham（Y Combinator 联合创始人，保留原文） |
| PM | PM（Product Manager，产品经理） |
| PMM | PMM（Product Marketing Manager，产品市场经理） |
| product market fit | 产品市场契合度 |
| release notes | release notes（发布说明，保留原文） |
| SaaS | SaaS（Software as a Service，软件即服务） |
| Sakura Micron | Sakura Micron（日本品牌针管笔/毡尖笔，产品名称，保留原文） |
| SAML | SAML（安全断言标记语言，一种单点登录协议） |
| schlep blindness | schlep blindness（苦差盲区，Paul Graham 提出的概念，保留原文） |
| SCIM | SCIM（跨域身份管理系统，一种用户身份管理协议） |
| Stripe | Stripe（公司名称，保留原文） |
| The Diplomat | 《头号外交官》（The Diplomat，Netflix 政治题材剧集） |
| Triage Management | Triage Management（分流管理，Linear 功能名称，保留原文） |
| triage queue | triage 队列（对问题/需求进行分类、优先级排序的队列） |
| West Wing | 《白宫风云》（West Wing，美国政治题材电视剧） |
| Women’s Box-Cut Tee | Women’s Box-Cut Tee（Everlane 产品名称，女士宽短款 T 恤，保留原文） |
此文档由 AI 分片翻译（translate_long_document）
Linear’s secret to building beloved B2B products | Nan Yu (Head of Product)
Speed and Quality Aren’t Opposites
Lenny Rachitsky: I think you see in the team at Linear that a lot of people don’t see, which is that there’s not actually a trade-off between speed and quality.
Nan Yu: People talk about this as if there were a trade-off because when they think about speed, the thing they over-index on is rushing or being sloppy. What they should be indexing on is being really competent. If you look at people who are at the pinnacle of their craft, you can basically tell how good the output is going to be of their work product by how fast they’re going.
How to Avoid Software Bloat
Lenny Rachitsky: What does speed look like when you say it can be done quickly and high quality?
Nan Yu: What it really looks like is you have some rough time budget for how long you think something’s going to take. By the time 10% of it has passed, after week one, you have something that works that tests some kind of key hypothesis internally.
Uncovering True Customer Feelings
Lenny Rachitsky: I imagine a criticism you all get. Over time, you’ll probably become a bloated piece of software as well.
Nan Yu: When we examine this problem, we look at, “Well, what feature requests can we debate and what kind of feature requests do we absolutely have to say no to?” The stuff that we absolutely have to say no to is the exact kind of thing that leads to this bloatedness that makes ICs hate their lives.
Introducing Our Guest
Lenny Rachitsky: Something that your head of sales shared with me is how impressed he is with the way you ask questions on customer calls and just keep digging and digging until you get to something.
Nan Yu: My goal is to feel bad in the same way that customers feel bad.
Why Users Love Linear
Lenny Rachitsky: Today, my guest is Nan Yu. Nan is Head of Product at Linear, which is one of the most beloved, most beautifully designed, and also the fastest growing B2B SaaS product out there today. You rarely see the kind of love that people have for Linear for any enterprise B2B SaaS product. So, there is a lot that we can learn from how Linear operates and how they build product. In my conversation with Nan, he shares a system that he uses for being creative and coming up with non-obvious solutions to customer problems, why it’s a red flag to him when PMs tell him there’s a trade-off between speed and quality, how he talks to customers in order to figure out the emotion that they want to avoid and then figure out the solution to avoiding that emotion, plus some killer advice on how to land a job, including how he landed his job at Linear and his previous role at Mode, and so much more.
If you have a desire to build a company or a product that’s as beloved as Linear, this episode will give you a ton of tactics and ways to change how you and your team operate. If you enjoy this podcast, don’t forget to subscribe and follow it in your favorite podcasting app or YouTube. It’s the best way to avoid missing feature episodes, and it helps the podcast tremendously. With that, I bring you Nan Yu.
Nan, thank you so much for being here and welcome to the podcast.
Nan Yu: Thanks for having me. I’m a long-time listener and reader, so it’s really a treat to be here.
Speed and Quality: Not Zero-Sum
Lenny Rachitsky: I want to share something with you to kick off that I haven’t shared with you yet, that I haven’t shared with anyone. These results might have come out by the time this podcast comes out, but I’m running a survey right now that I’m calling, “What’s in your stack?” Where all my subscribers are asked, “What tools do you use most day to day? What tools do you love most? What tools do you hate?” And one of the questions asked was, what tool do you wish you could switch to if your IT department allowed you to? The number one answer by far is people want to switch from Jira to Linear.
Nan Yu: Wow. I mean, hopefully, that means we’re doing a good job.
What Speed Actually Looks Like
Lenny Rachitsky: I think that’s exactly what that means. I’ll read a couple quotes to give you a sense of what people are saying about Linear. I doubt these are surprising to you, but this gives people a sense of why you’re here and why I’m excited to extract as much wisdom as I can from you. So, a couple quotes here. “Linear is a joy to use as I interact with my engineering teams, and I find inspiration in its design.” “Linear is simple to use, yet powerful.” “Linear’s design is obviously an industry benchmark, but moreover, the performance and speed is a massive productivity boost.”
Nan Yu: I mean, it’s really good to hear that because in a lot of ways, that’s what we’re trying to do. If you think about the entire impetus behind why Linear was started, it’s because Karri was sitting at Coinbase and Airbnb and these places and just watching everyone around him struggle using the tools that they had available and always incumbent tools and just seeing that it made people hate their day-to-day a little bit, and we all got into technology and design and engineering, all this kind of stuff because it was fun. All of us started off building stupid MySpace pages and all of these side projects when we were young, and it started off as this fun thing that we do, and we’re like, “Wow, we get to do this for a career,” and then to have all of this kind of stuff put these big speed bumps into our day-to-day workflow, it just was really sad. So, that’s why we started Linear. This really bust through all of that.
The “Pick Two” Rule Is a Lie
Lenny Rachitsky: What I love about Linear, I feel like it’s an inspirational business because many people want to, “I’m going to build just a much better version of something,” and often that doesn’t actually work out. Often nobody cares enough. There’s all these barriers and reasons. People don’t switch to something that’s better, and Linear is an amazing example of building an excellent product and actually succeeding, and there’s a lot more to it maybe than just building an awesome product. So, that’s what I’m excited to dig into and understand how you all operate, and I guess just based on these results, to me, this is the ultimate sign of product market fit. People being sad they can’t use a product in B2B enterprise software especially, so let’s get into it.
First question I want to get into is something that I think you see and the team at Linear sees that a lot of people don’t see, which is that there’s not actually a trade-off between speed and quality. I think a lot of people think this is just an innate fact and something I’ve heard you talk about is that’s not actually true. I actually saw Patrick Collison tweet this exact point that I’ll read after you… I want to hear your thoughts, but talk about what you’ve learned about how there’s maybe not actually this trade-off between speed and quality.
Nan Yu: People talk about this as if there were a trade-off almost in a naive way because when they think about speed, the thing they over index on is rushing or being sloppy, and what they should be indexing on is being really competent or being like an expert. So, if you look at people who are at the pinnacle of their craft, it could be anything. It could be like a chef or a programmer or someone building houses or something. You can basically tell how good the output is going to be of their work product by how fast they’re going. If they’re going really fast, and they’re obviously not being sloppy and then leaving a mess all over the place, it’s like, “Yeah. Well, they got there because this is just second nature to them,” and they’re able to go at a really rapid pace and try stuff. And when we’re building software, that’s such a big component of how good the product is on the other side of it, which is like, “How many iterations were you able to do?” So, the only way you’re going to get a bunch of iterations done and try different things and really feel out these different variations is by just going very fast.
How to Start Moving Faster
Lenny Rachitsky: In terms of speed, is the speed there moving quickly on each of iterations? Like what does speed look like when you say, “It can be done quickly and high quality”? What does speed look like?
Nan Yu: Speed… What it really looks like is you have some rough time budget for how long you think something’s going to take, and by the time 10% of it has passed, you have a workable solution. It’s not like, “Oh, at the halfway point, we have something that is maybe a candidate that we can play around with.” It’s like, no, no, no. After week one you have something that works that tests some kind of key hypothesis internally so that you can feel like is this thing actually panning out the way we expect it to or did we have some crazy incorrect assumption? And you don’t want to wait until you’re 80% done to be able to make that kind of judgment because then it’s just too late. Then you’re pushing deadlines out, and you’re making your marketing team very sad.
Handling Criticisms of Bloat
Lenny Rachitsky: Amazing. Okay, so the way you think is, “We’re going to spend a month on this feature. Let’s get something workable. We can start testing with potential users even internally in the first few days, essentially in the first week”?
Nan Yu: Yes. Yeah.
Long-Term Beliefs Over Short-Term Gains
Lenny Rachitsky: Yeah. I guess how can you do that? Because most teams can’t do that. Most teams need to research, design, build. “Okay, cool. We have something,” and once a month later, what allows you to do that?
Brand Penetration in Enterprise Markets
Nan Yu: Yeah, I mean, there’s a lot of components of it. I think having really good talent really helps. Having engineers who don’t get blocked by every single little design choice, they’re happy to just make something workable. Even if they don’t feel comfortable with that particular solution, they’ll just bust through it and make something happen there. Part of it is intent. We don’t have any expectation that the first version of it is going to be great. That is not in the cards. Look, the first version of it is our best guess in the general direction of what we want to actually ship in the end, and sometimes it works out. Sometimes, it’s like, “Wow, this first version was pretty good. Let’s make some minor adjustments, and we’re good to go,” but there’s no expectation there. So, no one feels like they have to be a perfectionist and get everything, like all sanded down and really in tip-top shape. It just has to work and get the job done and validate or invalidate our major assumptions.
Navigating Complex Product Debates
Lenny Rachitsky: I’ll read this quote from Patrick Collison. He tweeted this today as I was preparing for this interview, and he’s the CEO and founder of Stripe, if you’re not familiar. His tweet is, “I increasingly believe that ‘good, cheap, fast — choose two’ maxim is devious misinformation spread by the slow. In my experience, slow and expensive usually go together.”
A Methodology for Product Decisions
Nan Yu: Yeah, exactly. I mean, use the contractor kind of example. Like If someone’s making modifications to their house, and it’s taking forever, one, you’re in a hotel and also the bills are adding up.
Lenny Rachitsky: The other example you used when we were chatting about this earlier is chess players. I’m thinking of Magnus Carlsen, watching him. I think he was number one in speed chess in addition to just regular chess and what a microcosm of this point.
Questioning to Uncover Emotional Motives
Nan Yu: Yeah, I think that’s the case and Magnus and Hikaru and all those guys who are at the top of their game, they can go unbelievably fast. In fact, that’s the usual… I mean, I don’t want to get too out of my depth with chess, but the usual way you try to make the game fair is you give them much, much less time than someone who’s not quite as strong of a player, and they’ll still win a lot of time, too.
Examples of Specific Emotional Hooks
Lenny Rachitsky: So, maybe just to close out this point and give someone something concrete they can do with this information, say they want to start moving faster while not cutting quality, what do you think they can do? What’s one thing they can start trying to work on and improving in the way they operate?
Nan Yu: I think it’s really that sort of attitude and point of view question to understand and take the almost controlled risk that the first version of this is not going to be perfect. So, it actually makes it a lot cheaper in many ways. It means you don’t need a pixel perfect design. It means you don’t need to make sure that all of the little UI bugs and stuff like that are solved because none of that really matters. What matters is you have working software that you can interact with, and you can see if it feels good. Does it actually solve the core problem that is facing our users? You can take it back to users. You can even let them into an early beta or something like that and get real validation there and to really focus on getting the smallest, shippable element, like not shippable in the sense of, “I can actually put on the production,” but in the sense of like, “I can start learning from here.”
Summarizing Linear’s Success Secrets
Lenny Rachitsky: Just a question I imagine is in everyone’s mind is what do you do with this first very ugly V1… not ugly, not fully ready, first version. Is this something you’re using internally to see if it’s something? Is it something you have beta design partners with?
Nan Yu: We have a gradually increasing sort of circle of users that use every single feature. So, by the time it hits GA, by the time it gets released, it’s been used by a lot of different users up to that point. So, the first circle is just internal users. We use Linear every single day to write software and do our own work, so we have that kind of advantage and then once we feel like it’s good enough, we’ll put it into some beta customer group, and again, as early as we can in the process. We have to make sure that we don’t end up corrupting people’s data, and it doesn’t look hideous and that kind of stuff, but as long as it reaches that level of quality, we can release it to early access customers who can give us good feedback and also just try to solve their problems with it. If no one engages with it, if no one’s using it, then that’s a good signal that we didn’t really hit the mark, and then we have a couple of different beta audiences that we grow and then the ultimate release obviously is for GA where everyone gets it.
Understanding User Mental Models
Lenny Rachitsky: That’s an amazing answer. Okay, so secret number one to Linear success, I’m going to take some notes here, is get new feature, product ideas out to people as early as possible, say, in the first 10% of the amount of time you’ve allotted, and then release it increasingly to more and more people to get feedback. I think the implication here is just most wasted time is on building things nobody actually ends up wanting or using. So, the sooner you at least get directional sense of are you heading in a good direction, the faster it all go?
Nan Yu: Yeah, totally.
A Systematic Approach to Creation
Lenny Rachitsky: I imagine a criticism you all get. People are like, “Yes, Linear is so great, so beautiful, so much better than what’s been out there for decades,” but over time you’ll probably become a bloated piece of software as well. That’s just the fate of enterprise software. You have to check all these checkboxes. IT teams need all these features. So, there’s always this like, “Oh, yeah, sure, you guys can operate this way for now. You have an amazing product for now, but it’ll get ugly and bloated.” How do you think about avoiding that? I know it’s something you spent a lot of time thinking about. Maybe give us a glimpse into some of the conversations you have internally when there’s these feature requests like, “Oh, I need single sign-on with this thing and this button here.” How do you think about what to add, what not to add, and how to add these features to not make it bloated?
Nan Yu: This question actually comes to us a lot from candidates that are interviewing with us. When you go like, “Hey, do you have any questions for us?” This is the question that we’re going to get. So, we hear it quite a lot, and it’s very sensible for them to ask it because they see history being littered with the corpses of startups trying to compete in this space and not making it, and I think when we examine this problem, we look at, “Well, what kind of feature requests can we debate and what kind of feature requests do we absolutely have to say no to?” And the stuff that we absolutely have to say no to is also the exact kind of thing that leads to this bloatedness that makes ICs hate their lives, and it’s very specific. It’s customization features requested by middle managers in order to make reporting a little bit easier at the cost of making IC workflows worse.
It’s like if it fits that description, we’re just saying, “No.” There’s no debate because we’ve already thought about it and this is the thing that we can’t take a single step down this path. So, I think that’s honestly one of the core promises of Linear is that we will not make this particular trade-off. So, when you see people saying like, “Wow, Linear is so much faster. It’s so much easier to use and it makes my work so much more enjoyable.” This is the reason because we have not taken a single step in this direction. It’s very easy for a PM to say yes to this kind of request because often they’re talking with buyers. Any kind of B2B type of space, they’re talking with whoever the gatekeeper is and sales is putting pressure on them, and they’re saying like, “Hey, we really want this one feature. It’s going to make our reporting nicer.”
So, the director’s going to be really excited by this, and we’ll definitely make a buying decision based off of this, and we have to convince them that this is a false trade-off. The whole premise is wrong because the moment you start going down this path, and you make the IC user experience worse, they’re just going to disengage. No one has to do this. If I’m an engineer, I get paid to write code. My performance review is based on my code contribution. It’s not based on like, “Did I fill in all the tickets right?” So, I’m just not going to do that part, or I’m going to do it very sporadically, and then I’m going to just focus on my actual job.
And then all your reporting is wrong because all the data is wrong, and it’s sparse, and you get situations where people will… They’ll say like, “Well, here’s a dropdown field that someone put in here that’s required.” There’s nine choices. I don’t know what any of them meet, so I’m just going to pick one at random. I’m still going to pick the first one. Also, I’m going to pray that my boss is not actually using this data to do any kind of reporting and that has consequence because the data can’t possibly be correct. So, I think for us, it’s a very easy decision when it comes to that particular category of feature request.
Exploring Extremes in Draft Saving
Lenny Rachitsky: I love how simple and clear that is. Basically, you all have a policy. We’ll prioritize ICs over middle managers. Especially, like I love that it’s around reporting. Almost always it sounds like, “I want to track what’s happening.”
Nan Yu: Yeah, exactly. It’s always, “I want to track what’s happening.” Well, what do you want to track? Well, I want to track which version of the product this thing’s tied to based on some field information. It’s like, okay, how is the person working on this supposed to even know that information? Well, it takes like a five-minute scavenger hunt every single time. It’s like, “I don’t think they’re going to do that, man.”
Deriving Extreme Options from Promises
Lenny Rachitsky: What I imagine happens, and I think why this is hard for most companies is there’s an implication that you’re turning down deals. You’re not adding that one feature that will close a massive million-dollar sale, very difficult to do. I imagine it helps a lot that… I imagine the COO is very bought into this and there’s this, “We will win long-term holding the line on this.” Is that right?
Nan Yu: So, it is, but I also think that there’s not as much pressure as you would expect to do these kinds of things. There are basic scaling things, like we had to make SAML and SCIM and that kind of stuff. It’s like, “Yeah, sure, we’re going to do those sorts of, like keep the lights on type of work,” but when it comes to work that’s related to the actual business logic of the app’s value proposition, what buyers care about is, is this going to make their team more effective? That’s the reason that they’re making this buying decision in the first place is that they’re like, “Well, the current situation we’re in… ” And especially with large companies, right? The current situation we’re in is a mess, and if we can convince them that these types of things are actually the reason that it’s a mess, then we can really navigate them out of wanting them in the first place.
B2B Software Teaches How to Work
Lenny Rachitsky: Got it. So, there’s an element of you think you need this, but it turns out you’ll be more successful and get everything you want, not getting this?
Nan Yu: Yeah, and the thing is, it’s not everything you want, right? Because people come with a laundry list, and it’s like laundry list. Here’s 10 things I want. You’re like, “Do you want all of those 10 things equally?” They’re like, “No, actually I don’t.” The first three are the things that really matter to us. If we solve the first three, then the other stuff, we can negotiate on. So, our job is to solve the first three-way better than anybody else that if they got through the first three through some kind of visual programming, customization type of thing, that it’s never going to get to the quality level and the depth that we’re able to offer by offering those as native features.
Philosophy-Driven Building and the Linear Method
Lenny Rachitsky: It’s interesting thinking back to that survey I shared where the tool people want to switch to if IT allowed them was Linear, and on the one hand you could argue, “Well, okay, IT is not letting them use Linear for all these reasons. On the other hand, you guys are growing really quickly within enterprise, like you’re a new business. You started, I think, mid-market startups, and now you’re working way up. So, I think it’s not fair to say it’s not going to work in enterprise. It’s clearly working really well. I don’t know if there’s any stats you can share anything of that, but it seems to be going well, expanding up market.
Nan Yu: Yeah, I mean, growth has been good. Growth in enterprise has been leading the other segments because I think this year, especially we reached a tipping point where I think with software, so much of the buying decision is based on almost like a brand thing, like is this for us? A lot of times people pick “enterprise software.” It’s like, “Why? You know everyone doesn’t want this,” and they’re like, “Yeah, but it’s for us.”
Product Management as a Go-To-Market Discipline
Lenny Rachitsky: You won’t get fired for buying Microsoft or whatever.
Nan Yu: Yeah, exactly, and I think that we’re starting to have enough brand penetration amongst enterprises where people can have that feeling, right? They’re like, “Hey, Linear is for us. Who are we? Well, we are a large company that wants to act like a startup.” It’s like, “Who doesn’t want that? Who doesn’t want to go fast?”
Job Search Strategies for PMs
Lenny Rachitsky: Yeah. I had Jeffrey Moore on the podcast, and this is exactly what crossing the chasm looks like. He talked about basically you need someone that’s across the chasm like a later adopter that isn’t the person that’s, “I love new stuff, and I’m an early adopter kind of evangelist.” You need someone that’s like traditional old school, takes their time to start to adopt it for you to be like, “Oh, okay. Now, maybe I should really take it seriously.”
Nan Yu: I also think that with this particular category of tool, and with a lot of other B2B software, not… Like no means not now, right? Not right now because it doesn’t fit our budget. It doesn’t fit our change management situation. “Oh, we have this exec that’s really wedded to this other tool,” but those things change, right? So, we keep in contact with them. They’re in our CRM where we make sure we follow up, and we’ve had a lot of these where we’ve been said no to, like two years ago, and now we have some new features, and then go like, “Oh, yeah, it seems like you’re ready for our scale,” or whatever.
Maximizing Information from the Interview Process
Lenny Rachitsky: You mentioned that when you have these debates and questions that come out, you have features that a big company wants. There’s this category of, “We know we will not build things for middle managers that want reporting and custom stuff just to track what’s happening,” versus something an IC wants to be more productive and successful, Linear. Give us a little sense of some of the more complicated debates that aren’t necessarily in that bucket.
Nan Yu: I think the complicated debates are often when we do add a new native feature, do we extend an existing feature and make it more powerful or do we add a new sort of service? And a big part of that is trying to figure out exactly who’s going to use it, what are the actual real life use cases that we know about? Like that I know that Bob from Company X has this workflow and this is how it would work for him. Here are the different variations where it would work. So, tying it all the way back to real people is-
Our Philosophy on Deadlines
Lenny Rachitsky: Like a specific person?
Nan Yu: Yeah, specific person. Yeah. Yeah, exactly. Not a hypothetical person. Not one that you made up like Alice, Bob, or whatever. It’s like, “No, here’s the first name, last name. Here’s their email. You can ask them,” and I think that being able to tie it all the way back to reality in that way is a big part of how we really think about and discuss these things.
What Actually Deserves a Deadline
Lenny Rachitsky: This connects the way I think about my newsletter is I always try to answer the question a very specific, like a person actually asked, not a general sense of something people may be interested in, and that very specific question, like it implies there’s a need. Like not implies, it proves there’s at least one person who needs this thing versus you have this idea of somebody that may want this thing.
Fast Iteration Beats Precise Estimation
Nan Yu: Yeah. I think a trap that a lot of times PMs will fall into is they’ll make something, and they’ll make some choices in it because maybe it’s beautiful or it’s elegant, but they don’t go the step of like, “Is reality also beautiful and elegant?” Because reality is ugly sometimes, and if you have a beautiful and elegant solution that doesn’t match with reality, it doesn’t really matter. People can look at it, and they can ooh and ah, but if they don’t use it to get their work done, it’s never going to have long-term staying power.
Lightning Round Q&A
Lenny Rachitsky: Do you have a heuristic of how often you need to hear something for you to… could be just convinced, this is worth investing in? People may hear this, “Oh, one Bob. Bob wants this featured.” That doesn’t make sense. It’s just one guy. How do you know when it’s like, “Okay, we should really invest in this”?
Nan Yu: Part of it is you hear something, and you’re like, “Gosh, that actually is… ” Not only is that true. It means that the way we thought about this was a little bit wrong, and I call this process… I don’t know if it’s the right way to describe it. I call it a kneeling where you have a thing, and it’s not quite the right shape, and you put it out into the wild. So, this happens way in the first bit of the life of a particular feature. You release a thing, and then you start getting feedback about it, about hey, it doesn’t quite fit reality, and then you ask yourself like, “Did we test that aspect of it? Did we actually match that part to reality?” And if you didn’t, then it’s like that’s the part where you don’t actually need that many pieces of feedback against it. It’s not really a volume thing. It’s like, “Did we think about this right or wrong?” That’s one sort of category.
Another category is just you’re getting a request for maybe a very big feature or a feature set from a lot of different people, but then you dig in, and you try to say like, “Okay. Well, tell me about how you’re trying to use this,” and there’s 100 different use cases. So, you have choices here. You can either build the big feature that covers all the long tail of use cases or you can try to see if there’s really concentrated pools of use cases for this that really make a lot of sense to adopt as a first order type of feature. So, I think those are the two sort of strategies that we employ the most. It’s like, “Did we think about this wrong? And now we’re just learning something about how it matches reality or for this big general feature that people are asking for, are there actually more specific use cases that we should be solving, and we should be solving really, really well?”
Hit Products Born From Flaws
Lenny Rachitsky: A thread that’s coming through so far across a lot of these examples is getting to the specific person using the thing and making them happy and making sure the ask is going to solve their actual problem. In the case of looking at the IC versus the middle manager, in this case, it’s like, “Let’s talk to the person actually asking for this thing,” not, “There’s like 100 people generally asking for this thing and let’s build what we think is a general solution.”
Nan Yu: Yeah. I’ll give you an example of all of these things, which we just launched a feature called Customer Requests, and basically what this does, it adds a new concept of Linear, which is a customer. For B2B companies, this is very relevant, and the reason we did this is because we kept getting this request for fully customized fields, and we would be like, “Well, what is it that you want with your custom fields?” Because the problem is you add 100 custom fields and all your ICs start hating it. So, we don’t want to go down that path, but what is it actually you’re trying to do? And 40% of them were because, “Well, I have a customer,” like Walmart or whatever, right? Like, “Walmart asked for this feature, and it’s really important. I need everyone to know that Walmart needs this. I need to track it. I need to see how have we report… ”
We can report on what have we done for Walmart over the past year so that when my CSM has a one-on-one conversation with a rep, they can have some kind of evidence that we’ve been doing stuff for them, like all this kind of stuff. We’re like, “Okay. Cool.” That sounds like a very useful and powerful thing you want to do. How do you expect people to tag these things? Well, manually, because that’s how we did it in our spreadsheets. It’s like, “Okay, instead of that, we’re going to hook up with your customer support tools. We’re going to hook up with your CRNs. We’re going to automatically bring in feedback from these companies. We’re going to analyze the emails where they’re from, and then if someone requests a feature that gets escalated into engineering, it’ll just be tagged with whoever asked for it. You don’t have to do anything, but you will know, and you can still report on this stuff, but there’s nothing about this that makes ICs lives harder.
In fact, it makes them feel more confident because when they’re building the thing, they actually understand who’s asking for it and exactly what the email said. So, when they’re doing the design or the details, they can actually see the real-life use cases that are present and solve for those directly.
Lenny Rachitsky: As I’m hearing this, it’s like, “Okay, obviously, this seems like an obvious solution. Of course, 40% of people telling me they have customers.” In reality, most of the time, if you hear from a bunch of your customers, “Hey, I need this custom field,” and sometimes you hear one thing, sometimes you hear another. Most of the time you’re going to build this custom field. Something that your head of sales shared with me is how impressed he is with the way you ask questions on customer calls and just keep digging and digging until you get to something that is an insight for you, and then you start to try to solve the problem for them and think about what the product might be, and I think this is such an important and underappreciated skill for PMs. Is there any advice you could share of just how you approach this, how you ask questions, how you think about these customer calls to get to, “Okay, now, I see what we need to build versus let’s just build what they’re asking for”?
Nan Yu: It’s funny because I think from the outside, I’m on these sales calls and then the AE or someone’s watching me ask these questions, and I think often they’re like, “What are you doing? You’re just asking questions from angles that I don’t even know what your goal is here,” and my goal is to feel bad in the same way that customers feel bad. They come to us with a request, “Hey, we want X,” and it’s like there’s something motivating it and you can do the normal analytical thing and be like, “Ask five whys,” and try to figure out like, “Well, what are your goals?” “And as a persona X, I want to achieve this outcome.” You can do it that way, but you might miss the reason that they actually feel bad for not having this thing like, “I can’t accomplish this goal. So what?” “So, I’m not going to get promoted at work.”
Okay, great. I understand the severity of your problem at this point. What is the actual emotional valence that is motivating whatever you’re telling me? And it takes a little while to get there. You can ask people directly like, “How do you feel?” And they’re not necessarily going to tell you, but if you have a long enough and deep enough conversation with them, you start to level with them, and you’re starting to see stuff from their perspective, and the more you see it from their perspective and the more they know that, the more they’re willing to open up to you and tell you like, “Okay, honestly, I had this thing happen where I marked the ship date of this project as December 30th because it’s a Q4 project, and I wanted to put it at the very end, and then my marketing team lost their mind because they’re like, ‘We can’t ship something on December 30th. Everyone’s on vacation,’” and you’re like… And then they’re like, “Yeah, this has made me feel really bad.”
So, I don’t ever want to put dates on things ever again. So, like, “Okay, cool. We can help you deal with that. If that’s what you’re feeling, then I can start building stuff to make sure that you never have to have that bad feeling again.”
Lenny Rachitsky: People talk about empathy like, “You need to have empathy as a PM. You need to build empathy the best product leaders, have empathy in this.” I think it’s such a succinct and powerful way of describing what empathy actually looks like as a product leader, which is I want to feel as bad as they feel in hearing the story they tell, and it sounds like the way you do that is you keep asking questions to understand the moment they felt bad about something. In this case, the deadline.
Nan Yu: And if you ask somebody in that last story, like what kind of issue do you have? You’re like, “Oh, marketing and I would just never align on anything.” It’s like that doesn’t really tell you what’s going on. What it tells you is you had this terrible moment of communication that it’s all miscommunicated, and you’re like, “It’s just going to keep happening over and over again.” So, the thing that we did specifically to solve this was on projects in Linear, you can just specify a target date at whatever level of granularity you want. You can say it’s a December project. You can say it’s a Q4 project. You can say it’s a second half of 2024 project. Like whatever you’re happy promising, you can just put it on there and that way you never feel like you have to give this sense of false precision so that it ends up with a whole bunch of miscommunication down the line.
Lenny Rachitsky: I could see why people love Linear is it just makes them feel less bad less often. There’s a lot of connection here. I know this idea of emotions and feeling bad is a core part of how you think about building product, looking for moments. People feel bad. Is there anything more you could share there to share how you think about this idea of emotional hooks, emotional moments, and how you decide what to build?
Nan Yu: So, to set the background of this, I’ve worked in very, very competitive industries. I worked at Everlane, which was a direct-to-consumer clothing brand. I worked in Mode, which is like BI tools and there’s so many BI tools out there, and then obviously, Linear. We’re project management. There’s a lot of project management tools, and I think the more competitive your industry is, the more the low-hanging goal-oriented stuff is already picked because every PM from every one of these companies has been asking like, “Well, what’s your goal? What is your job to be done,” and all this kind of stuff. So, you have to look at things from an angle that other people might not have seen and for me, and for us, it’s the angle of where are the emotional hooks that you’re experiencing as you go through your work day, as you use our product, as you use competitors’ products?
I think it’s probably underexplored because… I don’t know. I feel like PMs and engineers, we’re like very thinky people. We avoid the touchy-feely stuff. So, I think that’s the opportunity. You can see where are you feeling bad throughout your day where you don’t even know? You might think, “I hate Mondays.” “Why do you hate Mondays?” “Well, on Mondays, I have to go out and gather a whole bunch of stuff to write this report that it’s really annoying.” “Oh, so if I gave you a button that made the report, would that help?” It’s like, “Oh, yeah, then I might not hate Monday so much.” So, I think Paul Graham has a word for this. He calls it schlep blindness, right? It’s like I’m schlepping through life, and I’m just completely blind to it, and it’s true. You have to have an outsider come in and see what the rhythm of your feelings are throughout the day, throughout the week, and you note the spots where you could really use a lot of improvement.
Lenny Rachitsky: Is there an example? I’ve shared a couple, but just where you’ve noticed this in someone using maybe a competitor or even Linear that you solved. I know you gave an example of the dates. I guess is there anything else?
Nan Yu: A big feature that people love about Linear is we have this thing called Triage Management, and what it does is it systemizes this thing where if I put an issue into a different team, if I’m asking them to do something or I’m reporting a bug to them, it sticks in a special zone where it’ll notify the right people. They’re on a rotation and people will be able to respond to it in an organized manner, and I think this kind of automation, this feature, it came out of two different fields people were having. One, people were trying to implement this stuff by hand, and it was just a lot of touches, and they were doing it, but they felt like, “Oh, I’m totally underwater.” “Why are you under water?” “Well, I have to throw all these tickets around and route them correctly and stuff like that,” and they didn’t see this as an opportunity to have a tool specialize in managing their triage queue.
Because they were managing by hand… They were on top of it, but it just felt really bad because they just had to spend so much attention doing this and then there’s the folks who didn’t do that. The feeling was just like, “Well, it’s totally out of control. People are just throwing tickets over the wall, and I don’t know what to do with them. I don’t know where they are. They end up in all these holes and then the people on the other side are like, “I throw tickets over the wall. I have no idea what happens to them. I have no expectation that people are ever going to respond to them.” So, there’s all of these bad feelings that people are having. They all have the same root cause, which is like there wasn’t a very automated organized way to deal with your triage queue.
Lenny Rachitsky: Marketers, I know that you love TLDRs. So, let me get right to the point. Wix Studio gives you everything you need to cater to any client at any scale, all in one place. Here’s how your workflow could look. Scale content with dynamic pages and reusable assets effortlessly. Fast-track projects with built-in marketing integrations like Meta, CAPI, Zapier, Google Ads, and more. A-B test landing pages in days, not weeks with intuitive design tools. Connect to tracking and analytics tools like Google Analytics and Semrush, and capture key business events without the hassle of manual setup. Manage all your client’s social media and communications from a unified dashboard, then create schedule and post content across all their channels. If you’re on content-rich sites, Wix Studio’s no-code CMS lets you build and manage without touching the design. And when you’re ready for more, Wix Studio grows with you. Add your own code, create custom integrations with Wix-made APIs, or leverage robust native business solutions. Drive real client growth with Wix Studio. Go to wixstudio.com.
I’m going to try to summarize some of the secrets of Linear’s success so far. So, the first is get something out as quickly as possible, say, in the first 10% of the time that you have to build this thing and get it out to internal users and then maybe a growing list of beta users and people that are aware of they’re using early stuff. Two is prioritize the IC and the user, basically, versus the buyer or the middle manager that wants reporting and all these custom features. So, it’s basically focused on the user, which I think you hear a lot, but I love this very specific example. Three is when you hear asks for features and requests, get to the specific person using the thing, not just general, “Okay, cool. I’ve heard it 100 times.” Find the person that actually needs this thing and understand what’s going on, and then four is look for people feeling bad in a moment working in the product. Is there anything else that I’m missing that’s important or any nuance you want to add?
Nan Yu: The part where you said, like focus on the user, I think it’s maybe a little bit more subtle than that. There’s a nuance which is find where the incentives are really misaligned amongst your user base. There’s a middle manager that wants really detailed reporting and there’s a IC who just really doesn’t want to go through all those extra steps, and the incentives for what they want are just very… They’re just very misaligned, and you have to find those situations and be pretty judicious about how you make those trade-offs and where you can really find win-win outcomes there.
Lenny Rachitsky: That’s a really important nuance. Something else that’s come through a couple of times as you’ve been talking is also something Patrick Collison tweeted once that has stuck with me, which is this idea of having a mental model in your head of the user. So, the way he described it and the way you’ve described it is oftentimes people are like, “Cool. We’re going to figure out what to build. We’re going to do a bunch of research, talk to users. That’ll inform what we build, and we build it, versus what you’ve been saying and what he said is you do a bunch of research, look at data, talk to people. That informs your mental model of what the customer needs in their life, and then that informs what you build. So, that anytime you do more research, talk to customers, it’s informing your view of the person, and then you’re like, “Oh, this was different from what I imagined,” or, “Oh wow. This is exactly what we’ve been thinking and let’s build that.” Anything along those lines that you might want to share?
Nan Yu: Yeah, I mean, I can tell you a little bit about how we manage our backlog, which I think actually ties directly into this. At any given moment, we have probably 20 or 30 opportunities that we could possibly explore, just product opportunities, like problems to solve, areas to improve for our users, but they’re not ready yet. We don’t have enough conviction around how we might approach it. So, we just accumulate understanding of this stuff and periodically, we accumulate some more stuff, and then we reevaluate, “Okay, what is our current understanding of how we might best approach this thing?” And I think something that people struggle with is that they might have this model in their head. Like a PM might have this model in their head about how a user behaves, but it’s just very hard to share that with someone else. You have to telepathically throw it into their brain, which is hard. So, what we try to do is identify areas that we might attack with a product, but also keep an up-to-date analysis of each of those areas so that everyone can engage with it and also contribute.
Lenny Rachitsky: Is there an example of something that’s sitting in your roadmap? I don’t know if you could share these sort of things that’s just sitting in the backlog of just like, “We’re not quite ready to tackle this yet, but here’s something we’re inkling on.”
Nan Yu: Yeah, sure. Capacity planning is a thing that’s been sitting in our backlog, and it’s something that we see managers struggle with all the time, which is like I have a limited amount of personnel and resources, and I need to deploy them in such a way where we can theoretically accomplish our roadmap, but also we don’t get blocked by some bottleneck that we don’t end up blocking all of the projects because this one engineer is stuck on some info thing, and that’s a thing people struggle with all the time. All the solutions out there are bad. The best solution is a very, very custom spreadsheet that someone would make, and it’s a lot of upkeep. So, we have some ideas about how we might automate this, how we might use existing data within Linear to really help out with this problem, but I don’t think we’ve quite cracked it yet.
I think there’s some nuances that we have to really explore a little bit further. So, we’re continuously developing this, and as we hear from hear from users that are struggling with this problem, we will get on a call with them and sit down with them and talk through it.
Lenny Rachitsky: And the idea there is keep informing this mental model, keep informing what this could be until you get to a place of like, “Okay. Cool. I think we figured out what will really solve this problem in an elegant way”?
Nan Yu: Yeah, and I want to really stress a nuance here, which is it’s not that we want to solve the entire problem. The entire problem is quite big, but there’s something that’s really right for Linear to do that would help people have a good starting point for them to reason about it. So, I think a lot of building conviction around stuff is not even like do we have a workable solution? It’s like how much of the problem should we actually take on? Because if we take on too much of the problem, then we’ll end up overpromising and not being able to deliver on it.
Lenny Rachitsky: I think what’s also useful here is you all keep your team very small intentionally and being constrained keeps you from taking on these things too early because you don’t have the engineers to build their designers.
Nan Yu: Yeah, that’s true. I actually hadn’t really put that part together, but I think some of the reason we’ve done it this way is because we don’t have the bandwidth to action everything. So, we have this backlog that we maintain to make sure that when we do take it on, we’re pretty set up for success.
Lenny Rachitsky: Yeah, it’s interesting. I think a lot of companies are starting to realize that they can build better products and move faster with fewer teams. I want to move in a different direction and talk a bit about how you actually think about building new products. Something that I’ve heard from you is that you have a systemized way of being creative, which I think is a dream for a lot of people’s. It’s like how do I be more creative? How do I think of new innovative concepts? You have a really interesting process for how you do this. Can you talk about it?
Nan Yu: Yeah, totally. I think when people talk about being creative, a lot of times what they have a problem with is extrapolating. They can see the stuff that’s right in front of them, but what about two or three steps down the line? And then it’s just like, “Well, there’s just so much possibility. I don’t know what direction to go.” So, the way that we try to do it is we ask a question which is like, “Okay, how extreme can you take it? You’re designing a product. You’re trying to come up with a solution. What’s the most outrageous version of this along some trait?” I don’t know if you guys did this at Airbnb, but I think Brian Chesky talks about like, “What’s the 11-star experience?” Is that a thing you guys did?
Lenny Rachitsky: It was a thing he talked about. Yeah, there’s always a push of what’s the 10X version of some idea.
Nan Yu: When you think in that way, when you’re saying like, “Hey, what’s the 11-star experience?” What you’re really asking is like, “Hey, what’s the most luxurious version of this hotel stay? Or what’s the most unforgettable kind of experience we can give people?” And you throw away things, I don’t know, like cost. You throw away things like practicality because that’s not what’s interesting. What’s interesting is I want to actually explore the possibility space, and I think this is really important to do because the goal is to get you to see beyond your defaults. We have all of these constraints that we’re operating under that we psychically have in the back of our heads that we just don’t even realize we have them. So, just break past all of them, and then you can really see what your options are because we talk about product decisions. It’s like, “Oh, yeah, you have these choices. What are you going to decide?” There’s all this decision-making kind of theory.
But the biggest risk is you didn’t see the right choice to begin with. You have these three choices and none of them were right. It’s this fourth one that was over in this corner, but you didn’t look in that corner, so you never found it. So, I think the whole goal of this is to try to expand the search space of what you’re trying to do.
Lenny Rachitsky: So, what you’re saying is people often don’t think out of the box enough by not thinking too radically enough. So, the choices they’re deciding between are just meh options and there’s this process of breaking out of that, and I think you could hear this and be like, “Yeah, sure.” I could spend 10 minutes being like, “Oh, hey, what’s the craziest [inaudible 00:47:35]- ”
Nan Yu: Yeah.
Lenny Rachitsky: But you’re saying that actually is what you do and that actually works really well?
Nan Yu: Yeah, and you actually build it. You can think of a very extreme version of a product and you can say, “Hey, let’s actually… ” For the first version, we talked about, like the first version, you know it’s not really the right answer. Sometimes, you know it’s so hard because you know this is the most extreme version of the answer. So, let’s build that as fast as we can and see how it feels, and then we’re going to learn so much about what the right actual answer is because we have seen this area of the product space and really felt it.
Lenny Rachitsky: Awesome. Let’s talk about an example of this because this feels awesome.
Nan Yu: Yeah, I can talk to an example. Actually, is it okay if I demo something?
Lenny Rachitsky: Absolutely. Let’s do it. Show and tell.
Nan Yu: Yeah, let me do that right now.
Lenny Rachitsky: Here we go. We’re going to share screen.
Nan Yu: All right. So, this is just like a demo space instead of Linear. So, the feature where we did this that I remember very clearly, because it was recent, is we built this feature to save drafts for your issues. So, Linear, as hard as an issue tracker, if I make a new issue and let’s say I’m trying to report a bug or something, so it’s like I make a bug report, then I might start thinking through like, “Okay, what are the repro steps?” And then I start typing them, and this happens all the time. When you’re at work, you’re doing this and someone distracts you. If someone pings you on Slack or you have to go to a meeting or something like that, you’re like, “I got to put this away for a second. I’ll come back to it later.” Note to self, figure out the actual repro steps and do it.
So, what can you do? Well, you want to save it as a draft. So, we’re like, “Okay, this is the problem,” and the first version of this, we’re like, “What do we want to do? Linear is about being fast.” So, we don’t want to get in your way. We want to say like, “What is the fastest draft saving experience possible?” So, if you save it as draft, you can save it as draft. If you decide to not… you want to throw it away, you don’t want it, just hit the X button, and it’ll just throw it away. We’re not going to interrupt you with a popup that says like, “Do you want to save your changes,” or any of that kind of stuff. We’ll just absolutely get out of your way fast as possible. So, we’re like, “What’s the risk here?” Well, it might feel really unsafe.
If you close this, and we don’t ask you if you want to save change, you might feel like, “Oh, I just lost my changes on accident.” We knew that going in. We built this anyway, and it felt super unsafe. It turns out that sort of inkling that we had was true, and we really felt exactly how unsafe it was. So, then we were like, “Okay, well, what’s the safest thing we could possibly do?” The safest thing is just auto save everything. So, you start a new issue, and then you start typing some stuff, and it’s just like auto saving as soon as you type a single character and that did feel quite safe. So, cool, but it also ended up leaving behind a whole bunch of like a paper trail of things you change your mind about. You’ve probably had this happen in document tools where you have a whole bunch of things in your space called like Untitled Document or New Document and stuff like that. It’s just like-
Lenny Rachitsky: So many untitled folders.
Nan Yu: Yeah, so many untitled folders because the moment you say new folder, it starts saving it, and then you don’t actually mean for that to happen. So, we had those two sorts of variations that we built, and we fell through and where we ended up was a balance between those two. So, what happens is if I’m creating a new issue, like I am here, and I close it out, it’ll interrupt me, like we have to interrupt you, otherwise it feels too unsafe. So, I can save the draft, I can go to my drafts, and then if I’m in this draft I’ve already made, and I go in there, and I start to say, “Okay, I’m going to keep working on it,” but then I get interrupted again, then I’m just going to auto-save it for you. There’s no point. I’m not going to ask you again.
I’m always going to auto save it because I’m not going to create a new object. I’m just making modifications in place. So, we made this very specific choice of on a brand new issue, we will interrupt you, and then on an existing draft that you’re messing around with, we’re just going to auto save everything and someone doing a analysis. If they did a detailed teardown of these decisions, they might say like, “Wow, they made very specific choices here,” but the path to get there is to do something totally extreme in one direction and then totally extreme in another direction and then find where they really meet up.
Lenny Rachitsky: Such a good example, the way that you described it is you went like here’s the safest route. Here’s the fastest version. Where did you come up with these list of options? And for folks that are trying to do this for their company, are these like… Because these are Linear principles, we’re going to be very fast. Is this the way you think most companies should operate these sorts of attributes? Do you think it’s specific to what makes their product different? How do you think about that?
Nan Yu: I think for a lot of companies, you have to ask, “What is the promise that your product or your business is making people?” It might be you always have a car available if you need it, and if you do that, then maybe we’re going to have to implement search pricing to make that happen. It’s always going to be available. So, here’s the trade-off that we have to make. It’s a very extreme point of view to do that. Or you might say the price is always predictable, but sometimes you can’t have a car in the first place. Those are all choices that you get to make, and you have to sort decide, like where in that spectrum does it make sense based on the promise of your company?
Lenny Rachitsky: A lot of people talk about this idea of working backwards. Brian Chesky in Airbnb has a big concept of working backwards from the ideal. Let’s design the best possible scenario and work backwards. I love that this is even more tactical, which is just pick the extreme version of very specific attributes. Probably not that ideal, but it’ll give us insight into a version of the ideal and an element that works well and then what doesn’t. Yeah, exactly. I did this a lot actually at Airbnb, just like testing the extreme. So, it super resonates, this idea, and when you say test, so was it like you build it and play with it? Do you roll it out to some of these circles of users or is it often just internal, and then you learn and then iterate?
Nan Yu: Yeah, we rolled out some of these versions to people.
Lenny Rachitsky: Oh, wow. Okay.
Nan Yu: So, the super-fast version that was unsafe, that only went interna, and everyone felt it was too unsafe, but then we thought, “Okay, let’s go to the super-safe version,” and then we rolled that out and everyone started having a whole bunch of… Like how many drafts are people making? I’m like, “This is too many.” The people are leaving behind this crazy paper trail. Okay, we got to figure out some difference here.
Lenny Rachitsky: Awesome. So, this very much connects to your first point of get things out really quick, and in this case, it’s like extreme versions. You’re probably not going to work long term, but it will teach you.
Nan Yu: Yeah, exactly.
Lenny Rachitsky: Amazing. Okay, and seeing it in action, I’m like, “Okay, obviously, this is the solution,” and that’s how the way this should feel, and to your point, it was not an obvious solution when you started thinking about it.
Nan Yu: Yeah. I mean, the best solutions are always obvious in hindsight, and it’s just like you have to develop a process internally that to eventually find your way there.
Lenny Rachitsky: Something else that you’ve mentioned when we were chatting that connects to some of the things we’ve been talking about is you have this perspective that B2B software isn’t just solving people’s problems, it’s also teaching them how to work, and it’s this accumulation of information. Can you talk about that? Because I thought that was really fascinating.
Nan Yu: If you think about how a lot of B2B software gets created, it’s because there was some person in the middle of some giant company who implemented some kind of process, and they’re like, “Wow, this process is really working for us. Maybe we should make it easier,” and they build a little tool internally and then all of their colleagues can now press on buttons and good things happen, and then they turn that process and that tool. They spin it off into a startup, and they make a startup. This process repeats thousands of times. So, when you adopt that tool, you’re not just adopting the actual software, you’re adopting the idea that this is a practice that you ought to be doing in the first place. So, if you’re a marketing person, and you adopt some marketing software, you’re not just saying, “Okay, now, I can write emails and send them to people.”
There’s all sorts of process around that. You’re organizing stuff into campaigns. You’re measuring click-through rates. You’re calculating cost of acquisition and all that stuff probably comes equipped with a tool because those are the right practices to do when you’re doing this sort of marketing exercise. And whether you knew about it before or you learned it from the tool, like as a buyer for this kind of product, what I’m doing is I’m saying like, “Hey, I’m going to bring in this baseline level of marketing competency into my organization, that this is the worst we can do is whatever the tool defaults are.”
Lenny Rachitsky: Interesting. So, you’re basically buying into a way of working when you’re adopting a piece of software, not just have this problem I need solved.
Nan Yu: Yeah, exactly, and I think the most salient example of this is if you’ve ever seen like a company adopt an ERP product, it’s the most painful thing you can imagine. It’s doing deep surgery. They have to redo all of their internal processes and the way they manage inventory and all this kind of stuff, but they’re willing to do it because they know that this is a battle-tested way of making sure that you’re actually doing good management of resources. So, they’re like, “We’re growing up now. It’s time for us to adopt these best practices. In order to do that, we have to adopt this tool, and we will conform to whatever the tool is best is to do.”
Lenny Rachitsky: This connects to a couple things I know about Linear, one is what you’ve shared of just avoiding these customizations requests from people. Do you have a very opinionated way of here’s how you should operate in order to build a great functioning product, org, and company in general? I’m just connecting threads here. One is like we’re going to avoid letting people customize too much because we know they’ll have a bad time, and then two is just this idea of we are opinionated about the way you should work in Linear, and it’s like you have a Linear method, I think it’s called, of just like here’s how product team should operate based on everything we’ve seen be successful.
Nan Yu: Yeah. Yeah. It’s definitely connected in a way, and I think sometimes when people talk about… You mentioned like being opinionated, and I think sometimes when people talk about being opinionated, it can feel like they’re almost saying like, “Hey, this is arbitrary,” like your opinion and my opinion, they’re just too opinions, man. Neither is right or wrong. What we try to do is find where there’s actual consensus amongst a lot of different high performing teams, and then we can take those practices and say like, “Okay, for a team that isn’t already practicing this, can we give them a button so that they can start practicing this?”
When we see companies doing a really good job of managing their triage queue, but it’s very manual, we’re like, “Okay, can we automate this? And then for this other company that really needs it that they don’t know this is what they need, can we just give them a button to activate this?” And now they have the practice within their org, too.
Lenny Rachitsky: So, I think the takeaway here is when you choose a tool, recognize it’s going to change the way you operate and be thoughtful about is this the way we want to work versus just we just have a problem we want solved?
Nan Yu: Yeah, exactly.
Lenny Rachitsky: I want to come back to something, a thread that’s come up a couple of times in our chat is the way you collaborate internally. It feels like there’s a pretty unique way. You said you were on all the sales calls. Is there anything that you can share about how you collaborate internally, how the different functions collaborate that may be unlike how other companies operate that might be helpful for them to learn from?
Nan Yu: Yes. Something that’s worked really, really well for us is we think of product management as partially like a go-to-market discipline in the same way that sales and marketing are, right? When you talk to people and like, “Hey, tell me how product management works in your company,” they’ll probably say something about like, “Well, there’s engineering product and design. They work in this triad, and here’s how they interact and collaborate,” and we all understand why that’s useful, why that’s helpful, but this other form of collaboration between product management, sales and marketing, I think it’s something that’s probably really underexamined and often I feel like in organizations, you actually see some antagonism between product and sales and marketing, and I think that’s a shame because when we come together, the way we think about the way that we think about selling is a matter of like… especially because we sell to very expert practitioners, and they have a very sensitive BS detector.
So, a big part of what we try to do is we try to help our marketing team pick exactly the right word and the right phrasing to make us sound native to the language that our customers speak and also-
Lenny Rachitsky: You’re talking about engineers is my sense, right?
Nan Yu: Yeah. Engineers is a big one, but even product managers, right?
Lenny Rachitsky: Mm-hmm.
Nan Yu: Like product managers know when… They know what the job is like. So, when you come in, you say the wrong words, people give you stink eye.
Lenny Rachitsky: Don’t call them project managers.
Nan Yu: Yeah, exactly, for example. So, I think that’s a big part of what we have to do. So, on our PM team, we actually have a full-time product marketer, and her job is to… Tactically, it’s like all the change logs come from her, all the release notes, and also she’s always crafting the language for whatever upcoming release that we’re building and working directly with the teams and trying to figure out how to talk about it, and then once we go out and build the campaigns, build assets and things like that, that’s where a lot of the language is coming from. It’s coming from the work that she’s doing and then with sales, they’re validating all that message in the field. They’re saying the words to customers directly and telling you if it’s sticking or not, and then you can have a really good feedback cycle between those three disciplines.
Lenny Rachitsky: What I’ve seen you refer to this way of working as is a double triangle, which is I think a complement to the PM, engineer, designer. Talk about that and give us a visual of what that looks like.
Nan Yu: Yeah, I think PMs, like product managers, we often have a tough time trying to explain like, “What is your job?” It’s a little bit of everything. I think the job that I do that we see it as is you’re taking the building side of the organization and the selling side of the organization and bringing it together. You’re taking all of the commercial motivations and goals of the company and making sure that what you build actually solves for those goals, and you’re tempering that with what’s possible and where the opportunities are to actually build stuff. So, to me, it’s the PM in the middle, and then you have engineering, product design, and then sales, marketing, product management on the other side.
Lenny Rachitsky: PM is always in the middle-
Nan Yu: Indeed.
Lenny Rachitsky: … but I think that’s true from the perspective of PM, and I love this visual of just the PM is connecting the builders to the sellers, and you’re involved in both worlds. This connects very directly to Brian Chesky’s whole thing about how PMs should be doing marketing. So, the way they changed it, every PM is also PMM, and there’s no more… They’re product marketers now. That’s their title and that’s like the extreme version of what you’re describing.
Nan Yu: Yeah. Yeah, and I think Apple’s been doing that way for forever, too.
Lenny Rachitsky: Got it. So, the advice here is if you’re a PM at a B2B business, lean into the sales and marketing side of it, lean into the go-to-market.
Nan Yu: Yeah, and in fact, if you’re leaving something on the table in terms of the kind of impact that you are having at your job, that’s probably the thing that you’re leaving on the table. You’re probably already doing a good job of collaborating with engineering and design. It’s probably the sort of sell side that there’s an opportunity for you to have more impact.
Lenny Rachitsky: Just to make it even more concrete for PMs that are like, “Okay, I want to do this. I want to do what Linear’s doing. I’m going to get more salesy.” What does it look like when someone is more is in this double triangle working more closely with sales? You talked about being on sales calls. What else there can you share of just like, “Here, try these things”?
Nan Yu: I think originate the message that you send to your audience. There’s a lot of things that marketing does, which you are never going to necessarily touch. There’s always demand gen and figuring out channel strategy and all this kind of stuff, like sure. That’s a peer marketing concern, but actually picking the words and where the emphasis is, like you should understand the customer at a pretty deep level, probably deeper than any other group at the company because of the kinds of requirements gathering, discovery that you’re doing. So, you’re going to know the native language that your customers speak a lot better and help your marketing team originate those words.
Lenny Rachitsky: Got it. So, basically be really involved in the product marketing, the writing, the emails, the headlines, the website?
Nan Yu: Yeah, yeah, exactly. I know the word product marketing is also so overloaded. They do so many different things, but it’s that sort of content creation piece that you really have an opportunity to contributes to.
Lenny Rachitsky: Yeah, I love how concrete that is. It’s like don’t think about this concept, product marketing. Just think about the words that your potential customers and customers see. Okay, final area I want to spend a lot of time on is totally different. It’s around getting a job.
Nan Yu: Oh, yeah. Okay.
Lenny Rachitsky: You have a pretty unique approach to finding a gig. I heard from the founder of Mode about the very unique way you approached getting a job there. I imagine Linear is a similar boat. What advice can you share with folks that are looking for a job, maybe struggling, that work for you when you were looking for your next gig?
Nan Yu: Project management is a unique role. Because we do just about everything, you don’t really get pigeonholed into being compared along a single dimension with everyone else, and everyone who’s hiring PMs, just like when they’re hiring execs, they’re hoping that they bring them on to solve some burning problem that they have. So, it’s your job when you’re in the interview process to figure out what that burning problem is. So, put on your discovery hat and go figure out what is the actual job to be done of the hiring manager when they’re bringing on a new PM onto their team? And if you can do that and then make a good case that you are the person to solve that problem, then hiring you becomes a binary choice between do I hire the solution to my problem or do I hire someone else?
And I think what ends up happening a lot is when you’re in a interview process, you’re just trying to put your best foot forward, trying to say that you’re great at everything. You have very few weaknesses. Maybe you tried too hard, like whatever, but everyone’s going to say that. So, you’re just one of end people, and you want to make yourself a little bit of just you versus the field. You’re the solution to a problem and then everyone else is like a roll of the dice.
Lenny Rachitsky: So, the way you’re describing it is the company has a job to be done, say it’s drive growth of some feature. In this case, it’s like for Linear, just build a killer or successful B2B product. I don’t know. That’s a broad one. Usually, you’re not interviewing for head of product role, so that’s maybe too broad. So, it’s like what is this PM role’s job to be done at the company and then help convince them you are the best person to do that job and solve this problem for them.
Nan Yu: Yeah, and a lot of times when you take that approach, it’ll feel like you already work there, and the way that I did this, like I got advice from a friend. He said like, “I was interviewing for this job at Mode that you referenced.” I’m like, “How should I approach it?” He’s like, “Just act like you already worked there. What would you do?” And then it’s like, “Okay, I could do that.” So, then when you’re in this interview process and someone’s asking you questions. He goes, “Do you have any questions for me?” You can ask them like, “What are your OKRs this quarter? How can someone help you achieve those?” You can be that specific about it, and they’re like, “Oh, yeah, sure. I can tell you about the exact thing that I’m doing this quarter, and then you’ll have some level of intelligence about what people are actually trying to solve because I think often we just get stuck in these very high level general types of questions like, “What’s the company goals sand all that kind of stuff, and it’s like, no, you can get really specific. If you were collaborating with that person in your job, what would you say to them?
Lenny Rachitsky: I love how actionable this advice is. There’s obviously an element of this takes work and time. A lot of people are interviewing at a lot of companies, trying to find a job, is part of your advice. Pick the ones you’re most excited about and invest a lot of time in this way of interviewing.
Nan Yu: You can invest a lot in the ones where you know that you’re going to be able to over deliver on. If you understand what they’re actually trying to solve, then you know where you’re going to have both the highest chance of success of getting hired, but also doing a really great job on the other end of it.
Lenny Rachitsky: And you talk about how you’re like pretending you have the job, pretending you actually have this job as part of the interview process. Oftentimes, as an outsider, you don’t have enough information to have a really good thought on what the solution is, and maybe part of it is going to be so wrong because you’re like, “I don’t actually know. I don’t have the data.” Do you actually try to reach out to the engineers and designers on the team to try to understand things? How far do you go to try to solve these problems and show them what you can do?
Nan Yu: Yeah, I mean, you’re in the interview loop. These are people that you’re going to be working closely with. So, start there. Do your discovery questions, and if there’s an area that you think you want to dig, you can ask. There’s no harm asking, “Hey, can you put me in touch with an engineering manager who’s working on the same problem?” And if no one else is asking, again, you’re going to have an extra piece of feedback from that eng manager. So, yeah, like this guy asks really good questions, and it seems like they’re really with it. No one else is going to have that piece of feedback. So, during the debrief process.
Lenny Rachitsky: And just asking that question alone will show them how deeply you’re thinking about this already?
Nan Yu: Yeah.
Lenny Rachitsky: Amazing. Nan, is there anything else that we have not covered that you want to touch on or share or you think might be helpful to listeners before we get to a very exciting lightning round?
Nan Yu: I have a very specific point of view on deadlines. I don’t know if that’s [inaudible 01:09:34] you care.
Lenny Rachitsky: Let’s do it. Fire away.
Nan Yu: I think what often happens is people get depressed about deadlines. It’s like, “Hey, here’s the ship date,” and then you never make it. I don’t know if you’ve had this feeling before.
Lenny Rachitsky: Absolutely, with some deadlines.
Nan Yu: You were an engineer before too, right? So, it’s just like engineers is basically like, “Oh, yeah. Yeah, deadlines, they’re complete fabrications,” and the only way to make deadlines real is to take them so seriously that they are basically like a P0 problem, and everything else has to not matter in comparison to the deadline because that’s the only way you’re going to be able to signal to the team and also to all the stakeholders that you’re actually taking it seriously. So, my feeling on deadlines is don’t have too many of them, and when you do, it’s a P0. So, the engineer is working on it. They don’t get to work on anything else.
It’s like, “Oh, I need them for this,” like nope. Nope. You’re not pulling them off of anything. We’re doing this. As a PM, your job is to just cut as much scope as possible to make it possible to hit that deadline. Like what are the things actually blocking us from doing it? Because what you want to do is at the moment where you have to make the go, no-go call on whether to ship, you want to be able to actually have a product that you can say yes to. It might not have all the features you had wanted or whatever, and you can say no. You can make that choice, but you want to set yourself up to be in a position where you can actually say yes or no to something, because what often happens is like we want this thing. Well, it’s not even close to being done yet, so there’s no possible way we can say yes. I can’t ship it. It’s half broken. It’s like, “No, no, no. You want to get to a point where it works. It might not be the product that you want, but it is an actual real product that you can conceivably ship.”
Lenny Rachitsky: So, you said that don’t have too many deadlines, but when you do, make sure you… Everyone understands these are actual deadlines. When do you decide it’s worth having a deadline? Is it like a marketing launch sort of thing? What’s worthy of a deadline in your experience?
Nan Yu: Yeah, it’s usually having to do with some kind of external marketing type of exercise that you’re try to hit.
Lenny Rachitsky: Got it.
Nan Yu: And I think that that’s the other thing that I think. As builders, we can often look at launch dates and stuff like that. It’s like, “Oh, who cares if it’s a little bit later or we skip this change log,” or whatever it is, and I think that that’s really a… I don’t know. It makes me go crazy when I hear people say that in all honesty. With marketing and communication with customers, you basically have a limited amount of opportunities to do so. A year is 365 days. There are 12 months. Each of those months has about four weeks. There’s some rhythm where you get to have 50-ish weeks to say something to your audience once a week, or you get to have 12 months to say something really big or four quarters to say something huge. If you miss one of those opportunities, you don’t get it back again. You can’t time travel back and say like, “Okay, actually, let’s redo first quarter and say this message that we wish we could have gotten into the field.”
Lenny Rachitsky: That is such a powerful point. I could see the sales marketing, go-to-market element of your job coming out there. I imagine everyone that’s in that field’s like, “Yes, this is exactly right.” Maybe just the last question along this line. So, I love this idea of taking deadlines very seriously when you commit to a deadline. At the same time, as you pointed out, it creates a lot of stress knowing there’s a deadline we have to hit. So, one lever you’ve mentioned is cutting scope. Another is just people spending more time estimating to have more accurate deadlines. You invest in that. How do you think about just for an engineering team to come into a deadline, how much to spend on de-risking and estimating versus just, “Let’s just do our best and then we’ll cut and adjust”?
Nan Yu: This might be my hot take, but we do almost no estimating in order to hit deadlines. What we do is we ship as early as we can. The thing we talked about earlier where if by the time that 10% of the time has elapsed, you have a working thing, you can now spend the rest of the time deciding whether or not you want to do another iteration or you want to polish that thing and get it to be a shippable state. So, you’re setting up your future self to be able to make that decision. So, none of this is… You can’t go into this at the very last moment and say like, “Okay, now, we have to take the deadline seriously.” You have to do it from the beginning and commit to the process of going very fast, iterating early, and then putting yourself in a position where you can say yes or no to a product.
Lenny Rachitsky: So interesting and so different from the way most companies operate. Nan, this was everything I was hoping it’d be. I think this is going to help a lot of people build much better product, which would be good for the world if more products are like Linear. With that, we reached our very exciting lightning round. Are you ready?
Nan Yu: Yeah, let’s do it.
Lenny Rachitsky: Okay, let’s do it. Okay, first question. What are two or three books that you have recommended most to other people?
Nan Yu: I think the one book that I recommend the most is The Design of Everyday Things by Don Norman. I read it originally in college for an HCI class I was taking, and I think of everything I’ve ever read, it’s the thing that caused me to see the world from the perspective of everything you interact with as a product. Every pencil that you use, every door that you open is a product that somebody designed.
Lenny Rachitsky: And is that the big takeaway from that book? Because it comes up a lot, and it’s such an old book. So, I guess for someone that hasn’t read or maybe doesn’t have time to read, it is the big takeaway for you. Someone designed everything and there’s a reason things aren’t great, and they can be improved.
Nan Yu: Yeah. I mean, I saw this the other day. I was at a café in my neighborhood, and I saw a kid rip a handle off a door, like of the café. He pulled it so hard, it came right off because it was a push door, but it had a handle that looked like you could pull it, and that’s one of the canonical examples of the book because [inaudible 01:15:25] are just mysteries. Yeah.
Lenny Rachitsky: Awesome. Next question. Do you have a favorite recent movie or TV show you’ve really enjoyed?
Nan Yu: I watched The Diplomat on Netflix. I think it was terrific. It’s really fun, easy watch. It has some West Wing vibes if you were into that back in the day.
Lenny Rachitsky: Yeah, have you seen the second season?
Nan Yu: Yeah, I finished the second season. Yeah.
Lenny Rachitsky: I wasn’t as excited about the second season, just to put that out there. The first season was really good and then just went off a little like, “Okay. I guess it’s cool,” but stuff like that.
Nan Yu: Yeah, it got a little like spy thrillery, I think.
Lenny Rachitsky: Okay, cool, but still really good and on Netflix. Okay, cool. Do you have a favorite product you recently discovered that you really like?
Nan Yu: I didn’t discover it, but I discovered a version of it that was really interesting. There’s a pen. Actually, I have one on my desk. It’s called the Sakura Micron. I don’t know if you use these. It’s like a felt tip pen. It’s really great. It was originally invented in Japan for artists to draw comic books and stuff, and you can use it for anything. I use it for journaling or whatever, but I was on Amazon. I was trying to buy more, and I found a package that said like, “Bible Study Kit.” I was like, “Why is this labeled Bible Study Kit?” And it was literally just the pen in four different colors, and it was because the thing doesn’t bleed through pages. So, if you have a Bible, which they often have these really flimsy newsprint pages. It’s not going to bleed through.
And it’s just really interesting to me that someone marketed a normal package of these pens as a Bible study kit and for people who were looking for that keyword, and it was official, too. It was not something hacked together. It was actually an official packaging of this.
Lenny Rachitsky: Amazing. What a unique pen choice. Two more questions. Do you have a favorite life motto that you often come back to and find useful in work or in life?
Nan Yu: The correct amount is too much minus one, and I think this ties into the try the extreme version of it of a thing where… I don’t know, like a stupid example, like how much pizza do you want to eat? It’s like, well, five slices was too many. I feel bad. Then four was probably the right number, and then if you want to find the right number, sometimes you just have to really shoot for the edge and then find out what’s too much, and then you’ll find out exactly what the right amount is.
Lenny Rachitsky: I love how tactical that is, makes me think about Elon Musk’s thing about cutting things. Like one of his formulas for just getting stuff done, one of them is just cut stuff before trying to optimize it and automate it, and his advice is if you don’t bring back 10% of things, you cut, you’re not cutting enough.
Nan Yu: Yeah, exactly.
Lenny Rachitsky: Final question. You worked at Everlane for a number of years, and you shared the rough idea of a story around a shirt, maybe a bestseller that they have now, and how you helped create a bestselling women’s shirt. Can you share that story?
Nan Yu: Yeah. So, I mean, to be clear, I witnessed the creation. I don’t think I had a direct hand in it, but yeah. So, I saw this advertisement the other day on Instagram for… It’s called the Women’s Box-Cut Tee, and it’s a wide and short for women, and I looked, and it had 20 colors of it, and it sells super well, and I remember when we created this thing, and it was because there was a batch of defective men’s t-shirts. They all came in an inch and a half too short. So, we couldn’t sell them. You would have your belly button sticking out. No one wants to wear of that. So, what we did was like, well, we have to salvage the inventory because we were a very small company, and we had to make cash flow, and we couldn’t just damage it out.
So, the design team and the marketing team came together, and they said, “Okay. Here’s what we’re going to do. We’re going to cut another two inches off of this and make it really cropped and market it towards women as like a cropped boxed-tee silhouette, and we did that. We’re like, “Okay, hopefully, we can salvage this inventory and not have to take a write-down.” It sold out in a week, and we’re like, “Oh, okay. I guess we just made a hit product,” and it’s one of these things where it’s very hard to know what this was. Was this a marketing thing? Was this a design thing? I don’t know, but you just come together, and you find the right product market fit in the weirdest way.
Lenny Rachitsky: I love that it’s still going.
Nan Yu: Yeah, it’s still going. Originally, it was just white. Now, there’s like 20 colors.
Lenny Rachitsky: Oh, man. I love how many industries you have worked in: fashion, data analytics, project management. I don’t know what’s next. There’s more, I imagine. Nan, this was incredible. I really appreciate making time for this. Like I said, I think we’re going to have helped a lot of people build better products. Two final questions, where can folks find you online if they want to reach out and learn more? And how can listeners be useful to you?
Nan Yu: Yeah, I’m on X/Twitter as the thenanyu. It’s T-H-E and then my name, and if they have any feedback about Linear, we’re very happy to take it, especially for people who use it in their day-to-day. We really want to hear from users.
Lenny Rachitsky: What’s the best way for them to share that? Is it tweet at you? Is it go to the website? What do you recommend?
Nan Yu: Oh, yeah. You can tweet at us. You can DM me on Twitter. My DMs are open, so it’s all good.
Lenny Rachitsky: Amazing. Nan, thank you so much for being here.
Nan Yu: Yeah, of course. Thanks, Lenny.
Lenny Rachitsky: Bye, everyone.
Thank you so much for listening. If you found this valuable, you can subscribe to the show on Apple Podcasts, Spotify, or your favorite podcast app. Also, please consider giving us a rating or leaving a review as that really helps other listeners find the podcast. You can find all past episodes or learn more about the show at lennyspodcast.com. See you in the next episode.
Glossary
| English | 中文 |
|---|---|
| 11-star experience | 11 星体验（Brian Chesky 提出的设计思维方法，指想象极致用户体验） |
| AE | AE（Account Executive，客户经理） |
| Airbnb | Airbnb（公司名称，保留原文） |
| B2B | B2B（企业对企业，保留原文） |
| backlog | backlog（待办事项队列，保留原文） |
| Brian Chesky | Brian Chesky（Airbnb 联合创始人兼 CEO，保留原文） |
| Capacity planning | 资源容量规划（根据可用人员与资源进行项目分配的规划方法） |
| changelog | changelog（变更日志，保留原文） |
| channel strategy | channel strategy（渠道策略） |
| COO | COO（首席运营官） |
| CRM | CRM（Customer Relationship Management，客户关系管理系统） |
| crossing the chasm | 跨越鸿沟 |
| CSM | CSM（Customer Success Manager，客户成功经理） |
| Customer Requests | Customer Requests（Linear 功能名称，保留原文） |
| demand gen | demand gen（需求生成，市场获客手段） |
| discovery | discovery（探索/发现，产品管理中指需求调研和问题发现的过程） |
| double triangle | 双三角（double triangle，Linear 内部协作模型，指产品-工程-设计与产品-销售-市场两个三角） |
| Everlane | Everlane（品牌名称，保留原文） |
| GA | 正式发布（GA, General Availability） |
| go-to-market | go-to-market（推向市场，指产品从构建到交付给客户的完整过程） |
| Hikaru | Hikaru（国际象棋特级大师 Hikaru Nakamura，保留原文） |
| IC | IC（Individual Contributor，个人贡献者） |
| Jeffrey Moore | Jeffrey Moore（ Crossing the Chasm 作者，保留原文） |
| Jira | Jira（产品名称，保留原文） |
| job to be done | job to be done（待完成的任务，产品管理中常用的需求分析框架） |
| Karri | Karri（Linear 联合创始人 Karri Saarinen，保留原文） |
| Linear | Linear（产品名称，保留原文） |
| Magnus Carlsen | Magnus Carlsen（国际象棋世界冠军，保留原文） |
| Mode | Mode（产品名称，保留原文） |
| MySpace | MySpace（产品名称，保留原文） |
| OKR | OKR（Objectives and Key Results，目标与关键结果） |
| opinionated | opinionated（理念鲜明/强主张，指软件有明确的使用方式引导，而非无差别满足所有需求） |
| Patrick Collison | Patrick Collison（Stripe CEO 及联合创始人，保留原文） |
| Paul Graham | Paul Graham（Y Combinator 联合创始人，保留原文） |
| PM | PM（Product Manager，产品经理） |
| PMM | PMM（Product Marketing Manager，产品市场经理） |
| product market fit | 产品市场契合度 |
| release notes | release notes（发布说明，保留原文） |
| SaaS | SaaS（Software as a Service，软件即服务） |
| Sakura Micron | Sakura Micron（日本品牌针管笔/毡尖笔，产品名称，保留原文） |
| SAML | SAML（安全断言标记语言，一种单点登录协议） |
| schlep blindness | schlep blindness（苦差盲区，Paul Graham 提出的概念，保留原文） |
| SCIM | SCIM（跨域身份管理系统，一种用户身份管理协议） |
| Stripe | Stripe（公司名称，保留原文） |
| The Diplomat | 《头号外交官》（The Diplomat，Netflix 政治题材剧集） |
| Triage Management | Triage Management（分流管理，Linear 功能名称，保留原文） |
| triage queue | triage 队列（对问题/需求进行分类、优先级排序的队列） |
| West Wing | 《白宫风云》（West Wing，美国政治题材电视剧） |
| Women’s Box-Cut Tee | Women’s Box-Cut Tee（Everlane 产品名称，女士宽短款 T 恤，保留原文） |
Reformatted by reformat_english.py