Context is now the product: Product leadership when software can build itself | Karri Saarinen

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. So I took a break this summer from paying attention to AI. I stopped following the news, like what is the latest model, what can it do? What agents do we have and what are the new techniques we can use? And when I was on this vacation, I thought like when I come back, maybe I will feel left behind. Maybe things changed a lot. But I realized that 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 like in the end, making great products and building like increasing revenue or building the business, like it's still hard. So it made me wonder, how much attention are we really paying to these tools? Like, 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, like, are we actually making better things with these tools? And are our teams getting better with these tools? And I don't think that That answer is clear, clearly yes. Like, if you look out there and like even inside your own companies, how do you even know? Like, are you making better things? Do you feel that way? Does your customers feel that way? So there's a lot of emphasis now on toolmaking and using tools and building systems. But I think like in the end, like as product people, our job is to make something good. And so in some ways, like today, I think there's been several talks about software factories. And I think that the industry has been, I think, obsessed with this idea a long time. Like, how do we scale and optimize the output our organizations do? And I think it makes sense and it is important to move fast and do things. But this started even before AI. And I think before AI, the idea was that we need to hire more people. We create very specialized roles so they can work in their own ways. And then we create, because there's a lot of people, we create more process. And 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. So experiments, the data tell us what works and what doesn't. And this is all to scale. How do we get more output and how do we get more output from the organization? But again, my philosophy has always been that more output isn't better. I think what we want to build 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 just 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 can the output 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, like, 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 2 things. So making products produces 2 things: the product and the learning. Historically, building products or designing them it's always created this learning as well. Like when you are struggling, like trying to think like what you should build, how you should build it, which way, which kind of shape does it take? You have all these questions you are asking and 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, it's also like teaches you something about what the problem is, what the customers want or like what is their view. So we are kind of like in this time now that there's a little bit this danger of losing that direct connection with the learning. And I think like 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. And I think like products are usually just Like, it's kind of obvious, but they're like, they're produced by the team in the company. And 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. And so, like, great companies, they consistently be able to build great things because they have this culture and context built around, like, how to think about things, like, what matters, what doesn't matter. So, this is like 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. And the image here is just an illustration of this kind of like compounding learning. It's a Formula 1 steering wheel, which started with very kind of traditional form, But over the decades, the kind of like the team learned how to really make it better and make it something that makes sense for this use case. Like Formula 1 cars, they don't need a lot of turning radius. So you need a lot of like small movements and like controlling the car at a high speed is very fine movements. And then 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 to AI to do, and more we automate it or tell teams to use AI, you kind of like create this separation from execution and from the learning. It's not necessarily a bad thing. It's what I'm calling this out is that if this is the case and this is happening in your company, like, how are you going to fix it? Like, eventually, if you don't learn from the work you do, I think eventually you would lose the advantage of what you have. currently in your space or in your company. One way to think about it is, like, well, what is good to automate? Maybe 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. Like, even at Linear, we do now auto-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 some time for the engineers. Like, they don't have to investigate the problems. They come and verify the result. And sometimes they make little changes for those results. But, so, the idea is, like, how do you save time now with the new tools, but without really, like, outsourcing everything? So, where I think about, like, the team should spend more time in is in the customer space and the customer problems. From the beginning, we always told, of 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 kind of stay close to the customer and kind of build your customer intuition that way. And I think now, if engineering or other roles, have some time savings, I think there is areas they can do more in. Like, 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 like, how do you keep this learning loop happening? Like, how do you have context and bring signals from that context and bring those learnings into the whole team and the whole company. And I think, like, actually now AI can be a great tool in this. So a lot of times people, I think, focus on what the AI can do, what it can execute, but not what the AI can teach you. So I think, for example, at Linear, what we do is that we use the AI to help us to build this context. So 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. And that's kind of like builds this like a place for the context and place for the kind of like the customer context. And then like something I started doing recently is that the problem previously, I think in a product organization, especially it's a large one, a lot of people start being kind of away from the customer problems, from the day-to-day problems. Because there's so much of it and 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 sent this like a watchers, like an agent to watch it and see, tell me when there's something interesting for me. So 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, we— I think there's no clear best practices. Every company does their stuff a little bit differently. And so that's why I'm trying to, like, learn more, like, what are all the ways people are using these tools? What do they want from us? And how can we help them better? So this can— it doesn't take a lot of time from my day to just read this. It gets few bullet points usually, but I get this like a daily briefing basically saying like these are the customer, what they're saying about the AI workflows. On the judgment side, I wanted to highlight a couple of things we do. I think what I've also noticed that when companies start using AI more and agents more, people start siloing themselves. Like a lot of people are working alone with their agents building things. And I think it's efficient, but then there's also the problems, like, we are not learning from each other anymore, or as much. So, one of the practices we started doing is this Quality Wednesday. And this happened because we, as we keep hiring people, we noticed that not everyone has the same standard or understanding what the quality means. And so, we tasked 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 weird hover state, like janky animation. It can be a copy error. It can be something else. So it doesn't mean that it should be like a huge project. It could be like a 5-minute fix. The bigger impact with this is not really that we do these fixes. We do like that too. The bigger impact is that the team trains, everyone trains themselves to look for this. Like, they train their eye to notice the small mistakes. And 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. And then 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 then what they ask people to do is just critique the whole feature. Like, 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 like, this is how I see it. And the team can still, like, interact with the people and ask them questions if they don't understand something. Again, like, we are trying to train people that what matters and, like, what do we care about. And also, like, kind of train, give the team who is building the feature a little more, like, realistic way to see what maybe how the users would think about the feature. Because a lot of people in the company, this is the first time for them seeing the feature. So, if they are confused, it's likely that the users are confused too. And then, like, after that, the lead can synthesize the feedback and make group it and make some 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, and that kind of gives everyone a little more— everyone can learn from each other, and they notice when you're building on 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. So my, really, the ask is that we have this idea that, well, 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 to something else. Rather than focusing on the execution, we could sort of start focusing on the customers, the explorations, the critiques, the quality, or even the reflection of what we do. I think, like, in the future, the product organization, maybe that 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, like, thinking about the actual activities and, like, how do we become better as a team and how we can become better as a As a product organization. What I said earlier, that I think companies are often compound understanding of the work and the problems they solve. So, I think there's an important aspect that you should have some kind of place where you put this stuff. Like, there is 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. And then I think it's important for the people, but it's also important for the agents. So I think now a lot of times I can now ask the agents like, what do we have about this? Or teach me something about the customers. Like, what are they saying? Like, what are they doing? And like, how is the team responding to that? I think there is a value of like creating this like a 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, that I think that the tools will keep improving. I think we'll keep watching the tools, and I think we'll keep automating more and more stuff. But I think my view is that we should automate more of the known things, like 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, like, we can spend more time, like, how do we build the understanding of what we're doing in this company or in this product organization? Like, how do we make sure that the team is learning from something and from someone or somewhere and not just executing the next prototype or the next idea or something? Because I think we at Linear, we don't really run experiments. We tell people to use their intuition, but I also tell people that intuition is not some magical force that, like in Star Wars or something, that it just 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. And 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 that context becomes the product. And 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, it's, it's, I look the other direction. It's like, what is actually creating the software? Like, who is making the decisions? And that's the people are doing that. And the better context those people have and like 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 like trying to do is think about like what is the trajectory this person can create for the company? Like what kind of ideas they have? Like do they have the right judgment or taste? How can they use it in this organization? So in the end, I think like more of the product organizations maybe comes around the It becomes the context. Like, most of work is about managing this context, like, learning from it, finding ways to 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, like, context becomes the product. Thank you. Thank you, Lenny.