Don't Become a Software Factory: Why Context Is the Real Product

Saarinen opens by describing a break he took from following AI: no news about the latest model, no tracking of new agents or techniques. He worried he would come back feeling left behind. Instead he found that little had changed in what matters, because building great products and growing a business were still hard.

That made him ask how much attention the industry pays to the tools versus the results. The tools are clearly getting faster and more capable. The more important question, he says, is whether teams are making better things with them and whether the teams themselves are getting better. He doesn't think the answer is clearly yes, and he asks listeners whether their own customers feel the difference.

Saarinen notes that several talks at the summit covered software factories, and that the industry has long been obsessed with scaling and optimizing output. The pattern predates AI: hire more people, create specialized roles, add process, and then run experiments because nobody can see what everyone is doing anymore. All of it aims at getting more out of the organization.

His philosophy is that more output isn't better. The goal is better experiences for customers. He is fine with building factories and automating things, but he urges companies not to *become* one, outsourcing both work and thinking elsewhere while focusing only on efficiency.

His reasoning is simple: customers are not buying lines of code or experiments. To sell anything, you have to make something someone wants.

Making products, Saarinen says, produces two things: the product and the learning. Struggling over what to build, how, and in what shape raises questions that you answer yourself, by talking to colleagues, or by asking customers. That effort teaches you what the problem is and how customers see it.

Great companies earn respect for their products and their teams, because products are produced by teams. The better a team understands its space and the stronger its skills and taste, the better it builds. Saarinen calls the accumulated knowledge context: customers, product space, available technologies, the judgment used in decisions, the taste to recognize what is good, and the history of what was tried and decided.

He illustrates compounding learning with a Formula 1 steering wheel, which began in a traditional form. Over decades teams learned that these cars need only small, precise movements at high speed, and the wheel evolved accordingly. The danger now is that the more work is handed to AI, the more teams separate execution from learning. He doesn't call that necessarily bad, but he says a company that stops learning from its work will eventually lose its advantage.

The question, Saarinen says, is what is good to automate and what people should keep doing. Repeatable work you don't learn much from is a good candidate. At Linear, an agent loop now investigates bugs: it connects to data tools and Sentry, studies the codebase, finds the source of the problem and writes a fix. Engineers verify the result and sometimes tweak it, saving them the investigation.

The time saved should go toward the customer space. From the start Linear has pushed engineers and other team members to join shared Slack channels with customers, answer questions and ask their own, building customer intuition. With time savings, people can spend more time with customers, explore more, train their judgment and produce higher-quality work than before.

The goal for a product organization, in his view, is to keep a learning loop running: gather signals from context and spread those learnings through the whole company.

Saarinen argues that people tend to focus on what AI can execute and overlook what it can teach. At Linear, automations pull customer feedback from sales calls, other meetings, support emails and internal discussions into one place that holds the customer context.

In a large organization, many people drift away from day-to-day customer problems because there is too much to follow. So he set up an agent as a watcher that tells him when something interesting appears. One example is a daily briefing on what customers say about their AI workflows, a topic where he sees companies doing things very differently and no clear best practices yet.

The briefing is usually a few bullet points and takes little of his day to read. It helps him learn how people use these tools, what they want from Linear, and how the company can help them better.

As companies adopt agents, Saarinen has noticed people siloing themselves, each working alone with an agent. That is efficient, but it means people stop learning from each other. One response is Quality Wednesday. As Linear kept hiring, it saw that not everyone shared the same standard of quality, so each person now spends time every week finding one defect in the product and fixing it.

The fixes can be tiny: a weird hover state, a janky animation, a copy error. The bigger payoff is that people train their eye for small mistakes, and because findings are shared in a meeting, everyone sees how others spot problems.

The second ritual is the feature roast, an optional meeting open to anyone in the company, where a team presents a feature and others critique it with raw, non-personal feedback. Because it is often the first time colleagues see the feature, their confusion is a good sign of what users will feel. The lead then synthesizes the feedback into actionable issues, and people remember each other's concerns, such as onboarding or animation, when building their own work.

Saarinen's ask is that if AI saves time, teams should spend it on customers, exploration, critique, quality and reflection rather than on producing more. He imagines product organizations moving away from execution toward more abstract work: thinking about how the team can get better. He also wants a shared place where learning about customers and product thinking lives, useful to people and to agents, who can then answer questions such as what customers are saying.

Automate more of the known, repeatable and lower-impact work, he says, and use the freed time to build understanding rather than to ship the next prototype. Linear doesn't run experiments and tells people to use their intuition. But intuition isn't magic like the Force in Star Wars: it is training from working and listening to customers, and it compounds first personally and then for the whole team.

He concludes that people should look past the output, the software or code, to what creates it: who makes the decisions and how much context they have. Hiring is therefore the first step in building great products, not as a way to raise output but for the trajectory, judgment and taste a person brings. More of the product organization's work, he predicts, becomes managing context and learning from it rather than executing code.