大家下午好。今天我想谈谈伟大的产品、上下文以及我们从事的产品工作。但首先，我想聊聊我的暑假。今年夏天我暂停了对人工智能的关注。我不再像以前那样追踪新闻，比如最新模型是什么、它能做什么、我们有哪些智能体以及我们可以使用哪些新技术。当我在度假时，我心想：等我回来时，也许我会觉得自己落后了，因为情况可能发生了巨大变化。

但当我回来后我意识到，其实并没有发生太大变化。有新模型、新技术和新智能体出现，但归根结底，打造卓越产品、增加收入或构建业务仍然很难。这让我反思我们究竟在多大程度上真正关注这些工具。我们经常全天候地注视着各种工具，总有新事物可以尝试，显然这些工具正在变得更好、功能更强、速度更快、能力更高。

但更重要的问题是：我们是否真的利用这些工具做出了更好的东西？我们的团队是否通过这些工具变得更强了？我认为答案并不明确。如果你放眼外界，甚至审视你自己的公司，你怎么知道你们是否真的做出了更好的东西？你感觉是这样吗？你的客户有这种感觉吗？

现在有很多关于工具制作、使用工具和构建系统的强调。但作为产品人员，我认为我们的工作是做出好的东西。因此，在某种程度上，今天有几场演讲提到了“软件工厂”，我认为行业长期以来一直痴迷于这个理念：如何规模化并优化组织所产出的成果。

这听起来合理，快速行动和做事确实很重要。但这在人工智能出现之前就已经开始了。我认为在 AI 时代之前，理念是我们需要雇佣更多的人，创建非常专业化的角色让他们各自工作。因为人多了，我们就建立了更多的流程；而有了流程和大量人员，我们甚至不再清楚人们到底在做什么或应该做什么。

于是我们通过运行实验来依靠数据告诉我们什么有效、什么无效，这一切都是为了规模化：如何从组织中获得更多产出。但我一贯的理念是：更多的产出并不等于更好。我认为我们要构建的是为客户带来更好的体验。我今天的一个观点是，你可以建立软件工厂、制造产品并实现自动化，这都很有道理。

但作为一个组织，不要让自己变成那样。不要成为一个软件工厂，将所有的工作和思考外包给其他地方，只关注产出的效率有多高。因为产出并不是产品。客户购买的不是代码行数，他们不购买实验或许多其他东西。归根结底，如果你想出售某样东西或制造出好产品，你必须做出有人想要的东西。

当我思考“创造”这件事时，我会想到两个方面：制造产品会产生两样东西——产品本身和学习成果。历史上，构建或设计产品总是伴随着学习的产生。当你挣扎着思考该建造什么、如何建造、走哪条路、它呈现何种形态时，你会提出各种问题并尝试回答。

也许你自己寻找答案，或者去与人交谈、与客户交流以寻求解答。因此，你在构建事物上投入的实际努力，也会教会你关于问题本质、客户想要什么或他们的观点等方面的知识。我们目前正处于一个危险时期，可能会失去与这种直接学习联系的纽带。

我认为，如果你观察任何伟大的公司或创造伟大产品的企业，你可能尊重他们的产品，但你也可能同样尊重他们的团队。显然，产品是由公司里的团队生产出来的。团队越好，他们对所处领域的理解就越深刻，他们的技能或天赋就越高超，品味也更好，因此他们构建的东西也就越好。

伟大的公司之所以能持续做出卓越的事物，是因为它们拥有围绕如何思考事物而建立的文化与上下文：什么重要、什么不重要。这包括所有关于客户、他们所处的产品领域、可用的技术、团队做决策时使用的判断力以及品味，还有过去尝试过的不同事物或做出的决定的历史。

这里的图片只是这种累积式学习的一个插图，展示了一个 F1 赛车方向盘。它最初采用非常传统的形式，但几十年来，团队学会了如何真正使其变得更好，并打造出适合这种用例的东西。F1 赛车不需要很大的转弯半径，因此需要大量的微小动作以及在高速下控制车辆。

那是非常精细的动作，这就是为什么实际的方向盘与我们通常在汽车上看到的不同。目前产品组织真正的危险在于：我们将更多工作自动化交给 AI，或告诉团队使用 AI 时，你实际上是在执行与学习之间制造了分离。

这并不一定是坏事；我指出这一点是因为，如果这种情况在你的公司发生，你打算如何修复它？如果你不从所做的工作中学习，我认为最终你会失去目前在你的领域或公司中拥有的优势。我们可以这样思考：什么是适合自动化的？什么是由人来做的更好？

我认为肯定有一些事情是重复性的，也许人们不会从中学习到太多关于某事的知识。例如在 Linear 我们现在如何处理错误修复？我们使用“Winner Loop”来调查 bug，它会连接数据进行操作。

Sentry 和其他工具会尝试深入代码库，理解 bug 的来源并编写修复方案。这为工程师节省了时间，他们无需再调查问题，只需验证结果并进行少量调整即可。现在的核心思路是：如何利用这些新工具节省时间，同时避免将所有工作外包出去？

我认为团队应将更多精力投入到客户领域和客户问题上。从公司成立之初，我们就一直推动工程师和团队成员深入接触客户：加入 Slack 频道、回答问题并主动提问。通过这种方式与客户保持紧密联系，从而培养对客户直觉的理解。

如果工程或其他角色因 AI 节省了时间，他们可以在这些方面投入更多：与客户相处、探索新事物、训练判断力或产出更高质量的工作。未来产品组织的真正目标，是如何保持这种学习循环：如何获取上下文、从上下文中提取信号并将这些经验教训传递给整个团队和公司。

