Why I took the summer off from AI (and what I learned) | Karri Saarinen (Linear)

Alright, good afternoon, everyone. Um, 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. Um, I—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—I was on this vacation, I thought, like, when I come back, maybe I will feel left behind, maybe things change a lot.

But it 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, that 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 we're 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 the, I think, 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 tool-making and using tools and building systems.

But I think, like, in the end, like, as a 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 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, like, 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, like, what works and what doesn't. And this is all to, like, scale. Like, how do we get more output? And like, how do we get more output from the organization?

But again, like, my philosophy is always that more output isn't better. Like, I think, like, what we want to build is, like, better experiences for the customers. One of my messages today is that don't—like, you can build these software factories and you can make and you can automate things and that all makes sense.

But just, like, 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, like, just focus on, like, how efficient can the output be? Because the output is not the product.

Like, 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 two things. So making products produces two things: the product and the learning. Historically, the building products or designing them, it's always created this learning as well. Like, when you are struggling, like, 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.

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 of 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, like, the better they build things.

And so, like, great companies, they're consistently 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 One 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 One cars, they don't need a lot of turning radius. You need a lot of, like, small movements and, like, controlling the car in 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. Like, what I'm calling this out is that if this is the case and this is happening in your company, like, how do 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 out-of-fix box.

We have a, 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 code base and try to understand where the bug is coming from.

And then it will write a fix. So it saves time for the engineers. Like, they don't have to investigate the problems. They come and verify the result. And sometimes they make small 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, at the beginning of the company, we've been pushing the engineers and all the team members really go connect with the customers, join the Slack channels, join the shared Slack channels, answer their questions, ask them questions, and, like, kind of, like, stay close to the customer and kind of, like, build your customer intuition that way.

And I think, like, now, if engineering or other roles have some time savings, I think there's 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 AI can do, what it can execute, but not what 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, 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 if it's a large one, a lot of people start being kind of away from the customer problems or 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, 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 kind of, it doesn't take a lot of time from my day to just read this.

Like, it's 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 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're 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 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 weird hover state, like janky animation.

It can be a copy error. It can be something else. So it doesn't mean that, like, it should be, like, a huge project. It could be, like, 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 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's 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're trying to train people that what matters and, like, what do we care about.

And also, like, kind of give the team who's 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 a 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 kind of actionable issues out of it. And then they can, like, fix it.

But, like, I think the important part is these are done together. And there's this, like, discussion that happens with these meetings. And that kind of, like, gives everyone a little more, everyone can learn from each other. And they notice, like, 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 must, I should check into that and, like, remember to do it so I don't get that feedback. So my, like, really the ask is that we have this idea that, well, AI can do a lot of stuff and, like, 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. Like, 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, 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 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'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. 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's 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 will keep watching the tools and I think we will 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 use, we tell people to use their intuition. But I also tell people that intuition is not some, like, 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 compound the whole team's understanding.

And so in the end, what this talk was about is that context becomes the product. And, like, 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, 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 theright judgment or taste? How can they use it in this organization?

So in the end, I think, like, more of the product organizations may become around the context. Like, more of the 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.