Context Becomes the Product: Karri Saarinen on What AI Should Free Teams to Learn
Lenny's Podcast
Karri Saarinen, co-founder of Linear, opened his talk at the Lenny and Friends Summit with a story about stepping away. This summer he took a break from following AI: the latest models, what they could do, which agents existed, which techniques were new. He expected to return feeling left behind. Instead, he found that little had changed where it mattered. There were new models, techniques, and agents, but making great products, growing revenue, and building a business were still hard.
That observation shaped his central question. The industry watches its tools constantly, and the tools are clearly getting faster and more capable. But are teams actually making better things with them, and are the teams themselves getting better? Saarinen said he does not think the answer is clearly yes. He asked the audience how they would even know whether their companies are making better things, and whether their customers feel that way. His position is that product people exist to make something good, and that the understanding a team builds through its work matters more than output.
The Software Factory Predates AI
Saarinen noted that several talks that day had covered "software factories." He argued the industry has been obsessed with scaling and optimizing organizational output for a long time, well before AI. In his account, the pre-AI version looked like this: hire more people, create specialized roles that each work in their own way, add process because there are so many people, and eventually lose track of what people are doing or supposed to be doing. At that point companies run experiments so the data can tell them what works.
He granted that moving fast matters and that the push for output makes sense. His philosophy, though, is that more output isn't better. The goal is better experiences for customers. He put his main message this way: you can build software factories and automate things, and that makes sense, but don't become one as an organization. Don't outsource all the work and thinking elsewhere while focusing only on how efficient the output is. In his words, "the output is not the product." Customers don't buy lines of code or experiments. To sell something, you have to make something someone wants.
Making Things Produces Two Things: the Product and the Learning
Saarinen said building a product has always produced two things: the product and the learning. When a team struggles over what to build, how to build it, and what shape it should take, it asks questions, sometimes answering them itself, sometimes going to colleagues or customers. That effort teaches the team about the problem and about what customers want.
The danger now, he said, is losing that direct connection to learning. He tied this to how we think about great companies: we usually respect their teams as much as their products, because products come from teams. The better a team understands its space, and the more skill and taste it has, the better it builds. Great companies can build great things consistently because they have developed a culture and context about what matters and what doesn't. He listed what that context contains: knowledge of customers, the product space, the available technologies, the judgment the team uses for decisions, the taste to recognize what is good, and the history of what the company has tried and decided.
To illustrate compounding learning, he showed the Formula 1 steering wheel. It started in a traditional form, but over decades teams learned what the use case needed. F1 cars don't need much turning radius. Drivers make small, fine movements to control the car at high speed, so the wheel evolved into something unlike an ordinary car's.
The Risk of Separating Execution From Learning
The more organizations automate work with AI, or tell teams to use AI, the more they separate execution from learning. Saarinen said this is not necessarily bad in itself. He was raising it so companies can ask how they will compensate. His view is that a company that stops learning from its own work will eventually lose the advantage it currently holds in its space.
One way to approach this is to ask what is good to automate and what is good for people to do. Some work is repeatable and doesn't teach you much. His example was bug fixing at Linear. The company now runs an AI loop to investigate bugs. It connects to Datadog, Sentry, and other tools, looks through the codebase to find where the bug comes from, and writes a fix. Engineers no longer have to do the investigation. They verify the result and sometimes make small changes. For Saarinen, the question is how to save time with these tools without outsourcing everything.
Where the Saved Time Should Go: Customers
Saarinen wants teams to spend more of their time on customers and customer problems. Since the company's beginning, Linear has pushed engineers and other team members to connect directly with customers. They join shared Slack channels, answer customers' questions, ask their own, and build customer intuition by staying close. If engineering and other roles now save time, he said, they can use it to spend more time with customers, explore more ideas, train their judgment, or produce higher-quality work than they previously had time for.
He framed the goal for future product organizations as keeping the learning loop going: gathering context, drawing signals from it, and bringing those learnings to the whole team and company. He argued AI can help here. People tend to focus on what AI can execute, he said, and less on what AI can teach you.
Using AI to Build Context: Customer Briefings at Linear
Linear uses AI to assemble customer context. Automations pull feedback from sales calls and other meetings, support emails, and internal discussions into one place.
Saarinen described a problem common in product organizations, especially large ones. Many people drift away from day-to-day customer problems because there are too many to follow, and nobody can read every email or request. His recent practice is to point "watchers," agents that monitor the collected context, at it and have them alert him when something interesting appears.
One is a daily briefing on AI workflows, covering what customers are saying about how they use AI. He set it up because he has seen companies approach AI workflows very differently. In his view there are no clear best practices yet, and every company does things a little differently. He wants to learn the range of ways people use these tools, what they want from Linear, and how Linear can help them. The briefing usually runs a few bullet points and takes little of his day to read.
Training Judgment Together: Quality Wednesday
On the judgment side, Saarinen described a pattern he has seen as companies adopt AI and agents: people silo themselves. Many work alone with their agents. He called that efficient, but it means people stop learning from each other.
Linear's first countermeasure is Quality Wednesday. It began because, as Linear kept hiring, the company noticed that not everyone shared the same standard or understanding of quality. Every week, everyone is tasked with spending some time in the product, finding one quality defect, and fixing it. The defect can be tiny: an odd hover state, a janky animation, a copy error. It isn't meant to be a big project, and it can be a five-minute fix.
The fixes do happen, but Saarinen said they are not the main impact. The bigger effect is that everyone trains their eye to notice small mistakes. Because findings and fixes are shared in a meeting, everyone sees how others find problems and learns from it.
Feature Roasts
The second practice applies to new features and is called a feature roast. It is an optional meeting that anyone at the company can join, hosted by the team building the feature. Attendees are asked to critique the whole feature and can be as nitpicky or as confused as they like. The feedback is raw and not personal: "this is how I see it." The building team can still ask follow-up questions when they don't understand a comment.
Saarinen gave two purposes. First, like Quality Wednesday, it trains people in what matters and what the company cares about. Second, it gives the feature team a more realistic preview of how users might react, since most people in the room are seeing the feature for the first time. If they are confused, users probably will be too. Afterward, the lead synthesizes the feedback, groups it, turns it into actionable issues, and the team fixes them.
What matters most, he said, is that these sessions happen together and involve discussion. People learn each other's priorities. Later, while building their own feature, someone might remember that a particular colleague always cares about onboarding or about a certain animation, check those things first, and avoid getting that feedback.
Reinvesting Efficiency Instead of Just Producing More
Saarinen's request was about what to do with the time AI saves. The common reaction is to make everything more efficient and produce more. If AI really is saving time, he suggested, that time could go toward customers, exploration, critique, quality, and reflection on the work itself. He speculated that product work may shift away from execution toward something more abstract: thinking about the activities themselves and how the team and the organization can get better.
A Shared Home for Context, for People and Agents
Returning to his claim that companies compound their understanding of their work and the problems they solve, Saarinen argued for having a place where that understanding lives. It could hold customer context, product thinking, and anything else the team is doing. He said this matters for people and also for agents. He now often asks agents what the company has on a topic, or asks them to teach him about customers: what customers are saying and doing, and how the team is responding. He sees value in a shared space where context about customers, the product, and the surrounding work accumulates.
Intuition Is Trained
In closing, Saarinen said tools will keep improving, people will keep watching them, and more will get automated. His view is that automation should target known things: work that is repeatable, less impactful, and not a source of much learning. He hopes teams spend more effort building understanding of what they are doing, making sure the team is learning from something or someone rather than just executing the next prototype or idea.
He connected this to how Linear operates. Linear doesn't run experiments. It tells people to use their intuition. He often tells people that intuition is not a magical force, like something out of Star Wars, that simply happens to you. It comes from working on things and listening to customers. Intuition is essentially training in your brain. The more context you absorb, the more your personal understanding compounds, and eventually the whole team's does too.
Context Becomes the Product
Saarinen summed up the talk as "context becomes the product." The industry fixates on output, the software and the code. He prefers to look the other way, at what creates the software: the people making the decisions. The better their context and their understanding of what they are supposed to do, the better the products.
That is why he has always seen hiring as the first step in building great products. He acknowledged this may sound obvious, but said people often hire simply to get something done or to increase output. What they should consider is the trajectory a person can create for the company: what ideas they bring, whether they have the right judgment and taste, and how they can use them in the organization. His closing prediction was that more of product organizations' work will become about managing context: learning from it and finding ways for the team to come together and learn, rather than writing the code or building the thing itself.
All right, good afternoon everyone. I'm here today to talk about great products, context, and the product work we do. But first, I want to talk about my summer.
I took a break this summer from paying attention to AI. I stopped following the news: what is the latest model? What can it do? What agents do we have, and what are the new techniques we can use? When I was on this vacation, I thought when I come back, maybe I will feel left behind. Maybe things change a lot. But when I came back, I actually realized that nothing has changed much. There's new models, there's new techniques, there's new agents, but I think in the end, making great products and increasing revenue or building the business, it's still hard.
So it made me wonder how much attention we're really paying to these tools. We are really watching the tools a lot all the time. There's always new things we can try, and it's clear that these tools are getting better. They can do more. They can do it faster. They're more capable. But I think the more important question is: are we actually making better things with these tools? And are our teams getting better with these tools? I don't think that answer is clearly yes. If you look out there, and even inside your own companies, how do you even know? How are you making better things? Do you feel that way? Do your customers feel that way?
So there's a lot of emphasis now on tool making and using tools and building systems. But I think in the end, as product people, our job is to make something good. Today, I think there's been several talks about software factories, and I think that the industry has been obsessed with this idea a long time: how do we scale and optimize the output our organizations do? I think it makes sense, and it is important to move fast and do things. But this started even before AI.
I think before AI, the idea was that we need to hire more people. We create very specialized roles so they work in their own ways. Then, because there's a lot of people, we create more process. Because we have process and a lot of people, we actually don't even know anymore what people are doing or what they're supposed to do. So we run experiments. The data tell us what works and what doesn't. This is all to scale: how do we get more output? How do we get more output from the organization? But again, my philosophy, as always, is more output isn't better. I think what we want to build is better experiences for the customers.
One of my messages today is that you can build the software factories, and you can automate things, and that all makes sense. But as an organization, don't become one. Don't become a software factory where you outsource all the work and thinking to somewhere else and just focus on how efficient the output can be, because the output is not the product. Customers are not buying the lines of code. They're not buying the experiments, or they're not buying a lot of things. So in the end, if you want to sell something or make some good product, you have to make something someone wants.
When I think about making things, I think about two things. Making products produces two things: the product and the learning. Historically, building products or designing them, it's always created this learning as well. When you are struggling, trying to think what you should build, how you should build it, which way, what kind of shape does it take, you have all these questions you are asking. Maybe you're answering them yourself. Maybe you go talk to someone. Maybe you talk to the customers and try to find the answer. So the actual effort you put into building things also teaches you something about what the problem is, what the customers want, or what is their view. We're in this time now that there's a little bit this danger of losing that direct connection with the learning.
I think if you think about any great company out there, or companies that create great products, you probably respect their product, but you probably also respect their team. It's kind of obvious, but products are produced by the team in the company. The better the team, the better they understand the space they're in, the better skills or talents they have, the better taste they have, the better they build things. Great companies consistently are able to build great things because they have this culture and context built around how to think about things, what matters, what doesn't matter. This is all the context around customers, about the product space they're in, the technologies they can use, the judgment the team uses to make decisions, the taste they have to actually find what is good, and all the history of the different things they've tried or what they decided.
The image here is just an illustration of this kind of compounding learning. It's a Formula 1 steering wheel, which started with a very traditional form. But over the decades, the team learned how to really make it better and make it something that makes sense for this use case. Formula 1 cars, they don't need a lot of turning radius. So you need a lot of small movements and controlling the car at high speed. It's very fine movements, and that's why the actual steering wheel ended up different than what we typically see in cars.
The danger really now with the product organization is that the more we automate stuff for AI to do, and the more we automate it or tell teams to use AI, you create this separation from execution and from the learning. It's not necessarily a bad thing. Why I'm calling this out is that if this is the case and this is happening in your company, how are you going to fix it? Eventually, if you don't learn from the work you do, I think you would lose the advantage of what you have currently in your space or in your company.
One way to think about it is: what is good to automate? What is good for people to do? I think there's definitely things that are repeatable and maybe not something you learn a lot about. Even at Linear, we do now how to fix bugs. We use the Linear loop to investigate the bug. It will connect to Datadog and Sentry and other tools. It will try to look into the codebase and try to understand where the bug is coming from, and then it will write a fix. So it saves time for the engineers. They don't have to investigate the problems. They come and verify the result, and sometimes they make little changes for those results. The idea is: how do you save time now with these new tools, but without really outsourcing everything?
Where I think the team should spend more time is in the customer space and the customer problems. From the beginning of the company, we've been pushing the engineers and all the team members to really go connect with the customers, join the Slack channels, join the shared Slack channels, answer their questions, ask them questions, and stay close to the customer and build your customer intuition that way. I think now, if engineering or other roles have some time savings, there's areas they can do more in. They can spend more time with customers. They can explore more things. They can train their judgment or make better quality work than they previously had time to.
So the goal, I think, really for the product organization in the future is: how do you keep this learning loop happening? How do you have context and bring signals from that context and bring those learnings into the whole team and the whole company? I think actually now AI can be a great tool in this. A lot of times, people focus on what AI can do, what it can execute, but not what AI can teach you.
For example, at Linear, what we do is that we use AI to help us to build this context. We collect all the customer information that we can. We have automations that pull customer feedback from sales calls and other meetings, as well as from support emails and internal discussions. That builds a place for the customer context.
Something I started doing recently is that the problem previously, I think, in a product organization, especially if it's a large one, a lot of people start being away from the customer problems and the day-to-day problems, because there's so much of it. You don't have the time to follow up with everyone or look at every single email or every request. But what I started doing is that we collect all this context, but then I send watchers, an agent to watch it and tell me when there's something interesting for me.
One of these things I set up is this daily briefing about AI workflows. What are the customers saying about their AI workflows? I want to learn more from it because I've seen a lot of companies do it very differently. Today, I think there's no clear best practices. Every company does their stuff a little bit differently. That's why I'm trying to learn more: what are all the ways people are using these tools? What do they want from us, and how can we help them better? It doesn't take a lot of time from my day to just read this. It gets a few bullet points usually, but I get this daily briefing basically saying what these customers are saying about the AI workflows.
On the judgment side, I wanted to highlight a couple things we do. What I've also noticed is that when companies start using AI more and agents more, people start siloing themselves. A lot of people are working alone with their agents, building things. I think it's efficient, but then there's also the problem that we're not learning from each other anymore, or as much.
One of the practices we started doing is this Quality Wednesday. This happened because, as we keep hiring people, we notice that not everyone has the same standard or understanding of what quality means. So we task everyone to go every week, spend some time, look into the product, try to find one quality defect in the product, and then fix it. It can be very small. It can be a weird hover state, a janky animation. It can be a copy error. It can be something else. It doesn't mean that it should be a huge project. It could be a five-minute fix.
The bigger impact with this is not really that we do these fixes. We do like that too. But the bigger impact is that everyone trains themselves to look for this. They train their eye to notice the small mistakes. Then, because we do this in a meeting, everyone shares their findings and their fixes. Everyone can learn from that and see how other people are finding these problems.
The second thing we do for new features is this feature roast. It's a little similar but a little different, where it's this optional meeting. Anyone in the company can join. The team who is building the feature hosts this, and what they ask people to do is just critique the whole feature. You can be as nitpicky or confused or whatever you want. You just put your raw feedback, and it's not personal. It's just, this is how I see it. The team can still interact with the people and ask them questions if they don't understand something.
Again, we're trying to train people on what matters and what we care about, and also give the team who is building the feature a little more realistic way to see how the users would think about the feature. For a lot of people in the company, this is the first time seeing the feature. So if they are confused, it's likely that the users are confused too. After that, the lead can synthesize the feedback and group it and make some kind of actionable issues out of it, and then they can fix it.
But I think the important part is that these are done together, and there's this discussion that happens with these meetings. Everyone can learn from each other. When you're building your own product or your own feature, you remember one of these discussions, and you know that, oh, that person always cares about the onboarding, or they care about this animation. So I should check into that and remember to do it so I don't get that feedback.
Really, the ask is that we have this idea that AI can do a lot of stuff, and let's make everything more efficient. Let's produce more. But if AI is really efficient and it's saving time, then maybe there's an opportunity to spend more of that time on something else. Rather than focusing on the execution, we could start focusing on the customers, the explorations, the critiques, the quality, or even the reflection of what we do. I think in the future, in the product organization, maybe the work we do changes, and we move away from spending so much time on the execution, but actually going a little more abstract and thinking about the actual activities. How do we become better as a team, and how can we become better as a product organization?
What I said earlier, I think companies often compound understanding of the work and the problems they solve. I think there's an important aspect that you should have some kind of place where you put this stuff. There's some place that's available for learning about the customer context, or learning about your product thinking, or learning about anything else you're doing. I think that it's important for the people, but it's also important for the agents. A lot of times, I can now ask the agents: what do we have about this? Or teach me something about the customers. What are they saying, and what are they doing, and how is the team responding to that? I think there is value in creating this shared space where this context lives around the customers and the product and the work that is happening around the product.
I will end this with this: I think that the tools will keep improving. I think we will keep watching the tools, and I think we will keep automating more and more stuff. But my view is that we should automate more of the known things, the things that are repeatable and maybe are not that impactful. It's not something we can learn a lot from. My hope is that we can spend more time on how we build the understanding of what we're doing in this company or in this product organization. How do we make sure that the team is learning from something and from someone, from somewhere, and not just executing the next prototype or the next idea or something?
At Linear, we don't run experiments. We tell people to use their intuition. But I often tell people that intuition is not some magical force like in Star Wars or something that happens to you. It is something that you have learned while working on something or listening to customers or something. Intuition is basically your training in your brain that you have. So the more you can learn and listen and see this context, I think it will compound your personal understanding and then eventually compounds the whole team's.
Understanding. And so in the end, what this talk was about is context becomes the product. It's more that we have this obsession to look at what is the output, the software or the code. But I think in the end, I look the other direction. It's like, what is actually creating the software? Who is making the decisions? And that's the people are doing that. And the better context those people have and better understanding they have about what they're supposed to do, I think the products are better.
And so at Linear, I always thought that hiring people is the first step building great products. And maybe it's kind of obvious, but I think sometimes people just think that I need to hire to do something. I need to increase the output. But what you're really trying to do is think about what is the trajectory this person can create for the company? What kind of ideas they have? Do they have the right judgment or taste? How can they use it in this organization?
So in the end, I think more of the product organizations maybe comes around—it becomes the context. More of the work is about managing this context, learning from it, finding ways for the team to come together and learn from it, versus the actual execution of the code or building the thing. So that's what I mean: context becomes the product. Thank—
[applause]
Article published · Updated