Linear CEO Warns AI Automation Erodes Team Product Judgment

Context is now the product: Product leadership when software can build itself | Karri Saarinen — Lenny's Podcast

Lenny's Podcast

Outsourcing software execution to AI severs the hands-on learning loop that trains product intuition, requiring companies to reinvest saved engineering hours into shared critiques and customer intelligence rather than shipping more code.

AI-assisted summary of Context is now the product: Product leadership when software can build itself | Karri Saarinen — original source. Check the original for full context.

Source published:

Key ideas

  • While AI tooling accelerates code generation, raw output volume remains a false proxy for value because customer demand depends on product quality, not organizational throughput. (1:47)
  • Product building yields two outputs—the artifact itself and institutional learning; delegating core problem-solving entirely to AI risks severing the feedback loop that trains human judgment. (3:24)
  • Linear confines AI automation to mechanical, low-learning tasks like cross-platform bug diagnosis, reinvesting the saved engineering hours into direct customer exposure and craft polish. (5:47)
  • To counter developer isolation caused by autonomous tools, Linear utilizes shared rituals like Quality Wednesday defect fixes and unvarnished company-wide Feature Roasts to align design taste. (10:36)
  • Product leadership must shift focus from overseeing task execution to curating the shared context that grounds both human intuition and automated agents. (13:11)

Detailed notes

## Background Published on YouTube by Lenny's Podcast on September 29, 2026, this video features Linear co-founder Karri Saarinen speaking live at the Lenny and Friends Summit in San Francisco. The talk explores how product leadership must evolve as software development automates, arguing that enduring products depend on the context and judgment teams build through direct customer feedback, shared critiques, and hands-on craft.

## TL;DR Karri Saarinen challenges the tech industry's rush toward automated 'software factories,' warning that outsourcing core problem-solving to AI risks decoupling execution from the institutional learning that trains product intuition. He advocates using AI selectively for low-learning maintenance tasks and synthesizing qualitative customer feedback, while deliberately protecting human judgment from isolated work silos. Through practices like weekly 'Quality Wednesdays' and unvarnished 'Feature Roasts,' Linear systematically trains collective taste across the organization. Ultimately, Saarinen argues that context itself is the product, urging teams to reinvest AI-driven efficiency into customer discovery, craft, and shared decision-making rather than churning out more code.

## Atmosphere & style The talk carries a calm, deliberate, and contrarian clarity that cuts cleanly through relentless AI hype. Saarinen speaks with measured practitioner authority, delivering an introspective keynote that feels less like a speculative conference presentation and more like a principled manifesto for product craft. The mood is grounded and candid, encouraging builders to step back from the sprint for sheer output to reflect deeply on how organizational taste, intuition, and quality are actually cultivated.

## Bulletin - [01:47](https://www.youtube.com/watch?v=Zn9NZ-r1-C4&t=107s) While AI tooling accelerates code generation, raw output volume remains a false proxy for value because customer demand depends on product quality, not organizational throughput. - [03:24](https://www.youtube.com/watch?v=Zn9NZ-r1-C4&t=204s) Product building yields two outputs—the artifact itself and institutional learning; delegating core problem-solving entirely to AI risks severing the feedback loop that trains human judgment. - [05:47](https://www.youtube.com/watch?v=Zn9NZ-r1-C4&t=347s) Linear confines AI automation to mechanical, low-learning tasks like cross-platform bug diagnosis, reinvesting the saved engineering hours into direct customer exposure and craft polish. - [10:36](https://www.youtube.com/watch?v=Zn9NZ-r1-C4&t=636s) To counter developer isolation caused by autonomous tools, Linear utilizes shared rituals like Quality Wednesday defect fixes and unvarnished company-wide Feature Roasts to align design taste. - [13:11](https://www.youtube.com/watch?v=Zn9NZ-r1-C4&t=791s) Product leadership must shift focus from overseeing task execution to curating the shared context that grounds both human intuition and automated agents.

## Key takeaways - [00:06](https://www.youtube.com/watch?v=Zn9NZ-r1-C4&t=6s) Rapid advances in AI models and agent frameworks have not changed the fundamental difficulty of creating valuable products and building sustainable revenue. - [01:47](https://www.youtube.com/watch?v=Zn9NZ-r1-C4&t=107s) The traditional enterprise 'software factory' mindset optimizes for headcount, operational processes, and raw output rather than building what customers actually want. - [03:24](https://www.youtube.com/watch?v=Zn9NZ-r1-C4&t=204s) Execution is the primary engine of team development, producing both the software itself and the compounding domain knowledge required to make sound decisions. - [03:24](https://www.youtube.com/watch?v=Zn9NZ-r1-C4&t=204s) The decades-long evolution of the Formula 1 steering wheel demonstrates that specialized, high-quality design emerges strictly from repeated, hands-on execution. - [05:47](https://www.youtube.com/watch?v=Zn9NZ-r1-C4&t=347s) Indiscriminately outsourcing problem-solving to AI agents risks stripping teams of their hard-earned competitive advantage and institutional memory. - [05:47](https://www.youtube.com/watch?v=Zn9NZ-r1-C4&t=347s) Linear automates low-learning maintenance tasks—such as tracing telemetry logs and generating draft PRs—while requiring human engineers to verify fixes and make final adjustments. - [05:47](https://www.youtube.com/watch?v=Zn9NZ-r1-C4&t=347s) Efficiency gains from AI should not be absorbed into writing more code, but reinvested upstream into user discovery, craft refinement, and edge-case testing. - [08:00](https://www.youtube.com/watch?v=Zn9NZ-r1-C4&t=480s) AI agents are effectively utilized as qualitative filters, ingesting sales recordings and support tickets to deliver concise daily customer intelligence briefings to leaders. - [09:47](https://www.youtube.com/watch?v=Zn9NZ-r1-C4&t=587s) Heavy reliance on autonomous AI coding tools threatens team cohesion by pushing engineers and designers into isolated work silos that halt collective critique. - [10:36](https://www.youtube.com/watch?v=Zn9NZ-r1-C4&t=636s) Linear's weekly 'Quality Wednesday' calibrates the entire company to a uniform standard of polish by having every employee find, fix, and present a defect resolution. - [10:36](https://www.youtube.com/watch?v=Zn9NZ-r1-C4&t=636s) Company-wide 'Feature Roasts' recreate genuine first-time user friction by encouraging open, unvarnished peer criticism on unreleased work. - [13:11](https://www.youtube.com/watch?v=Zn9NZ-r1-C4&t=791s) Centralizing context in accessible company repositories grounds human decision-making and allows AI agents to accurately interpret historical reasoning. - [14:49](https://www.youtube.com/watch?v=Zn9NZ-r1-C4&t=889s) Product intuition is neither innate nor mystical; it represents accumulated cognitive training gained through direct customer exposure and active peer review. - [14:49](https://www.youtube.com/watch?v=Zn9NZ-r1-C4&t=889s) Because product quality is dictated upstream by decision quality rather than downstream code generation, organizational context is now the true product.

