上下文成了产品:当软件能自己构建自己时的产品领导力——Karri Saarinen(Linear)

• Linear 的 Karri Saarinen 开场先讲自己的夏天：他放了个假，不再追最新模型、agent 和新技巧，本以为回来会被甩在后面，结果「其实没怎么变」——新东西都有，但做出好产品、把收入做上去，还是一样难。→ 详细
• 由此抛出全场的问题：工具确实越来越强，可我们真的用它做出更好的东西了吗？团队变好了吗？他不认为答案是明明白白的「是」——你怎么知道？你的客户有这感觉吗？→ 详细

▲ 图注：幻灯片「We spent decades optimizing the software factory.」——右侧是一张厂房里成排工人伏案作业的黑白老照片，底部一行写着 MORE PEOPLE → MORE PROCESS → MORE EXPERIMENTS → MORE OUTPUT，正是他口述的那条链条。

• 软件工厂（把组织当流水线、想办法放大产出的思路）当天已有好几场演讲在讲。Karri 说行业对它着迷很久了，AI 之前就开始：招更多人 → 设出很细的专门岗位、各干各的 → 人多了加流程 → 搞不清大家在做什么、该做什么 → 于是跑实验，让数据说什么管用。全是为了更多产出。→ 详细
• 他的理念是「产出更多不等于更好」，要的是给客户更好的体验。建工厂、做自动化都说得通，但组织自己「别变成软件工厂」——别把活儿和思考都外包出去、只盯产出效率，「因为产出不是产品」。→ 详细

• 客户买的不是代码行数，也不是实验；想卖出东西，就得做出有人想要的东西。→ 详细
• 做产品会产出两样东西：产品和学习。琢磨「该做什么、怎么做、长成什么形态」时你会问出一堆问题，自己答、找人聊、找客户聊——这份力气本身在教你问题是什么、客户要什么。现在的危险是丢掉和这种学习的直接联系。→ 详细

▲ 图注：幻灯片「Great product organizations compound understanding.」——六只 F1 方向盘分两排，上排三只是传统圆形（年份标 1969 / 1974 / 1988），下排三只是布满按钮旋钮的异形方向盘（1999 / 2008 / 2014）；底部一行 CUSTOMER · PRODUCT · TECHNOLOGY · JUDGMENT · TASTE · HISTORY，对应他列的那几样上下文。

• 论证的支点：你敬佩一家公司的产品，多半也敬佩它的团队。团队越懂自己所在的领域、技能越强、品味越好，做出来的东西就越好。伟大的公司能持续做出好东西，是因为围绕「怎么想问题、什么重要、什么不重要」攒下了一整套文化和上下文。→ 详细
• 他把「上下文」拆成具体几样：对客户、对所在产品领域、对能用的技术的认识；团队做决策时用的判断力；分辨出什么是好的那份品味；以及试过的各种东西、做过的各种决定的全部历史。所以他讲的上下文是一个团队「懂」的总和，不只是客户资料。→ 详细
• 幻灯片用 Formula 1 赛车的方向盘示意这种复利式的学习积累：一开始是很传统的样子，几十年下来车队一点点学会把它做成真正适合这个场景的东西——F1 不需要很大的转向幅度，要的是高速下大量小幅度、非常精细的操控，所以方向盘最后长得和普通汽车完全不一样。→ 详细

▲ 图注：幻灯片左右两栏——左「Automate the known」（已知的交给自动化）：自动修 bug 和报错、分拣进来的工作、回答产品问题；右「Invest people in the unknown」（把人投到未知里）：客户问题、探索、判断力、质量、新的产品方向。

