Why I took the summer off from AI (and what I learned) | Karri Saarinen (Linear)
In a Nutshell
Karri Saarinen argues that AI tools are improving rapidly but companies risk losing their competitive edge by automating away the learning that comes from direct product work. He advocates using AI to handle repetitive tasks while redirecting saved time toward customer interaction, quality critique, and building shared organizational context. At Linear, this means practices like daily AI briefings on customer feedback and "Quality Wednesday" sessions to maintain team intuition and taste.
These notes were generated by AI and may contain inaccuracies.
I took a break this summer from following artificial intelligence news. I stopped following the news, such as what the latest model is, what it can do, what agents are available, and what new technologies we can use. While I was on this holiday, I thought that when I returned, I might feel that I had fallen behind and that things had changed a lot. But when I returned, I realized that, in fact, not much had changed. There are new models, new technologies, and new agents, but I think ultimately making great products and increasing revenue or building a business is still difficult.
We monitor these tools intensively all the time. There are always new things we can try. It is clear that these tools are constantly improving. They can do more. They can do it faster. They are more capable. But the more important question, in my opinion, is: Are we actually making better things using these tools? Do our work teams improve by using these tools? I don't think the answer is clear. Absolutely yes. If you look around you, and even within your own companies, how can you really know that? How can you be sure you're making better things? Do you feel that? Do your customers feel that?
There is now a great focus on the manufacture and use of tools and the building of systems. But I believe that ultimately, as people who work in products, our job is to make something good. In some ways, I think there were several conversations today about software factories. I think the sector has been obsessed with this idea for a long time: how do we expand and improve the outputs of our institutions?
I think that makes sense, and it's important to move quickly and get things done, but this started even before artificial intelligence. I think that before the age of artificial intelligence, the idea was that we needed to hire more people, create highly specialized roles for them to work in their own ways, and then because of the large number of employees, we would invent more procedures. Because of these procedures and the large number of people, we actually ended up not knowing what the employees were doing or what they were supposed to be doing. Therefore, we conduct experiments. Experiments and data tell us what works and what doesn't. All of this is for the sake of expansion, such as how to get more output, and how to get greater productivity from the organization.
But again, my philosophy has always been that more output does not necessarily mean better. I believe what we want to build is better customer experiences. One of my messages today is that you can build software factories and you can automate things, and that makes sense, but don't turn your organization into just a factory. Don't become a software factory where you outsource all the work and thinking, and focus only on the efficiency of the outputs; Because outputs are not the product, customers do not buy lines of code, nor do they buy only experiments, nor do they buy many other things. So ultimately, if you want to sell something or make a good product, you have to make something that people want.
When I think about making things, I think about two things. The manufacturing of products produces two things: the product itself, and the learning. Historically, building or designing products has always created this type of learning as well. So when you struggle to think about what you should build, how you should build it, in what way, and what form it will take? You ask yourself all these questions, and maybe you answer them yourself, or you go and talk to someone, or maybe you talk to customers to 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 their point of view is.
We now live in a time when there is a looming danger of losing that direct connection with the learning process. I think if you think about any great company or companies that create great products, you probably respect their product, but you also respect their team. I believe that products are usually produced by the team within the company, and this is fairly obvious; The better the team, the more accurately they understand their field, the better their skills or talents, and the more refined their taste, the better their ability to build things. Therefore, great companies are consistently able to build great things because they have this culture and context built around how they think about things, what is important and what is not. This includes all context relating to the customers, the product area they work in, the technologies available to them, the judgment the team uses to make decisions, the taste they have to distinguish good, and the history of things they have tried or decisions they have made.
The image here illustrates this type of cumulative learning. It's a Formula 1 steering wheel, which started out very traditional, but over the decades the team has learned how to really make it better and how to make it suitable for this use case, where Formula 1 cars don't need a large turning radius. You need a lot of small movements and control of the car at high speeds. These are extremely precise movements. This is why the steering wheel ended up looking different from what we usually see in regular cars.
The real danger now for organizations that deliver products is that the more we automate tasks using artificial intelligence, and the more we ask teams to use it, the more we create a kind of disconnect between execution and learning. This is not necessarily a bad thing. But what I'm pointing out is, if this is the case, and if this is happening in our company, how will you deal with it? Ultimately, if you don't learn from the work you do, I think you will lose the advantage you currently have in your field or company.
One way to think about it is: What good things can be automated? Perhaps: What are the things that humans are best suited to do? I definitely think there are repetitive things that you probably don't learn much from. Even at Linear, we are now automating software bug fixes. We use the "Linear loop" tool to investigate errors. It connects to "Data Dog", "Sentry" and other tools. He will try to search the codebase and attempt to understand the source of the programming error. He will then write a repair for it. This saves time for engineers. Because they do not have to investigate the problems. They come to check the result. Sometimes they make minor changes to those results. But the idea is how to save time now using new tools, without assigning everything to others.
I believe the area where the team should spend more time is the client space and client issues. From the beginning, we have been telling everyone in the company, urging engineers and team members to actually communicate with customers, join Slack channels and Slack community channels, answer their questions, ask them questions, stay close to the customer, and build your intuition about the customer in this way. And I think now, if engineering or other roles have some spare time, there are areas where they can do more, such as spending more time with clients, exploring more things, training their judgment, or delivering better quality work than they previously had time to do.
So, I think the real goal of a product organization in the future is how to maintain the continuity of this learning cycle? How do you get the context, bring in signals from it, and communicate those lessons learned to the entire team and the entire company? I think artificial intelligence could be a great tool in this matter now. Often, I think people focus on what artificial intelligence can do and what it can accomplish, not on what it can teach you. Therefore, I believe that we at Linear are using artificial intelligence to help us build this context. We collect all customer information that we can obtain. We have automated systems that pull customer feedback from sales calls and other meetings, as well as support emails and internal discussions. This creates a kind of space dedicated to context, and a space for the client's context.
Recently, I started implementing something. The problem previously in product companies, especially large ones, was that many people started to get away from customers' daily problems because of their sheer number, and they didn't have time to follow up with everyone or check every email or request. But what I started doing was collecting all these communications, and then assigning monitors or agents to follow up on them and inform me when there was something of interest to me. So, one of the things I've prepared is this daily briefing on the AI workflow. What do customers say about their AI workflow? I want to learn more about that because I've seen many companies doing it in very different ways. Currently, I don't think there are any clear best practices. Every company does its business in a slightly different way. That's why I'm trying to learn more about how people use these tools, what they want from us, and how we can better help them. Therefore, reading this doesn't take up much of my time each day. It's usually just a few points, but I get this daily briefing that tells me what customers are saying about the AI workflow.
From an evaluation perspective, I wanted to highlight some of the things we do. I also noticed that as companies start using artificial intelligence and proxies more, employees begin to isolate themselves. Many people work alone with their agents to build things. I think this is effective, but the problem is that we no longer learn from each other as much as we used to, or as much as we used to.
So, one of the practices we started with is "Quality Wednesday". This happened because, as we continued to hire new people, we noticed that not everyone had the same standards or understanding of what quality meant. Therefore, we assign everyone each week to take time to look at the product, try to find one quality flaw, and then fix it. It can be very simple. It might be a strange mouse cursor movement or a jittery animation. There might be an error in the text. It could be anything else. So this doesn't mean we have to undertake a huge project. It could be as simple as a 5-minute repair. The greatest impact of this does not lie in simply carrying out these reforms. We do that too, but the bigger impact is that the team trains everyone to research these things themselves. For example, they train their eyes to notice small mistakes. Because we are doing this in a meeting, everyone shares the results and solutions they have reached. Everyone can learn from this and see how others discover these problems.
The second thing we do for new features is "feature preview". It is somewhat similar, but slightly different in that it is an optional meeting. Anyone in the company can join it. The team that builds the feature is the one hosting this meeting. What they are asking people to do is simply criticize the entire feature. You can be precise in your observations, or vague, or whatever you want. You are simply giving your direct feedback and it is not taken personally. Simply put: this is how I see things. The team can interact with the attendees and ask them questions if they do not understand something. Again, we are trying to train people on what is important and what we care about. Also, we give the team building the feature a more realistic way to see how users might think, since many employees are seeing the feature for the first time. So, if they are confused, the users are likely to be too. After that, the administrator can compile, categorize, and convert the observations into actionable tasks. I think the important part is that these things are done together, and there is a discussion taking place in these meetings that allows everyone to learn from each other. When you work on your own product or feature, you remember one of these discussions and know that that person always cares about the welcome phase or this particular movement. So, I need to check that, and remember to do it so that I don't receive those comments.
My real request is that we embrace the idea that artificial intelligence can do a lot of things, so let's make everything more efficient. Let's produce more. But if artificial intelligence is truly effective and saves time, then perhaps there is an opportunity to use that time for something else. Instead of focusing on execution, we can start by focusing on customers, exploration, critique, quality, or even reflecting on what we do. I think that in the future, the nature of our work in product management may change, moving away from spending a lot of time on implementation, and towards a more abstract approach, where we think about the actual activities and how we develop ourselves as a team and as a product manager.
What I said earlier is that I believe companies often double down on their understanding of the business and the problems it solves. Therefore, I believe that an important aspect is having a specific place to put this information. A place available to learn about the customer's context, or to understand how to think about the product, or to learn about anything else you do. I believe this is not only important for individuals, but also for intelligent agents. Currently, I can often ask agents what we have on a particular topic or ask them to teach me something about customers. For example: What are they saying? What are they doing? And how does the team respond to that? I believe there is value in creating a shared space where this context lives around customers, the product, and the work being done.
I will conclude by saying that I believe the tools will continue to improve. I think we will continue to monitor tools and automate more tasks, but my view is that we should automate the known and repetitive things that may not have a huge impact. These are not things from which we can learn a lot. I hope we spend more time on how to build a deeper understanding of what we do in this company or in the product management department. How do we ensure that the team learns from something, someone, or somewhere, and not just implements the next prototype or the next idea? At Linear, we don't conduct experiments in the traditional sense. We ask people to use their intuition, but I also tell them that intuition is not a magical power like the one in "Star Wars" that suddenly happens to you. Rather, it is something I learned while working on something, listening to customers, or otherwise. Intuition is essentially the training your mind has received. Therefore, the more you learn, listen, and become familiar with this context, I believe that will double your personal understanding, and consequently, double the understanding of the entire team in the end.
Ultimately, what I wanted to say in this presentation is: the context becomes the product. We are obsessed with looking at outputs, software, or code; But I think that, in essence, it requires looking in the opposite direction. It's about who actually creates the software, and who makes the decisions. They are the people who do it. The better context and more accurate understanding these people have of what they are supposed to do, I believe the products will be better. Therefore, at Linear I have always believed that hiring people is the first step to building great products. It may seem obvious, but I think people sometimes assume that I need to be employed to accomplish a task. I just need to increase the output. But what you're really trying to do is think about the path this person can make for the company. Such as the type of ideas they possess. Do they have sound judgment or good taste? How can they utilize that within this organization? Ultimately, I think more production institutions are context-centric; A larger part of the work involves managing this context, learning from it, and finding ways to bring the team together to learn from it, rather than just executing code or building things. This is what I mean when I say that the context becomes the product.
Keep Lenny's Podcast in your library
Save the videos and channels worth coming back to, and find them again in one place.