## Detailed walkthrough ### [00:06](https://www.youtube.com/watch?v=Zn9NZ-r1-C4&t=6s) The AI Hype Cycle vs. The Reality of Product Building

Karri Saarinen opens his talk by sharing a personal experiment from the past summer: he intentionally disconnected from the relentless AI news cycle. He completely stopped tracking the latest model releases, agentic frameworks, and new development techniques to see what would happen. Expecting to feel completely left behind upon his return, he instead discovered that very little had fundamentally shifted. While the underlying models, agents, and tool capabilities continue to advance at a rapid pace, the core reality of building successful products, driving revenue, and establishing a sustainable business remains as difficult as ever.

This realization prompted Saarinen to question the industry's collective fixation on tooling. Software teams are constantly monitoring new tools, marveling at how much faster and more capable they are becoming. However, Saarinen challenges whether these systems actually result in better products or elevate the capabilities of the teams using them. When companies look critically at their output and talk to their customers, the answer is rarely an unambiguous "yes." In his view, product leaders have become overly preoccupied with toolmaking and infrastructure when their primary responsibility remains making something genuinely good.

[01:47](https://www.youtube.com/watch?v=Zn9NZ-r1-C4&t=107s) Resisting the "Software Factory" Mentality

Saarinen addresses a prominent theme across tech conferences: the push to turn development organizations into automated "software factories." He notes that this obsession with scaling and optimizing raw output is not new to the AI era. Long before generative models emerged, tech companies attempted to scale output by hiring aggressively, carving out hyper-specialized roles, introducing heavy operational processes, and running endless experiments to dictate product direction. This structural bloat eventually distanced teams from what they were actually supposed to build, substituting statistical A/B test readouts for product instinct.

Saarinen warns organizations against adopting this philosophy wholesale. While building automated systems and streamlining engineering tasks makes operational sense, a team should never define itself as a software factory that outsources critical thinking and judgment in pursuit of sheer output volume. "Output is not the product," Saarinen reminds the audience—customers do not pay for lines of code, volume of experiments, or raw operational efficiency. A company's commercial and creative survival still depends entirely on building something people genuinely want.

- The traditional enterprise playbook—mass hiring, hyper-specialized silos, heavy process, and relying entirely on experiment data—optimizes for output rather than quality. - Delivering sheer volume of code is a false proxy for success because customers buy valuable experiences, not raw organizational throughput.

[03:24](https://www.youtube.com/watch?v=Zn9NZ-r1-C4&t=204s) The Two Outputs of Work: Product and Compounding Learning

Whenever a team sets out to build something, Saarinen argues that it produces two distinct outputs: the product itself, and the learning that occurs during the process. Historically, the arduous process of figuring out what to build, determining its shape, wrestling with trade-offs, and validating hypotheses against user feedback generated deep domain understanding. The very struggle of execution served as the engine that trained product teams, instilling intuition around customer needs and technical constraints.

By shifting too much active thinking and execution to automated systems, teams risk severing that vital connection to learning. Saarinen highlights that the most respected companies are revered not just for their artifacts, but for the teams behind them. Enduring companies succeed because they foster a shared organizational context composed of:

- In-depth customer and domain understanding - Knowledge of relevant technologies and their practical limits - Sharpened decision-making judgment and aesthetic taste - An institutional memory of past experiments, failures, and design trade-offs

To illustrate how domain-specific learning compounds over decades, Saarinen references the evolution of the Formula 1 steering wheel. It began as a conventional round automotive wheel, but through decades of intense racing, teams realized that F1 cars require extremely tight steering ratios and high-speed precision rather than broad turning angles. The wheel transformed into a dense, specialized control interface uniquely tailored to the driver's constraints—an outcome made possible only by compounding, hands-on learning from real-world execution.

```mermaid flowchart TD accTitle: Compounding Learning vs Risk of Decoupling accDescr: Diagram illustrating how execution feeds institutional learning and taste, and where AI automation risks breaking the loop.

subgraph CraftEngine["The Traditional Craft Engine"] A["Hands-on Execution & Problem Solving"] --> B["Compounding Team Learning"] B --> C["Deep Customer Context & Taste"] C --> D["Exceptional Product Quality"] D --> A end

subgraph RiskZone["The Automation Hazard"] E["Outsourcing Execution to AI Without Active Engagement"] -.->|Severing the Loop| B end ```

[05:47](https://www.youtube.com/watch?v=Zn9NZ-r1-C4&t=347s) Decoupling Execution: Automating Repetitive Tasks vs. Preserving Judgment

The emerging hazard for modern product organizations is that indiscriminate automation decouples execution from learning. If a team delegates its core problem-solving to AI agents, it risks losing the hard-won competitive advantage it spent years cultivating. Saarinen argues that leaders must deliberately delineate between what should be automated and what must remain human-driven.

The ideal targets for AI automation are repetitive, low-learning tasks. Saarinen shares how Linear implements this principle for maintenance: when a bug occurs, Linear uses an internal agent loop that investigates the issue across platforms like Datadog and Sentry, pinpoints the root cause in the codebase, and drafts a proposed pull request. Engineers bypass the tedious forensic work while remaining responsible for verifying the fix and making final adjustments. This targeted efficiency gives engineers surplus bandwidth—not to produce more code, but to spend time directly with customers, develop product judgment, explore edge cases, and push for higher craft quality.

- Automate low-signal, mechanical tasks (e.g., bug diagnosis across telemetry services, initial code patches). - Reinvest the reclaimed time into customer problem discovery, design exploration, and quality reviews.

[08:00](https://www.youtube.com/watch?v=Zn9NZ-r1-C4&t=480s) Using AI to Amplify Customer Context and Daily Briefings

Instead of viewing AI solely as an execution engine, Saarinen advocates using it to gather and synthesize context. Linear has long pushed its engineers and product contributors to participate in shared customer Slack channels, field support inquiries, and build firsthand customer intuition. However, as an organization expands, individual team members can easily become overwhelmed by the sheer volume of customer interactions and slowly drift away from ground-level reality.

To solve this, Linear employs AI to ingest qualitative signals across sales calls, meeting recordings, support tickets, and internal discussions. Rather than relying on static dashboards, Saarinen deploys targeted AI "watchers" or agents programmed to monitor this stream for specific themes. For instance, he created a custom daily briefing agent tracking what customers say about their AI workflows. Because there are currently no established industry best practices for AI implementation and teams approach the technology in widely divergent ways, this automated synthesis provides him with high-signal, real-time intelligence directly from the customer base without requiring hours of manual transcript reading.

[09:47](https://www.youtube.com/watch?v=Zn9NZ-r1-C4&t=587s) Daily Briefings and Countering the AI Silo Effect

Karri Saarinen wraps up his discussion of automated customer intelligence by detailing his own daily routine. Rather than wading through endless raw call logs, he reviews an AI-generated briefing summarizing customer feedback specifically regarding AI workflows. It arrives as a concise set of bullet points detailing how users interact with the tools, what features they are asking for, and where Linear can provide better support. Because the synthesis takes only a few minutes to read each morning, it creates a lightweight, daily anchor keeping leadership in direct touch with user sentiment.

Transitioning to how teams maintain judgment, Saarinen warns of a subtle organizational trap emerging alongside AI adoption: isolation. When engineers and designers lean heavily on autonomous agents to write code and generate prototypes, people increasingly retreat into silos, working in solitude alongside their tools. While individual execution speed increases, collective learning grinds to a halt. Teams stop cross-pollinating ideas, critiquing each other's work, and reinforcing shared engineering and design standards.

[10:36](https://www.youtube.com/watch?v=Zn9NZ-r1-C4&t=636s) Quality Wednesdays and Feature Roasts: Training Shared Taste

To counter this fragmentation and align taste across a rapidly expanding team, Linear instituted specific group rituals. The first is "Quality Wednesday." As the company scaled, Saarinen noticed that new hires naturally arrived with varying standards of what craft and quality meant. To calibrate the entire organization to a single high bar, every team member is tasked once a week with scouring the product to find and fix at least one quality defect. The scope is deliberately flexible—it does not need to be an expansive engineering initiative; it can be a five-minute fix addressing a janky animation, an awkward hover state, or a minor copy error.

The primary value of Quality Wednesday is not merely squashing small bugs, but systematically training the team's collective eye. Because the company gathers in a meeting where everyone showcases what they caught and how they fixed it, team members absorb how their peers evaluate polish.

A complementary practice for upcoming work is the "Feature Roast." Hosted by the team building a new feature, this optional, company-wide session invites anyone to deliver raw, unvarnished critiques. Participants are urged to be completely candid, calling out confusing UI flows, jarring transitions, or aesthetic flaws without fear of causing offense:

```mermaid flowchart TD accTitle: Rituals for Building Product Judgment accDescr: Weekly rituals of Quality Wednesday and Feature Roasts feed into shared reviews and build lasting team taste. subgraph S1["Weekly Rituals"] A["Quality Wednesday<br/>(Find & fix 1 defect)"] B["Feature Roast<br/>(Unvarnished critique)"] end subgraph S2["Team Synthesis"] C["Shared Review Session"] D["Group Feedback into Issues"] end subgraph S3["Compounding Taste"] E["Trained Eye for Craft"] F["Anticipatory Polish"] end A --> C B --> D C --> E D --> F E --> F ```

Because coworkers outside the immediate project team are experiencing the feature for the first time, their friction points closely mirror what actual end-users will encounter. Following the roast, the project lead synthesizes the commentary into actionable Linear issues. Saarinen notes that the real long-term benefit happens later during execution: an engineer building an unrelated feature will remember that a specific colleague always scrutinizes onboarding states or animation curves, prompting them to address those details proactively before shipping.

- **Quality Wednesday scope:** Finding and repairing minor defects—such as broken hover states, janky transitions, or copy bugs—in fixes that often take only five minutes. - **Feature Roast mechanics:** Open-invite, non-personal critique sessions where colleagues simulate real first-time users by identifying points of confusion and aesthetic gaps. - **Synthesis:** Leads categorize open feedback into concrete, trackable issues, embedding peer sensibilities directly into the development roadmap.

[13:11](https://www.youtube.com/watch?v=Zn9NZ-r1-C4&t=791s) Reinvesting AI Efficiency into Shared Context and Understanding

Saarinen questions the tech industry's default response to AI automation, which tends to focus entirely on accelerating output and shipping ever-larger quantities of code. If AI agents genuinely make teams more efficient and save hours of manual labor, organizations should not simply use that surplus to produce more noise. Instead, they should reinvest that recovered time upstream into higher-leverage, reflective activities: conducting customer explorations, facilitating design critiques, elevating product quality, and deliberating on strategic direction.

He explains that enduring companies are built on the "compound understanding" of the problems they set out to solve. For that understanding to compound, context must live in a transparent, accessible shared space rather than in fragmented personal silos. This shared knowledge base serves a dual purpose: it grounds human team members in the reasoning behind decisions and enables AI agents to answer nuanced questions about customer sentiment and historical team responses. In this environment, product leadership transitions away from monitoring daily task execution toward curating the organizational context that guides both people and agents.

[14:49](https://www.youtube.com/watch?v=Zn9NZ-r1-C4&t=889s) Demystifying Intuition and Leading with Context

As AI tools mature, Saarinen argues that teams should happily automate the known, repeatable, and low-impact tasks where there is little new learning to be gained. Human effort must instead focus on building deep domain understanding. Addressing Linear's well-known rejection of A/B testing in favor of product intuition, Saarinen demystifies what intuition actually represents:

> "Intuition is not some like magical force that like in Star Wars or something that it happens to you. It is something that you have learned while working on something or listening to customers... Intuition is basically your training in your brain that you have."

The deeper an individual's exposure to customer reality and peer critiques, the sharper their personal intuition becomes, which eventually compounds into the judgment of the entire team.

Saarinen concludes by returning to the central theme of his talk: "context becomes the product." The industry often obsesses over visible artifacts—the code, the features, the immediate software output. However, the true determinant of product quality is upstream: the quality of the decisions being made by the people building it. This reframes the purpose of hiring. Adding team members is not about increasing headcount to churn out raw output; it is about bringing in individuals whose taste, judgment, and ideas alter the company's trajectory. When product organizations pivot from micromanaging execution to cultivating shared context, exceptional software follows naturally.

## Notable quotes > [01:47](https://www.youtube.com/watch?v=Zn9NZ-r1-C4&t=107s) software factories — Karri Saarinen

> [01:47](https://www.youtube.com/watch?v=Zn9NZ-r1-C4&t=107s) Output is not the product — Karri Saarinen

> [08:00](https://www.youtube.com/watch?v=Zn9NZ-r1-C4&t=480s) watchers — Karri Saarinen

> [10:36](https://www.youtube.com/watch?v=Zn9NZ-r1-C4&t=636s) Quality Wednesday — Karri Saarinen

> [10:36](https://www.youtube.com/watch?v=Zn9NZ-r1-C4&t=636s) Feature Roast — Karri Saarinen

> [13:11](https://www.youtube.com/watch?v=Zn9NZ-r1-C4&t=791s) compound understanding — Karri Saarinen

> [14:49](https://www.youtube.com/watch?v=Zn9NZ-r1-C4&t=889s) Intuition is not some like magical force that like in Star Wars or something that it happens to you. It is something that you have learned while working on something or listening to customers... — Karri Saarinen

> [14:49](https://www.youtube.com/watch?v=Zn9NZ-r1-C4&t=889s) Intuition is basically your training in your brain that you have. — Karri Saarinen

> [14:49](https://www.youtube.com/watch?v=Zn9NZ-r1-C4&t=889s) context becomes the product — Karri Saarinen

## Mentioned Karri Saarinen, Linear, Lenny's Podcast, Lenny and Friends Summit, Datadog, Sentry, Slack, Formula 1, Star Wars, San Francisco

## Video description AI can help teams ship more software, but are they learning enough to make better products? At the Lenny and Friends Summit, Linear’s Karri Saarinen argues that great products depend on the understanding teams build through customer conversations, shared critiques, and hands-on work. He shares how Linear uses AI customer briefings, weekly quality reviews, and candid feature feedback to strengthen the judgment of the whole team.

Recorded live at Lenny and Friends Summit on September 10, 2026, in San Francisco.

[Source](https://www.youtube.com/watch?v=Zn9NZ-r1-C4)

中文简报

Linear CEO 警告：AI 自动化正侵蚀团队的产品判断力 将软件执行外包给 AI 会切断培养产品直觉的实践学习闭环，这要求企业将节省下来的工程时间重新投入到共同评审和客户洞察中，而非一味交付更多代码。 Karri Saarinen 对科技行业盲目追求自动化“软件工厂”的趋势提出质疑。他警告称，将核心问题解决外包给 AI 可能会使执行与培养产品直觉的组织学习脱节。他主张有选择地将 AI 用于学习价值较低的维护任务以及综合定性客户反馈，同时有意识地保护人类判断力免受孤立工作模式的影响。通过每周的“Quality Wednesdays”（质量周三）和直言不讳的“Feature Roasts”（功能吐槽会）等实践，Linear 在整个组织内系统地培养集体品味。最终，Saarinen 认为上下文（context）本身就是产品，他敦促团队将 AI 带来的效率提升重新投入到客户探索、打磨工艺和共同决策中，而不是盲目生产更多代码。 尽管 AI 工具加速了代码生成，但原始产出量仍然是衡量价值的错误指标，因为客户需求取决于产品质量，而非组织的吞吐量。 (1:47) 构建产品会产生两种结果——产品本身和组织学习；将核心问题解决完全交由 AI 处理，可能会切断训练人类判断力的反馈闭环。 (3:24) Linear 将 AI 自动化限制在跨平台漏洞诊断等机械性、低学习价值的任务上，并将节省下来的工程时间重新投入到直接接触客户和打磨产品工艺中。 (5:47) 为了应对自动化工具导致的开发者孤立问题，Linear 借助“Quality Wednesday”（质量周三）缺陷修复和全公司范围内直言不讳的“Feature Roasts”（功能吐槽会）等共同仪式，来对齐设计品味。 (10:36) 产品领导力必须将重心从监督任务执行转向构建共享上下文，以此作为人类直觉和自动化智能体的共同基础。 (13:11)

Reading summary

As AI accelerates code generation, Linear's Karri Saarinen argues that product leaders must resist turning their organizations into automated "software factories." Instead of optimizing for raw output, companies should use AI to automate low-learning tasks and synthesize customer signals while reinvesting saved time into cultivating shared context, taste, and product judgment. The Illusion of the Software Factory (0:06) After stepping away from the AI news cycle for a summer, Saarinen returned to find that despite rapid advances in models and agentic frameworks, building a successful product and sustainable business remains as difficult as ever. He challenges the tech industry's fixation on tooling and its push to turn development teams into automated "software factories." This mirrors an older enterprise playbook—mass hiring, hyper-specialized silos, heavy processes, and substituting statistical A/B test readouts for product instinct—which ultimately distanced teams from what they were supposed to build. Saarinen insists that "output is not the product." Customers pay for valuable experiences rather than lines of code, experiment volume, or raw operational efficiency. When companies outsource critical thinking and judgment to chase sheer throughput, they optimize for a false proxy rather than making something people genuinely want. The Hidden Hazard of Decoupling Learning (3:24) Whenever a team builds software, Saarinen contends it produces two outputs: the artifact itself and the compounding learning gained through execution. Wrestling with trade-offs and validating hypotheses against user feedback builds deep domain understanding, technical awareness, aesthetic taste, and institutional memory—much like how decades of hands-on racing evolved the Formula 1 steering wheel from a simple round wheel into a dense, specialized control interface. Indiscriminate AI automation threatens to sever this feedback loop by decoupling execution from learning. Therefore, leaders must deliberately separate mechanical tasks from human judgment. At Linear, an internal agent loop investigates bugs across Datadog and Sentry, pinpoints root causes in the codebase, and drafts proposed pull requests. Engineers avoid tedious forensic work while still verifying fixes, freeing bandwidth not to ship more code, but to engage with customers, explore edge cases, and elevate craft quality. Amplifying Customer Context with AI (8:00) Rather than treating AI solely as an execution engine, Saarinen advocates using it to preserve ground-level customer intuition as an organization scales. Although Linear encourages engineers and product contributors to join shared customer Slack channels and field support inquiries, rapid growth can overwhelm individuals with interaction volume. To prevent teams from drifting away from user reality, Linear uses targeted AI "watchers" to ingest and synthesize qualitative signals across sales calls, meeting recordings, support tickets, and internal discussions. For example, because no industry best practices exist yet for AI workflows, Saarinen relies on a custom daily briefing agent that summarizes how customers use AI tools and what features they request. Taking only a few minutes to read each morning, this automated synthesis keeps leadership anchored in real-time user sentiment without hours of manual transcript review. Rituals Against Isolation to Train Taste (9:47) Saarinen warns that heavy reliance on autonomous agents for code and prototypes can push engineers and designers into isolated silos, halting collective learning and peer critique. To align standards across a growing team, Linear instituted two group rituals. On "Quality Wednesday," every team member finds and fixes at least one product defect—often a five-minute repair to a janky animation, awkward hover state, or minor copy error—and showcases it in a company meeting to calibrate the team's collective eye. For upcoming work, teams host an optional, company-wide "Feature Roast," inviting candid critiques of confusing UI flows or aesthetic flaws from colleagues experiencing the feature for the first time. Project leads convert this feedback into trackable issues. Over time, engineers internalize their peers' standards—such as a colleague's focus on onboarding states or animation curves—and address those details proactively before shipping. Saarinen concludes that product intuition is not a magical force, but trained judgment built from customer exposure and peer critique. By reinvesting AI-driven time savings upstream into customer exploration, design critique, and shared organizational context—which informs both human teams and AI agents—companies ensure high-quality decisions. In this model, "context becomes the product," and hiring shifts from adding headcount for raw output to recruiting individuals whose taste and judgment alter the company's trajectory.

Source quotes

[1:47] Karri Saarinen: software factories [1:47] Karri Saarinen: Output is not the product [8:00] Karri Saarinen: watchers [10:36] Karri Saarinen: Quality Wednesday [10:36] Karri Saarinen: Feature Roast [13:11] Karri Saarinen: compound understanding [14:49] Karri Saarinen: Intuition is not some like magical force that like in Star Wars or something that it happens to you. It is something that you have learned while working on something or listening to customers... [14:49] Karri Saarinen: Intuition is basically your training in your brain that you have. [14:49] Karri Saarinen: context becomes the product

Original transcript

[0:06] All right, good afternoon everyone. Um, [0:08] I'm here today to talk about great [0:11] products, context, and the product work [0:14] we do. But first, I want to talk about [0:16] my summer. Um, I so I took a break this [0:19] summer from paying attention to AI. I [0:22] stopped following the news like what is [0:24] the latest model? What can it do? what [0:26] agents of do we have and what what are [0:28] the new techniques we can use and when I [0:31] was I was on this vacation I I thought [0:34] like when I when I come back maybe I [0:36] will feel left behind maybe things [0:38] change a lot but it realized that when I [0:41] came came back actually realized that [0:43] nothing has changed much um there's new [0:45] models there's new techniques there's [0:47] new agents but I think like in the end [0:49] that the making great products and [0:51] building like increasing revenue or [0:53] building the business like it's still [0:55] hard so it made me wonder how much [0:57] attention we're really paying to these [0:59] tools. Like we are really watching the [1:02] tools a lot all the time. There's always [1:04] new things we can try and it's clear [1:07] that these tools are getting better. [1:09] They can do more. They can do it faster. [1:11] They're more capable. But the I think [1:13] more important question is like are we [1:15] actually making better things with these [1:17] tools? And are our teams getting better [1:20] with these tools? And I I don't think [1:22] that that answer is is clear clearly [1:26] yes. Like if you look out there and like [1:28] even in your inside your own companies, [1:30] how do you even know like how are you [1:31] making better things? Do you feel that [1:33] way? Does your customers feel that way? [1:35] So there's a lot of emphasis now on tool [1:38] making and using tools and building [1:40] systems. But I think like in the end [1:43] like as a product people our job is to [1:44] to make something good. And so in some [1:47] ways like today I think there's been [1:49] several talks about software factories [1:51] and I think that the industry has been I [1:54] think obsessed with this idea a long [1:56] time like how do we scale and optimize [1:59] the output our organizations do and I [2:02] think it makes sense and it is it is [2:04] important to to move fast and like do [2:07] things but this started even before AI [2:10] and I think before AI the the idea was [2:12] that we need to hire more people we [2:13] create very specialized roles so they [2:16] work in their own ways and then we [2:17] create because there's a lot of people [2:19] we create more process and because we [2:21] have process and a lot of people we [2:23] actually don't even know anymore like [2:25] what what people are doing or what [2:26] they're supposed to do. So we run [2:27] experiments. So experiments the data [2:29] tell us like what what works and what [2:31] doesn't and this is all to like scale [2:33] like how do we get more output than like [2:34] how do we get more um output from the [2:38] organization but again like my [2:40] philosophy as always it's more more [2:42] [clears throat] output isn't better like [2:43] I I think like what we want to build is [2:46] like better experiences for the [2:47] customers one of my messages today is [2:49] that don't like you can build the [2:52] software factories and you can make and [2:54] you can automate things and that all [2:55] makes sense but just like as an [2:57] organization Don't become one. Don't [2:59] become a software factory where you out [3:02] like outsource all the work and thinking [3:05] to somewhere else and like just focus on [3:07] like how efficient can the output be [3:10] because the output is not the product. [3:11] Like customers are not buying the lines [3:13] of code. They're not buying the [3:14] experiments or they're not buying a lot [3:16] of things. So in the end like if you [3:18] want to sell something or make some good [3:21] product you have to make something [3:22] someone wants. When I think about making [3:24] things I think about two things. So [3:28] making products produces two things. The [3:31] the product and the learning. [3:33] Historically the building products or [3:36] designing them it's always created this [3:39] learning as well. Like when you are [3:40] struggling like trying to think like [3:42] what you should build, how you should [3:44] build it, which way, what kind of shape [3:46] does it take, you have all these [3:48] questions you are asking and maybe [3:50] you're answering them yourself. Maybe [3:51] you go talk to someone, maybe you talk [3:53] to the customers and try to find the [3:55] answer. So the actual effort you put [3:57] into building things, it's also like [3:59] teaches you something about what the [4:01] problem is, what the customers uh want [4:04] or like what what is their view. So [4:07] we're kind of like in this time now that [4:09] there's there's a little bit this danger [4:11] of losing that uh direct direct [4:15] connection with the with the learning. [4:17] And I think like if you think about any [4:19] great company out there or companies [4:21] that create great products, you probably [4:23] respect their product, but you probably [4:25] also respect their team. And I think [4:27] like products are usually just like it's [4:29] kind of obvious, but they're like [4:31] they're produced by the team in the [4:33] company. And the better the team, the [4:35] better they understand the space they're [4:37] in, the better skills or talents they [4:39] have, the better taste they have, like [4:41] the better they build things. And so [4:44] like great companies they consistently [4:46] be able to to build great things because [4:48] they have this culture and context built [4:50] around like how what how to think about [4:53] things like what matters what doesn't [4:54] matter. So this is like all the context [4:56] around customers about the product space [4:58] they're in the technologies they can use [5:01] the judgment the team uses to make [5:03] decisions the taste they have to [5:05] actually find what is good and all the [5:07] history of the different things they've [5:09] tried or or what they decided. And the [5:11] image here is just a illustration of [5:14] this kind of like compounding learning. [5:16] It's a Formula 1 steering wheel which [5:18] started with very kind of traditional [5:20] form. But over the decades the the the [5:23] kind of like the the team learned to how [5:25] to really make it better and make it [5:28] something that makes sense for this use [5:30] case. Like Formula 1 cars, they don't [5:33] need a lot of turning radius. So you [5:35] need a lot of like small movements and [5:36] like controlling the car in a high [5:38] speed. It's very fine movements and then [5:41] that's why the the actual steering wheel [5:43] ended up different than what we [5:45] typically see in cars. The danger really [5:47] now with the product organization is [5:49] that the more we automate stuff um to AI [5:52] to do and more we automate it or tell [5:54] teams to use AI, you kind of like create [5:57] this separation from execution and from [5:59] the learning. It's not necessarily bad [6:01] thing like it's what I'm calling this [6:03] out is that if this is the case and this [6:06] is happening in your company like how [6:08] are you going to fix it like eventually [6:10] if you don't learn from the work you do [6:12] I think eventually you would lose the [6:14] advantage of what you have currently in [6:16] your in your space or in your company [6:19] one way to think about it is like well [6:20] what is good to automate maybe what what [6:22] is what is good for people to do I think [6:25] there's definitely things that are [6:26] repeatable and maybe not something you [6:28] learn a lot about like even At winner we [6:30] do now how to fix bugs. We have a we use [6:34] it the winner loop to investigate the [6:36] bug. It will connect to data do and [6:38] sentry and other tools. It will try to [6:41] look into the codebase and and try to [6:43] understand where the bug is coming from [6:44] and then it will write a fix. So it [6:46] saves the time for the engineers like [6:48] they don't have to investigate the [6:49] problems. They come and and verify the [6:52] result and and sometimes they make [6:54] little changes for those results. But so [6:57] the idea is like how do you save time um [7:01] now with these new new tools but without [7:04] really like outsourcing everything. Um [7:07] so where I think about like the team [7:09] should spend more time in is in the [7:11] customer space and the customer [7:12] problems. From the beginning, we always [7:15] told at of the beginning of the company, [7:17] we we've been pushing the engineers and [7:19] all the team members really go connect [7:22] with the customers, join the Slack [7:24] channels, join the shared Slack [7:25] channels, answer their questions, ask [7:27] them questions, and like kind of like [7:29] stay close to the customer and kind of [7:31] like build your customer intuition that [7:33] way. And I think like now if engineering [7:37] or other roles have some time savings I [7:41] think there's areas they can do more in [7:43] like they can spend more time with [7:45] customers they can explore more things [7:47] they can train their judgment or or make [7:51] better quality uh work than they [7:54] previously had time to. So the goal I [7:57] think really for the product [7:58] organization in the future is like how [8:00] do you keep this learning loop happening [8:03] like how do you have context and and and [8:06] bring signals from that context and and [8:08] bring those learnings into the whole [8:10] team and the whole company and I think [8:12] like actually now AI can be a great tool [8:14] in this. So a lot of times people I [8:17] think focus on what AI can do what it [8:20] can execute but not what AI can teach [8:22] you. So I think for example at linear [8:25] what we do is that we use the AI to help [8:27] us to build this context. So we collect [8:30] all the customer information that we [8:32] can. Um we have automations that pull uh [8:36] customer feedback from sales calls and [8:38] other other meetings uh as well as from [8:41] support emails and and internal uh [8:44] discussions and that's kind of like [8:46] builds this like a place for the context [8:48] and place for the the kind of like the [8:50] customer context and then like some [8:52] something I started you doing recently [8:54] is that the problem previously I think [8:56] in a product organization especially [8:58] it's a large one a lot of people start [9:01] being kind of away from the customer [9:02] problems on the day-to-day problems [9:05] because there's so much of it and and [9:07] you don't have the time to follow up [9:09] with everyone or look at every single [9:11] email or every request. But what I [9:14] started doing is that we we collect all [9:16] this context, but then I sent this like [9:19] a watchers like an agent to watch it and [9:22] see tell me when when there's something [9:23] interesting for me. So one of these [9:25] things I set up is this daily briefing [9:28] about AI workflows. what are the [9:30] customers saying about their AI [9:32] workflows? I want to learn more from it [9:35] because I've seen a lot of companies do [9:37] it very differently. Uh today we I think [9:40] there's no clear best practices. Every [9:43] company does their stuff a little bit [9:45] differently. And so that's why I'm [9:47] trying to like learn more that like what [9:49] are all the ways people are using these [9:50] tools? What what do they want from us [9:52] and how can we help them better? So this [9:55] can it's it doesn't take a lot of time [9:57] for my day to just read this. It gets [9:59] few bullet points usually but I get this [10:02] like a daily briefing basically saying [10:05] like the these are the customer what [10:07] they're saying about the AI workflows. [10:09] On the judgment side I wanted to [10:11] highlight couple things we do. I think [10:13] what I've also noticed that when [10:15] companies start using AI more and agents [10:17] more people start uh siloing themselves [10:21] like a lot of people are working alone [10:23] with their agents building things and I [10:26] think it's efficient but then there's [10:28] also the problems like we not learning [10:31] from each other anymore um or sport as [10:34] much so one of the practices we start [10:36] doing is this quality Wednesday and this [10:39] happened because we as We keep hiring [10:43] people. We we notice that not everyone [10:45] has the same standard or understanding [10:47] what what the quality means. And so we [10:50] task everyone to go every week, spend [10:53] some time, look into the product, try to [10:55] find one quality defect in the product [10:59] and then fix it. It can be very small. [11:01] It can be weird hover state like janky [11:04] animation. It can be a copy error. It [11:06] can be something else. So it doesn't [11:09] mean that like it should be like a huge [11:10] project. It it could be like a five [11:12] minute fix. The bigger impact with this [11:14] is not really that we do this fixes. We [11:16] do like that too. But the bigger impact [11:18] is that the team trains everyone trains [11:21] themselves to look for this like they [11:23] train their eye to notice the small [11:26] mistakes and then because we do this in [11:28] a meeting everyone shares their findings [11:30] and their fixes. Everyone can learn from [11:33] that and see how other people are [11:35] finding these problems. And then the [11:37] second thing we do for new features is [11:39] this feature roast. Uh it's a little [11:41] similar but a little different where [11:43] it's this optional meeting. Anyone in a [11:45] company can join the team who is [11:47] building the feature hostess and then [11:49] what they ask people to do is just [11:52] critique the whole feature. Like you can [11:54] be as nitpicky or confused or whatever [11:57] you want. You just put your raw feedback [12:00] and it's not personal. It's just like [12:02] this this is how I see it. And the team [12:04] can still like interact with the people [12:05] and ask them questions if they don't [12:07] understand something. Again, like we're [12:08] trying to train people that what matters [12:10] and like what do they we care about and [12:13] also like kind of train um give [12:16] [clears throat] the team who is building [12:17] the feature a little more like realistic [12:19] way to see what maybe how the users [12:21] would think about the feature because a [12:23] lot of people in a company this is the [12:24] first time for them seeing the feature. [12:26] So they if they are confused it's likely [12:28] that the the users are confused too. And [12:31] then like after that the lead can [12:33] synthesize the feedback and and make [12:36] group it and make some kind of [12:37] actionable issues out of it and then [12:39] they can like fix it. But like I think [12:42] the important part is that these are [12:43] done together and there's this like [12:46] discussion that happens with these [12:47] meetings and that that kind of like [12:49] gives everyone a little more everyone [12:51] can learn from each other and they [12:53] notice like when you're building on your [12:55] own product or your own feature you [12:57] remember one of these discussions and [12:59] you know that oh those that person [13:01] always cares about the onboarding or [13:04] they care about this animation so I must [13:06] I should check into that and like [13:08] remember to do it so I don't get that [13:10] feedback. So my like really the ask is [13:12] that we we we have this idea that well [13:15] AI can do a lot of stuff and like let's [13:17] make everything more efficient. Let's [13:19] produce more. But if if AI is really [13:21] efficient and it's saving time, then [13:23] maybe there's an opportunity to spend [13:25] more of that time to something else. [13:27] Like rather than focusing on the [13:29] execution, we could sort of start [13:31] focusing on the customers, the [13:32] explorations, the the critiques, the [13:34] quality or the even the reflection of [13:36] what we do. I think like in the future [13:38] the product organization maybe that the [13:41] work we do changes and we move away from [13:44] the spending so much time on the [13:46] execution but actually going a little [13:49] more abstract and like thinking about [13:51] the the actual activities and like how [13:53] do we become better as a team and how we [13:55] can become better as a as a product [13:57] organization. what I said earlier that [13:59] the the I think companies are often [14:01] compound understanding of the work and [14:03] the the problems they they uh solve. So [14:07] I think there's an important aspect that [14:10] you should have some kind of place where [14:12] you put this stuff like there's some [14:13] place that's available for learning [14:16] about the customer context or learning [14:18] about your product thinking or learning [14:20] about anything else you're doing and [14:23] then I think that it's important for the [14:24] people but it's also important for the [14:26] agents. So I think now a lot of times I [14:28] can now ask the agents like what do we [14:30] have about this or teach me something [14:33] about the customers like what are they [14:35] saying and what are they doing and and [14:37] like what how is the team responding to [14:38] that. I think there is a value of like [14:40] creating this like a shared space where [14:42] this context lives um around the [14:44] customers and the product and the the [14:46] work that is happening around the [14:48] product. I will end end this with this [14:50] that I think that the tools will keep [14:52] improving. And I think we will keep [14:53] watching the tools and I think we will [14:55] keep automating more and more stuff. But [14:56] I think my view is that we should [14:58] automate more of the known things like [15:00] the things that are repeatable and maybe [15:03] are not that impactful. It's not [15:04] something we can learn a lot from. My [15:06] hope is that like we can spend more time [15:08] like how do we build the understanding [15:10] of the what we're doing in this company [15:11] or in this product organization like how [15:14] do we make sure that the team is [15:15] learning from something and from someone [15:17] from somewhere and not just executing [15:19] the next prototype or the next idea or [15:22] something because I think I we we at [15:25] linear we don't run experiments we we [15:28] use we tell people to use their [15:29] intuition but I often tell people that [15:32] intuition is not some like magical force [15:34] that like and Star Wars or something [15:36] that it's happens to you. It it is [15:39] something that you have learned while [15:41] working on something or listening to [15:43] customers or something. Intuition is [15:45] basically your training in your brain [15:47] that you have. And so the more you can [15:50] learn and and listen and and see this [15:52] context, I think it will compound your [15:54] personal understanding and then [15:56] eventually compounds the whole team's [15:58] understanding. And so in the end I like [16:00] what what this talk was about is like [16:02] context becomes the product. Then like [16:04] it's it's more that we we have this [16:06] obsession to look at what is the output [16:08] the software or the code but I think in [16:12] the end it's it's I I look the other [16:14] direction it's like what is actually [16:16] creating the software like who is making [16:17] the decisions and that's the people are [16:19] doing that and the better context those [16:22] people have and like better [16:23] understanding they have about the what [16:25] they're supposed to do I think the [16:27] products are better and so at linear I [16:30] always thought that hiring people is the [16:32] first step building great products and [16:34] maybe it's kind of obvious but I think [16:36] sometimes people just think that I I [16:38] need to hire to do something I need to [16:40] increase the output but what you're [16:42] really like trying to do is think about [16:43] like what is the trajectory this person [16:46] can create for the company like what [16:48] kind of ideas they have like do they [16:50] have the right judgment or taste how can [16:51] they use it in this organization so in [16:54] the end I think like more of the product [16:56] organizations maybe comes around the it [17:00] becomes the context like more of the [17:01] work is about managing this context like [17:03] re learning from it finding ways to to [17:07] team to come together and learn learn [17:08] from it versus the actual execution of [17:10] the code or or building the thing so [17:13] that's what I mean like context becomes [17:15] the product thank [17:19] >> [applause]