• 产品组织现在的危险：越把事情交给 AI、越要求团队用 AI，就越把执行和学习分开。Karri 说这不一定是坏事，但如果你公司里正在发生，你打算怎么补？不从自己做的工作里学习，最终会丢掉现有的优势。→ 详细
• 分界线：重复性的、从里面学不到太多的事适合自动化。Linear 的例子是修 bug——agent 连上 Datadog、Sentry（线上监控和报错追踪工具）等工具，翻代码库找出 bug 的来源，再写出修复；工程师只需核对结果，有时做点小改动。幻灯片把同一条线写成两栏，见上图。（Linear 自己做 agent 的经验见 ep138。）→ 详细
• 原则一句话：用新工具把时间省下来，但不把所有事情都外包出去。→ 详细

• 团队该多花时间的地方是客户和客户的问题。Linear 从创立之初就推工程师和所有成员直接接上客户：加入和客户共享的 Slack 频道，回答问题、也向客户提问，靠这个养出客户直觉。→ 详细
• 工程或其他岗位省出时间后，他先列了四个去处：多和客户在一起、多做探索、锻炼判断力、做出比以前更高质量的工作。→ 详细
• 讲完下面三个机制后，他把这一点升成了对全场的请求：现在的默认想法是「AI 能干很多事，那就更高效、多产出」，可如果 AI 真省了时间，正好把它花到别处——客户、探索、评议、质量，以及对自己所做之事的反思。未来的产品组织也许会少花时间在执行上，往更抽象一层走，去想「我们作为一个团队怎么变得更好」。→ 详细
• 目标是让学习循环一直转：拥有上下文 → 从中带出信号 → 把学到的带给整个团队和公司。AI 可以是这件事的好工具，只是「大家盯着的是 AI 能做什么、能执行什么，而不是 AI 能教你什么」。→ 详细

▲ 图注：幻灯片里 Linear 界面的局部放大——面包屑「Loops › Daily AI customer insights」，时间「Today at 8:00 AM」，正文以「@karri AI customer signals from the last day:」开头，下面三条信号的标题是 Composable, governed Agent skills、Agent-to-code context and escalation、MCP auditability and external-agent collaboration；客户名在幻灯片上已打码，右侧被裁，小字只能读到半句。

• 先有底座：Linear 把能收集到的客户信息全收起来——用自动化从销售电话和其他会议里拉客户反馈，也从客服邮件和内部讨论里拉，攒成一个专门「放客户上下文的地方」。用他的话说，是「用 AI 来帮我们搭建这份上下文」。→ 详细
• 要治的病：产品组织、尤其是大组织里，很多人会慢慢离客户的日常问题越来越远——量太大，你没时间逐个跟进，也没法把每一封邮件、每一条需求都看一遍。→ 详细
• 他的做法：放一个 watcher（负责盯梢的 agent）盯着这堆上下文，一有他可能感兴趣的就告诉他。他设的其中一份是关于 AI 工作流的每日简报——「客户都在怎么说他们的 AI 工作流？」选这个题是因为各家公司做法差别非常大，「还没有什么明确的最佳实践」，他想弄清三件事：大家用这些工具的方式有哪些、想从 Linear 得到什么、Linear 怎么更好地帮到他们。→ 详细
• 成本很低：简报通常就几条要点，读一下占不了一天里多少时间，但基本上每天都有一份。→ 详细

▲ 图注：幻灯片左右两栏——左「Feature Roasts」：15–30 分钟的会、全团队都能评议这个功能、把意见写进文档、项目负责人综合反馈；右「Quality Wednesday」：每周工程师花约 30–60 分钟修掉产品里的一个小瑕疵，更大的影响是团队练出了在上线前就注意到质量问题的眼力。

• 背景与起因：公司用 AI、用 agent 越多，人就越各干各的——很多人是一个人带着自己的 agent 在做东西，高效，但大家不再互相学习了；他把下面两个做法归在「判断力」这一侧。Quality Wednesday 的直接起因则是不断招人后发现，不是每个人对「质量到底意味着什么」的理解都一样。→ 详细
• 规则：给每个人布置一个任务——每周花点时间进产品里看一看，找出一个质量缺陷并修掉。可以非常小：一个怪怪的 hover 状态（鼠标悬停时的样式）、一段卡顿的动画、一处文案错误，「可能就是个五分钟的修复」。他口头说的是「每个人」，幻灯片上写的是工程师每周花约 30–60 分钟。（同场峰会专讲品质与匠心的一段见 ep241。）→ 详细
• 真正的收益不在修复本身，而在每个人都在训练自己的眼睛去注意小毛病。而且这件事放在一个会上做：每个人分享自己发现了什么、怎么修的，其他人就能看到「别人是怎么发现这些问题的」。→ 详细