我认为 AI 在此过程中可以成为极好的工具。很多时候，人们只关注 AI 能做什么、执行什么任务，却忽略了 AI 能教会你什么。例如在 Linear，我们利用 AI 帮助构建这种上下文环境。

我们收集所有能获取的客户信息。通过自动化流程，从销售通话、其他会议以及支持邮件和内部讨论中提取客户反馈。这构建了一个集中存放上下文和客户洞察的平台。

近期我开始推行的一项做法是：过去在产品组织中，尤其是大型团队里，人们往往因日常问题繁多而远离客户实际痛点。由于时间有限，大家无法跟进每个人、查看每封邮件或每个请求。

为此，我收集了所有上下文数据，并部署了一个“观察者”智能体来监控这些信息。当出现对我有价值的内容时，它会通知我。例如，我设置了一个关于 AI 工作流的每日简报：客户对 AI 工作流有何评价？

我想从中学习更多，因为我看到许多公司以截然不同的方式处理此事。目前似乎没有明确的最佳实践，每家公司做法各异。因此我试图了解人们使用这些工具的各种方式、他们的需求以及我们如何更好地帮助他们。

这每天只需花很少时间阅读，通常只有几个要点。我收到一份每日简报，概述客户对 AI 工作流的看法。在判断力训练方面，我想强调我们做的几件事。

我注意到，随着公司越来越多地使用 AI 和智能体，人们开始孤立自己：许多人独自与智能体协作构建事物。这虽然高效，但也带来了不再互相学习、缺乏交流的问题。

为此我们开始推行“质量周三”活动，原因是随着招聘新人，我们发现并非所有人都具备相同的质量标准或对质量的认知。我们要求每个人每周花些时间检查产品，寻找一个质量缺陷并修复它。

这可以是很小的问题：奇怪的悬停状态、卡顿的动画或文案错误等，无需大型项目，可能只需五分钟修复。其更大影响不在于我们做了这些修复，而在于团队通过此活动训练自己：培养发现细微错误的敏锐度。

由于我们在会议中进行，每个人分享发现和修复方案，大家可以从中学到如何发现这些问题。对于新功能，我们还进行“功能吐槽会”。这是一个可选会议，公司任何人可加入构建该功能的团队。

参与者只需对功能进行批评：可以挑剔、困惑或提出任何意见，提供原始反馈而非人身攻击。团队仍可互动并询问不理解之处。这旨在训练人们关注重点，并以更真实的方式让构建团队了解用户可能的想法。

对公司许多人来说，这是他们首次看到该功能。如果他们感到困惑，用户很可能也如此。随后负责人会综合反馈、归类并制定可执行的问题清单进行修复。

重要的是，这些活动是共同完成的，会议中的讨论让每个人互相学习。当你构建自己的产品或功能时，你会想起之前的讨论：记得某人总是关注引导流程或特定动画。因此我会检查这些细节，以避免收到类似反馈。

我们的理念是：虽然 AI 能处理大量事务并提高效率、增加产出，但如果 AI 真正高效且节省了时间，或许我们有机会将这部分时间投入到其他事情上。

在执行力方面，我们可以开始更多地关注客户、探索性研究、批判性反馈以及工作质量，甚至是对我们所做工作的反思。我认为在未来，产品组织的性质可能会发生变化：我们将不再将大量时间耗费在执行层面，而是转向更加抽象的思考——思考我们实际从事的活动。例如：团队如何变得更好？产品组织如何实现进化？

正如我之前所说，我认为公司往往缺乏对“工作”与“所解决问题”的复合式理解。因此，我认为至关重要的一点是：必须建立一个专门的空间或机制来沉淀这些知识。这个空间应当可用于学习客户背景、理解产品思维，或者掌握其他任何相关领域的信息。

这不仅对团队成员重要，对于AI智能体（Agents）也同样关键。现在我经常向智能体提问：关于这一点我们有哪些积累？或者教我一些关于客户的事情——他们在说什么、在做什么，以及团队是如何回应的。我认为，创建一个共享空间非常有价值，让关于客户、产品及围绕产品开展的工作的上下文信息在此汇聚。

最后我想说：工具会不断进步，我们会持续观察这些工具，自动化程度也会越来越高。但我认为，我们应该将更多精力投入到自动化那些已知的、可重复的、且可能影响力不大的事务上，因为从这些工作中我们很难学到太多新东西。

我的希望是：我们能花更多时间去构建对公司或产品组织的深层理解；确保团队能从某些事物、某人或某处汲取经验，而不仅仅是执行下一个原型或想法。在Linear，我们不单纯依赖实验；我们鼓励人们运用直觉。但我常提醒团队：直觉并非《星球大战》中那种神秘的魔法力量，它不是凭空降临的。

直觉是你通过工作、倾听客户或观察其他事物而积累的学习成果。它本质上是你在大脑中形成的训练结果。因此，你学习得越多、倾听和观察的上下文越丰富，你的个人理解就越深厚。最终，这种积累会复利式地增强整个团队的理解力。

这次演讲的核心观点是：上下文即产品。我们往往痴迷于关注产出——无论是软件还是代码，但我认为应该换个视角：是什么在驱动软件的诞生？是谁在做决策？是人。如果这些人拥有更好的上下文和更清晰的目标认知，那么产品就会更好。

在Linear，我一直认为招聘是打造伟大产品的第一步。这看似显而易见，但有时人们会误以为招聘只是为了完成某项任务或增加产出量。实际上，你真正应该思考的是：这个人能为公司带来怎样的发展轨迹？他们具备什么样的想法、判断力或品味？以及如何在组织中运用这些特质。

最终，我认为产品组织将更多地围绕“上下文”展开：工作重心将从单纯执行代码或构建功能，转向管理这些上下文——从中重新学习、寻找团队共同协作并从中学到经验的方法。这就是我所指的“上下文即产品”。