• 形式：针对新功能的一个自愿参加的会，公司里任何人都可以来，由正在做这个功能的团队主持，请大家把整个功能从头到尾评议一遍。「你想多挑剔就多挑剔，想多困惑就多困惑」，把最原始的反馈丢出来；规矩是不针对个人，只是「我看到的就是这样」，团队可以当场追问。上一节幻灯片的左栏补了两个细节：会只开 15–30 分钟，意见记进一份文档。→ 详细
• 两个目的 + 一个收口：一是训练大家明白什么才重要、公司在乎什么；二是让做功能的团队更真实地看到用户会怎么想——对公司里很多人来说这是头一回见到这个功能，「如果他们看得一头雾水，用户多半也会一头雾水」。会后负责人把反馈综合、归类，整理成可以动手处理的 issue（工单）去修。→ 详细
• 为什么非得一起做：会上有讨论，每个人都在互相学。之后你做自己的功能时会想起某一次讨论——「哦，那个人总是特别在意 onboarding」（新用户上手引导），或者在意某个动画——于是提前去查那一块，免得又收到同一条反馈。→ 详细

• 他重申：公司往往就是对所做的工作、所解决的问题的理解，一点点复利累积出来的。所以你得有个地方来放这些东西，让人可以去了解客户上下文、了解你们的产品思考、了解你们在做的任何其他事情。→ 详细
• 这个地方「对人很重要，对 agent 也同样重要」。他现在常直接问 agent：「关于这个我们手上有什么？」或者「给我讲讲客户的情况——他们在说什么、在做什么，团队又是怎么回应的」。agent 在这里不是替他干活，而是把攒下的上下文讲给他听。→ 详细
• 他要的是一个共享空间，里面住着三类上下文：围绕客户的、围绕产品的、围绕产品正在发生的那些工作的。（「给 agent 备好上下文」这条线，另见 ep165、ep194、ep70。）→ 详细
• 收尾的立场：工具会继续进步，我们也会继续盯着它、继续自动化；但该自动化的是「已知的事」——可重复、影响没那么大、学不到太多的事。他希望把更多时间用来建立对自己所做之事的理解，确保团队是在「从某件事、某个人、某个地方学到东西」，而不只是在执行下一个原型、下一个想法。→ 详细

• 原话是「我们在 Linear 是不跑实验的，我们让大家用自己的直觉」。但他常跟人说，直觉不是《星球大战》里那种莫名其妙降临到你身上的神奇力量，它是你在做事、听客户说话的过程中学来的——「直觉基本上就是你大脑里已经有的那份训练」。所以学到、听到、看到的上下文越多，个人的理解就越会复利累积，最终带动整个团队的理解。→ 详细

• 题眼：我们总盯着产出看——软件也好、代码也好。Karri 往另一个方向看：到底是什么在创造软件？谁在做决定？是人。这些人拥有的上下文越好、对自己该做什么理解得越透，产品就越好。→ 详细
• 所以在 Linear 他一直认为招人是做出好产品的第一步。很多人招人时想的是「招个人来干某件事、把产出提上去」，真正该想的是这个人能给公司带来怎样的轨迹：有什么样的想法？有没有对的判断力或品味？在这个组织里怎么用起来？→ 详细
• 结论：产品组织会有越来越多的工作是在管理上下文——从中学习，想办法让团队聚到一起、从中学习，而不是真的去执行代码、把那个东西造出来。「这就是我说的『上下文成了产品』的意思。」同场峰会的另外几段从别的角度回答了同一个问题（同批 254 / 256 / 257）。→ 详细