Most SaaS Companies Got AI Wrong. Linear Waited.

SPEAKER_02

Everyone will have many agents and companies will build their own agents.

SPEAKER_00

Linear becomes like a system for guiding the agents and building this context. This is the perfect business for this era because it's still SaaS. You're the one who has this sticky interface because it's where everyone is kicking things off from and where they're recording all the information. But you don't have to pay for any of the actual tokens.

SPEAKER_00

Kari, welcome to the show. Oh, thanks. Thanks for having me. Really, really great to finally meet you. You are the co-founder and CEO of Linear. Little known fact, the first time I ran into Linear, it was because we were using it in 2020 at the very beginning of Every to act as our content management system for the newsletter. And at the time it was very hush hush. You couldn't get access to it, but everyone, if you knew, you knew that Linear was amazing. And we use it for a while and really loved it. But then we realized it was made for software, not publishing articles. So we moved off of it. But it was really cool while we did it.

SPEAKER_00

And I've always admired the level of taste and craft that you bring to what you build. And also, I think the level of thoughtfulness and patience that you build it with. And I think that's one really interesting thing is the way that you built the company originally was to keep it closed for a while, not raise too much money, not put crazy expectations on the company. And I think that's also something to do with how you approached AI. You guys are really in AI right now. When I think about the companies that are successfully transitioning into this moment, that were started in the pre-AI era, Linear is definitely on that list.

SPEAKER_00

You know, OpenAI came out with Suno the other day. And the main thing that it hooks into is Linear. And you've successfully transitioned the product to be really agent native. And so, but when GPT-3 first came out, I didn't see anything about that on Linear. So I'm curious about that transition for you. What was that like emotionally to have built this product for a particular way of working and a particular way of building software and then see the world change, but maybe not be totally sure if this was going to be the thing. And then eventually it'd be like, this is the thing we need to rebuild the product or change how the product works in a significant way.

SPEAKER_00

Like, talk to me about that. Yeah. [SPEAKER_02] Well, first of all, thanks for being an early user. [SPEAKER_02] And I think the thinking has always been the same. [SPEAKER_02] It's we just want Linear to be the best product in this category and help companies move work forward and build software products. [SPEAKER_02] And in some ways, this new AI stuff doesn't really change that mission. [SPEAKER_02] It maybe even improves it. [SPEAKER_02] And our goal was always that Linear can take more of the burden of running these product teams or figuring out things to do or figuring out when to do them and let the product teams or the individuals actually build the things.

SPEAKER_00

[SPEAKER_02] And now they can build it with AI or the AI builds it. [SPEAKER_02] So in some ways, the mission for us didn't change.

SPEAKER_02

Yeah. Actually, I think the AI is making it better because now we can automate more and take more of that burden and let people use their craft or use their taste or thinking in it. But I think we do have, and I personally always have this problem, a way of addressing problems, which is I come from a design background. So a lot of times the way I approach things is first, I'm trying to understand them. So this sounds obvious, but then I think what happens in the tech world, a lot of times people don't try to understand things. They often jump into that, oh, I can do this. So I'll do it now. But did you think should you do it or does it actually help you?

SPEAKER_02

So that was our thinking with the early AI and the chatbots, every company is rushing into this moment as hey, we are now an AI company because we have this chatbot integrated. And we tried that too internally. And then we just realized this is not really that useful. How do you actually use, what is the workflow where you would actually need this or use this? So we spent a couple of years now trying to understand these workflows, how do people actually want to use these things? And we did a couple of things well, though, I think we released this agent platform, so it's an open platform with very good docs, and agents can build the integration themselves using the docs.

SPEAKER_02

And because of that, we now have most of the coding agents or agents out there integrated with Linear and this is like OpenAI brought their Codex, their cloud agent in there, because we just have this available. So I think we kind of saw this world that there's not going to be one agent, but everyone will have many agents and companies will build their own agents, which we're now seeing with Coinbase and Ramp who are our customers, and they built their own homegrown coding agents, which then integrate with Linear. So Linear becomes a system for guiding the agents and building this context.

SPEAKER_02

We don't try to own everything in this world or in this market, we can play with other people, other companies too. So the approach was much more like, how do we understand the workflows, what is actually valuable, and what people could use these tools for versus just jumping into well, everyone else is doing this thing, so we should do it too. And by the way, now we are adding a chat interface into Linear, but it's much more like there's tools and there's skills and there's more understanding, we gather how you should use it, you can use it to synthesize customer requests, because that's what Linear can handle, Linear is a place for customer problems or requests or other

SPEAKER_02

So I think the approach was much more like, how do we understand the workflows, what is actually valuable, and what people could use these tools for versus just jumping into well, everyone else is doing this thing, so we should do it too. And by the way, now we are adding a chat interface into linear, but it's a lot more like, there's tools and there's skills and there's more of understanding how you should use it. You can use it to synthesize customer requests, because linear can handle that. Linear is a place for customer problems or requests or other things. So now a linear agent can natively work through those and see patterns or things like that. And that's the, we're trying to bring clarity and context to the organization, which they can then use as part of AI building workflows. So because once the AI builds more and executes more, the problem only becomes how do you productively harness this in a good way. You can task a million agents doing something, but should they be working on those things? Probably not all of those. If you don't think about it, probably a lot of that work is not necessarily that useful. You need to have some kind of decision making process of like, is this actually important? Should we do this? And linear is a way to do that and build that intent and build that context and then build it with the agents. There's an interesting thing going around right now, I don't know if it's a meme or a mind virus or what, but the stock market thinks that SaaS is dead. And I think you're pointing to something really interesting, which is this dynamic where a couple years ago, a lot of companies, including a lot of SaaS companies, rushed to chatbots. And I think a big part of that is, well, we know this thing is happening, so we have to at least show that we're doing something. And I think that the market is starting to, the public markets are now starting to look at that and require that. And I imagine when the AI stuff was coming out and you guys were maybe testing AI features, but weren't releasing them, I imagine there was some pressure, maybe from investors or from yourself, or maybe internally to do something. And it seems like you waited until you had the fat pitch. And I'm curious if that is true, what that was like and what you think it means for all of the public market companies, all the public market SaaS companies that are down right now and whose CEOs are like, well, I guess we really need to launch an agent platform or whatever.

SPEAKER_02

[SPEAKER_00] Yeah. I mean, I think there's, we don't really have pressure from investors. That's one benefit of picking the right investors. And also they trust us to make the right calls. And then also we obviously did talk about this, but we also have that discussion. It's like, we just don't see the value right now doing it this way. We need to find the actual real value here that actually helps these companies. And so I think it wasn't like that, but there was definitely internal pressure. And now I think the speed of the market has picked up a lot. Like every month or couple of weeks, there's something changing. And we are tracking those same changes and trying to see where all of this is going. But there's also this, it creates a lot of noise in the market. There's this, oh, now this week someone is doing this loops. And then a couple of weeks later, people are like, no, the loops are a bad idea. And then we, you shouldn't, I think those things are signals that you should read and understand. But you also need to know that a lot of this stuff is not tested. And a lot of times the people testing these things are not testing it in some large organizational context where things actually matter, like if they work or not. And so I think there's that, like we haven't tested all these things, so we can't make these predictions of exactly how things are going to change. I think on the SaaS narrative, I do think the narrative is probably directionally correct, that you switch SaaS companies, you probably have to, as an investor, you kind of have to, there's more uncertainty of the future cash flows because the landscape is changing, you can't expect that everything will stay the same. But I think the narrative is kind of simplistic, like, oh, people will write out their own CRM tools. And I don't think that's exactly going to happen. But I think what might happen is there's new companies that come out, or I think a lot of the public companies are not the most flexible or the most robust solutions out there. They are the big solutions that the big companies use. And there's a certain kind of inertia in there. So I would say that the public companies probably get hit the hardest here, because their moats are kind of disappearing in a way. I think even for us, we consider now it's like, we need to live in this day one world again, where we can't rely on our previous decisions anymore. We have to look at these problems in a fresh way, like, what happens when these things change? What happens when agents come into this product development process? What are the new problems that come out of it? And how do we help that? So we shouldn't be tied into past experience or the past product we have, but see what the future product should be. And I think this is harder for large companies and companies that have existed for decades. So I don't think it's an easy task. And I think growth companies or startups can do it a lot better.

SPEAKER_02

How big is the team now? About 120 total, I think. About half of them, like 60 people, are on the product team. And what was that? What has that transition been like? I assume that over the last couple years, there have been a lot of divided opinions on is AI coding really a thing? Is it just glorified autocomplete? Is it going to eliminate programming as a job? And then how have you, how has that change cycle been to actually go change your workflow, figure out what the new programming workflow is like? How did you get the team in shape to do that? And what did you learn in that process? can do it a lot better. How big is the team now?

SPEAKER_02

About 120 total, I think about half of them, about 60 people are on the product team. And what has that transition been like? I assume that over the last couple years, there have been a lot of divided opinions on whether AI coding is really a thing. Is it just glorified autocomplete? Is it going to eliminate programming as a job? And how have you, how has that change cycle been to actually go change your workflow, figure out what the new programming workflow is like? How did you get the team in shape to do that? And what did you learn in that process?

SPEAKER_02

Yeah, I think there was definitely a time in the company where we had to encourage people to use these tools more. I think there's always habits where you've done stuff this way, so you're less and less interested in trying new tools. But I think now, probably all of the engineering and sometimes our design and PMs also are now using agent coding or coding tools. We don't track any specific metrics. To me, it's like I talk about this sometimes on Twitter, like the biggest vanity metric is how much of your code is agent-written or how many PRs are you merging? And I think that's not the right metric. It measures output, but what does that output do? It doesn't actually generate value. Is it improving the product? If you're measuring these kinds of metrics, you need some kind of counterbalance, like what is actually the quality of this work and is it actually meaningful? And I think what's also playing out in the market is we have large companies that are token sellers. When you have a lot of incentives where your business model is to spend more tokens, your revenue will be higher and your market share will be higher. So there's a lot of incentives saying people should just spend more tokens and not saying, well, think about things and spend it well. I think people are looking at it too simplistically, like if we just spend more tokens, things will be better. But I don't think that's ever been the case. In building products, there's some value in speed and making changes. But then you should also understand any change or addition you make can also have a negative impact. So it's not always like activity is always positive. Sometimes it can be negative too.

SPEAKER_02

What do you think is a more nuanced metric for, if you're judging how well, how in this AI world are we doing our job of figuring out these new workflows and adapting to them and using them in our own work? If tokens or number of PRs submitted or percentage of agent-generated code are not necessarily the right metrics, maybe even in isolation, what do you look at? Or how do you think about it? I mean, I think it's still the classic metrics of profits or revenue or user love or some of these things are what you should be aiming for. Those seem like lagging indicators, right?

SPEAKER_02

Yeah, they are. But I think you should still measure some of these things like token usage per person or by different teams. But you shouldn't take it to the extreme where this is the only metric that matters. You should use it as a signal that are we doing something? And then think, well, is our product actually improving? Do we have any indication this product is actually improving? Do we get comments on the new features? Are there fewer bugs? And I think bugs is actually a measurable metric. If you run an honest bug tracking process where you actually track bugs. And I think now with agents and AI, it's almost like, why do you even have bugs in your product? You should have no excuse for it anymore.

SPEAKER_02

[SPEAKER_00] Internally we have a zero bugs policy. We have a linear team triage and any bugs go there. There's a one week SLA that every bug needs to be fixed. And now with the coding agents, the coding agents can do the first pass on it. And once it's done the fix, it will tag the engineer on it. And the engineer maybe doesn't like it, or there's some changes they want to make. They can do it also now inside linear and they can review the code in linear. So there's a very good workflow for now. But I think it still starts from the fact that do we care if our product is buggy or not? And we have made the choice that bugs are bad things or mistakes, and we should fix them as quickly as we can. And that's a priority to everyone. So I think it still comes down to whether you care about the quality of the output or you just want more output.

SPEAKER_02

What are the ways that these tools have changed your product building workflow, both personally and as an org? And what are the most effective ones that might be surprising?

SPEAKER_02

Yeah, I think on the product side, it's definitely a lot better. I have with linear now a skill where I fed some of our internal docs and blog posts about how we think about product development and made this a linear workflow skill. And then I tell it, okay, look at this, help me understand this feature request. We collect feature requests inside linear. And then, for example, there's a request like multiple assignees per issue. It's requested by lots of people, hundreds of people. And so I tell it to go synthesize, help me understand what are the different reasons people want it? I don't want to just have a request. It starts with explaining the problem, trying to understand the core problem, which is usually what I want to know. So when I see a new request, I might go into linear and say, oh, do we have this kind of request already? And then help me understand.

SPEAKER_02

There's a request for multiple assignees per issue. It's requested by lots of people, hundreds of people. And I'm telling it to go synthesize, help me understand what are the different reasons people want it? I don't want it to just start with explaining the problem, trying to understand the core problem, which is usually what I want to know. So this helps me when I see a new request, I might go into Linear and say, do we have this kind of request already? And then help me understand it. And then it helps me give an understanding, which then helps me, potentially, should we actually tackle this now? Or is this something we could do later? Or maybe never. So before we start building anything, it's helping me understand the problem in a very quick way. I don't have to go ask around or find people to do it for me. On the design front, I actually don't personally use it much. I actually like the manual design process. I still have Figma open, and when I have a problem or idea, I just draw it in there. And to me, my work is often exploring things. So I actually don't think the speed really helps there. I actually like the slowness of the manual thing. Every time you draw something, you have to check on yourself. Why am I doing this? Why am I drawing it this way? Or should I draw it a different way? But the broader team, when the design team works on problems, I think now they are building a lot more prototypes. And we have a quite robust build system. So you can build it into that, you can make a PR, and then it will run the build, and you get the preview link to the build. And then you can use it live in the product. So it helps the testing or prototyping stage of it. But I still tell the designers to explore more freely in Figma first, or wherever, and try to think about how do you approach the problem? Not just jump into doing it. There are projects like that too, where it's very clear what needs to be done. But if it's a bigger project, I think they should still spend that time. On the engineering side, it's probably similar to a lot of other ones. We can fix problems a lot faster once we identify them and decide to do it. We use Slack a lot, and with our Slack agent, we have a discussion, and then we eventually decide, yeah, we should do this. And then we just tackle it, and they're saying, hey, can you create the issues out of this conversation, and then we'll do it? And so it helps us track, come back to it later, and make it actionable right away, versus having a meeting, starting a project, and then assigning people. So I think the pattern in all of those things is it's shortening some kind of loop and making it faster. You can do the thing right away versus waiting for next week or some other time to do it. It's very little effort to do it right away.

SPEAKER_02

[SPEAKER_00] Which is interestingly, sometimes it seems like you're the exact opposite of your preferred outlook. You know, we shouldn't do things faster. Actually, we should take things a little bit slower. How does having tools that make you go much faster interact with that outlook?

SPEAKER_02

[SPEAKER_00] Yeah, I think it's more like, we shouldn't go fast at deciding things or speed running the decisions or not even doing decisions. I think some people do it now where they just have an idea, then they build it. And now we're all looking at this idea that no one really knows why it exists. And should we even do it? Every new prototype or idea can seem useful. But then you don't have a good way of framing how useful this is versus other things. Should we spend the time actually committing to this idea? Because we already have decided on some of the other ideas. So I think there's this danger of not having a decision making way. We don't have a lot of processes in Linear, but it's more like, we want to commit on this. Once we commit on the thing or the fix or the project, then I want it to improve fast. I want the loop to be fast to actually work on the problem. But I don't want the problem finding to be fast. You should take the time to find the right problem and the right approach for the problem. And then once you decide that, then you can go faster on it.

SPEAKER_02

Here's a simple test for whether your AI is actually ready for production. Would you stake a business decision on what it just told you? If the answer is not yet, you're not alone. The gap is in capability because AI can do a lot. It's really about trust. You can't verify the output of the AI. You can't trace the reasoning, and nobody with real domain expertise has touched it. Dialect is a new system from Scale AI that captures how enterprises make decisions and closes that gap. It puts your actual experts in the loop, the people with years of institutional knowledge, and encodes their judgment into your AI systems. Every correction, every override comes with full context. So the next time your AI makes a call, there's an expert's reasoning behind it. That's how you go from a cool AI demo to an AI system you can trust. Visit scl.ai slash dialect. That's scl.ai slash dialect to learn more.

SPEAKER_02

Back to the episode. One thing that what you're saying makes me feel is I totally get that approach. And for myself as a product builder, I often don't know what I'm doing until I do it. And I can't think it through until I've done five different things that I can't explain. And then I'm like, okay, here's the thing. And I understand it. Is what you're saying different from that? Or is it the same, just said differently? Maybe it's different, but I can see that workflow. I feel like that workflow is trying to understand.

SPEAKER_02

dialect to learn more. While I'm doing that, back to the episode. One thing that what you're saying makes me feel is I totally get that approach. And also for myself as a product builder, I often don't know what I'm doing until I do it. And I can't think it through until I've done like five different things that I can't explain. And then I'm like, okay, here's the thing. And I understand it. Is what you're saying different from that? Or is it the same, just said differently? Maybe it's different, but I can see that workflow. I feel like that workflow is understanding what you're doing. And yeah, it's building, it's like making things as understanding.

SPEAKER_02

Yeah. And I think that's fine. I think the problem there just becomes sometimes you don't know. I think conceptual work sometimes in design, I consider this conceptual work where the output of this is a concept. It's not we just shouldn't deliver this necessarily, but this is I made this, I went through this process of understanding this problem and I have a concept for it or I have. What's an example, because I would assume that the output of a design process would be Figma, a Figma that you could export. So what's an example of a concept that comes out of a design process?

SPEAKER_02

Well, I think in the past, in large companies, I've used the concept term to not scare people. So usually it's rethinking some area completely. And that's a concept, it's a concept car. So it's this car won't go into production, but here's some ideas that could influence the next car. So you're trying to sometimes people, I don't know, this is partly a large company thing, but I think it can happen in small companies too, is that once you see something very different, your fears might start coming up. Like, well, if we change this, what else is going to happen? What's going to break? But the point is not right now to decide that, we just decide, does this concept, this new idea have merit? And can we do we think it's important enough for something to take it further and then deal with the problems later? So it's trying to divide which decisions you're making now. And I've used it. Yeah. In our company and other companies, I just completely rework a surface and say, Hey, I think the project should look like this, which is completely different from what it currently is. And then people like, Oh, that's actually interesting. Or they're like, well, it won't work for this and that line. And I'm like, okay, that's fine. And it's a way to.

SPEAKER_02

[SPEAKER_00] Maybe like a figment design or a prototype. So it's I think there's even with all this tooling, the output shouldn't always be we ship something. It's sometimes the output can be something internal that Hey, we just now we have a better understanding of this problem. We can tackle it better. And we can actually make it into a shippable thing. But we first try to think about it before doing it. Right. And to you thinking about it can include building stuff. It's just the reason you're building stuff is not to ship it the next day. It's to understand it better, but thinking can be designing, it can be writing, it can be talking about it, that kind of stuff.

SPEAKER_02

Yeah. And something I did have to share with the company recently was that I like we always care about the quality bar a lot, but I think this thinking process of are we doing the right thing is what we're trying to decide sometimes now with AI, it's actually hard to tell. It's if the tooling changes all the time, people the LLMs are not deterministic anyway, as no, how useful this thing could be. And then there's a moment you just have to decide, yeah, I think we should, obviously we can try this internally, but we also need to try it with customers and you put it into some kind of beta or something that. So I think there's definitely nuance to this right now that there are situations where it's and it's always with product building, there's a limit how much you can think about it inside your company until you need to actually put it somewhere for someone else to use. And then you learn from that use case. But again, it's more like every stage, you have some kind of goal in mind. Like now we've put it to beta, the goal should be understand the workflows and how people use it and how they want it to be better, not to do something else, not to try to ship it as fast as we can or something. We should be honest about what is the actual goal for this stage.

SPEAKER_02

So we've talked about how AI has changed your internal workflow. I'm also curious how it has changed your product strategy and how you think about building products, not the actual work of building products, but what kind of product to build and what, for example, should you let AI agents connect into your product, which I know you've done versus build your own AI into the core feature? Should you have both? What should they be able to do? Yeah, how does it affect your product strategy and your vision for what a good product is?

SPEAKER_02

Yeah. I mean, I would say we are now adding agent, a linear agent that can have context of their work and the context of the organization and the products you build, that you can use in different ways. And they're the PM workflows. You can also as a designer use it the way to understand the problems. And then we will also do a coding agent where you can actually start writing code with the agent.

SPEAKER_02

Interesting. And it will, you can see the diffs online. So it's a cloud conductor and environment where you can kind of see the changes and you can guide it. And we think the strategy has definitely changed. And we are just trying to understand what are the problems of today? We think one of the things is that you can use in different ways. And they're like the PM workflows. You can also as a designer, use it to understand the problems. And then we will also do a coding agent where you can actually start writing code with the agent.

SPEAKER_02

Interesting. And it will, you can see the diffs online. So it's a cloud conductor and environment where you can see the changes and you can guide it. And we think the strategy has definitely changed. And we are just trying to understand what are the problems of today? We think one of the things that is changing is that historically people thought issue tracking is a ticketing system for the kitchen, engineering. So an order comes in, someone orders fish. Now that fish goes into the kitchen, there's a ticket: make fish. And that's how people think about issue tracking. But we kind of never thought about it that way. For us, Linear is more the backbone. We rely on collecting signals and collecting problems or collecting decisions: we should do this thing. So I think there's definitely a shift. We have to teach people these products are really meant to improve your team's workflow, not to be a weird ticketing system for different parts of your organization. And that's probably going away with the agent. So you don't need that anymore. The agent can do those tickets and they can also complete them. But we think there's still value in collecting that context and making something shaping that works actionable and providing agents good context from the environment. But the one lesson we learned with the agents is that it's tough when we are not ourselves in control of it. We do want to support all companies and all agents as much as we can. But if we have ideas for it, we can't do it. It's on them to do it. So now, one of the reasons we are doing this coding agent is we actually think we see a lot more smoother end to end workflow where you don't have to do everything, but you start some of your tasks in Linear. You can ask the agent: hey, does this thing exist already? Or if not, make an issue, make a work stream out of it, and then start working on it and start writing the code. And then you can see the diffs coming in, you can review it, and you can merge it or see the prototypes. So it's trying to solve one of the problems I see when I use Claude or ChatGPT or some of these tools or Codex. I have to really explicitly tell the agent what context to bring. And I think the value with Linear is the context lives there. And if we inject it smartly, part of the work stream, it's much more natural. Or we can design the flow that makes sense. And we don't span the context windows or something. And I think we see this feature is you probably have Linear as the multiplayer or the organizational context of what's happening in the product and what the potential future state of it is. You might still run local agents, but there are situations where you should just automate some of the bug fixes or automate that small task and just do it in Linear. And then let it run in the background in a sandbox while you run your own work on your own computer or somewhere.

SPEAKER_02

That's really interesting. I think from a product strategy perspective, I'm really curious about the decision to integrate your own agents. Because before we did this interview, I didn't know about the Linear agent. And I was sitting here thinking: wow, this is the perfect business for this era, because it's still SaaS. There are no AI token costs, but it is the place where you control all of the AI. So all the other companies have to deal with all the other coding agents and whatever, have to deal with all the token costs: OpenAI, Anthropic, and whatever. But you're the one who has this sticky interface, because it's where everyone is kicking things off from and where they're recording all the information. But you don't have to pay for any of the actual tokens. And it sounds like you're adding a layer where you will have to pay for the tokens. And you may prefer that. And I think the reason you're saying is because tighter integration between the two means you can do more interesting, more powerful things.

SPEAKER_02

[SPEAKER_00] How did you think about that from a business perspective, changing your margin profile that much? I assume there's a lot of interesting discussion there about how adding in token costs changes the business model.

SPEAKER_02

Yeah, I mean, honestly, I think it's something we'll have to see in the future more. We definitely thought about it and have some calculations or thinking on it. I think on the coding agents, we do have to offer usage-based billing, because it's going to get very expensive. On the basic Linear agent functionality that answers questions for you, that should be more included into the system. And we will have a lot more. We will have to see how much the usage actually is. But Linear still is going to be a fairly focused platform for certain kinds of things. You shouldn't be running random things here. I think you should be pretty clear what you should be doing inside Linear and what kind of workflows or workloads are you running there. So we're not trying to build a very generic agent platform. It's just a more product context or product memory platform where you can integrate those agents and you can use Linear agents from other tools too. Or you can bring other tools into Linear. So it's a way to work around your product. And it's an API into the product thinking versus using more of the normal tools where you always have to

SPEAKER_02

linear and what kind of workflows are you running there, workloads. So we're not trying to build this very generic agent platform, it's a product context or the product memory platform where you can integrate those agents, and you can use linear agents from other tools too. Or you can bring other tools into linear. So it's a way to work around your product. And it's an API into the product thinking versus using more of the normal tools where you always have to tell it to go fetch this thing, go find this thing, because it doesn't have any understanding what do you generally do? Or what kind of context that might be existing already? Can we see a demo? I'd love to see it.

SPEAKER_02

Yeah. Is the screen sharing? Okay. Yes.

SPEAKER_02

All right. Yeah. So what we have coming up, this is actually my real linear instance. And what do we have come up is we do have now, if you do a new tab inside linear, that will be the classic box of what do you want to do? There's also this other interface where you can, if you are inside some context, like a project or something, you can do the work there. But, for example, the one we will have skills and the skills we will have guidance, like organizational guidance and a personal guidance, and you can have skill, like personal skills or organizational skills. So for example, what I was mentioning earlier is that sometimes I want to understand problems. So I want to understand this problem of multiple assignees. So I made the skill, which is essentially I fed some materials from our blog, and it's act like a linear product teammate. And then it has this format of it starts with the underlying need. And it has this way it goes through the problem. And I so I made this to help my workflow, something just quickly and trying to understand sometimes this feature request. So I can do it, well, let's do the multiple workspaces. So we have this collection of stuff about multiple workplaces. And then it can go through there, there's probably many different requests. And it will try to start thinking through it, they will look into the customer activities, it will look through the different things. What model is it under the hood? I did, I think we'll eventually have multiple models. But now we use Claude called for this. Sonnet or Opus? I don't actually know.

SPEAKER_02

[SPEAKER_00] So it starts going through, it's like, okay, there's a real need, but it's more complicated than it sounds. So companies maybe want this multiple workspaces for different reasons. And I think my understanding generally is that they want one place to have this billing and governance, but then they might have multiple different divisions in the company. And so it's not they would want to divide that, the team, that workspace more, but they might still have some kind of overarching control. So it goes through the kind of trying to explain, what is missing and what is good about it. It also makes this few recommendations of the product direction. So do this or that on that. So it's it helps to make this something that is quite not complicated into some kind of actionable thing. And I can, we can talk about this as a team or something. But similarly, more a micro example is that if there's I want to make a new theme, new dark theme.

SPEAKER_02

[SPEAKER_00] What's a theme? [SPEAKER_00] Themes are just like in our app, so you can have like, [SPEAKER_00] Oh, okay, got it. Yeah. [SPEAKER_00] Yeah. Like the way it looks. [SPEAKER_00] Yeah. [SPEAKER_00] Yeah. [SPEAKER_00] So maybe I want to create a new version of a dark theme, make it just black.

SPEAKER_02

[SPEAKER_00] So I can now task a coding agent on it. And it should start looking into, it can look into the code base and they can try to understand the code base, obviously. And then at first it's turning it into an issue and then delegating into an issue. So I created this issue, it's in progress, it's still located to linear, and then now linear starts working on it. There's a spinning up the sandbox for it. And I think the pro, one of the benefits on issue is now people know I'm doing this. So the team knows I'm doing this. And I can say like, hey, I'm doing this. So he can also come here to look at this, what is happening? And then the thing is this agent session is visible to everyone. So it's visible to me and to him. So I can call like, once it's, it will take a while, but once it does, we can both jump into this chat and tweak it together if we want to, or just see what happened here. So it's similar to what you do on your computer, but then now it's happening in a shared context. And there's more understanding, where did this come from? Okay. It came from me. If this could come from a customer discussion or a shared context is interesting. So two people can be in the same chat. Yeah. So I know that's really cool. Yeah. I don't have none ready to demo this, but we did have this instance, kind of accidentally, we noticed this is actually useful sometimes is that Anon was our head of product and Connor, who is our head of design, they both were working on some tweaks on the inbox. So they could go back and forth, a PM and a designer could go back and forth. It's like, no, it's not quite right. Let's fix this thing. And then they could both see the kind of the preview link. Let's see if I have something here. Okay. So there's one, my previous pull request. So we will have pull request here. You can see the activity, but you can also see the code. So you see the code diffs. And then if you want to comment on it, or you want to work on this code with the agents, like,

SPEAKER_02

they could go back and forth, like a PM and a designer could go back and forth. It's like, no, it's not quite right. Let's fix this thing. And then they could both see the preview link. Let's see if I have something here. Okay. So

SPEAKER_02

[SPEAKER_00] there's one, my previous pull request. So we will have pull request here. You can see the activity, but you can also see the code. So you see the code diffs. And then if you want to comment on it, or you want to work on this code with the agents, no, this is not right. And then I can work on it and similar workflow works for code reviews where engineer might come in and say, this is not right. They could just task the agent to fix it versus telling the other engineer to fix it. So I think it collapses the cooperation loop a lot more and allows multiple people to use the agents to work on one thing. And then here, this is only a backend change. So there's no client review I can do, but if I had, if this would be a client facing thing, I could open the preview link and then actually see how does it look live? That's interesting. But yeah, those are a few things we're adding. I'm curious about this. One interesting thing about this is it seems to increase the surface area of the product a lot. It's about a lot of different things that already exists to some degree somewhere else. And obviously there are things that you can do differently. So you can have multiple people in a chat. It's more plugged into linear more generally, but you have to recreate a lot of stuff that's already being built by a lot of other companies. So how do you think about that and the trade-offs of that and doing that well, especially entering something like AI coding, where all the big companies are just going as hard and as fast as they can to build AI coding agents?

SPEAKER_02

Yeah, I think there's definitely the question we need to keep asking ourselves, what is our advantage or unique advantage here? And I think, honestly, I don't think we will solve all the different coding needs, but we don't necessarily have to. I think what we see the value is, is sitting upstream where that work is coming from. There's really good leverage there that we can offer to companies where work comes in or bugs come in, they automatically get spawned into agents, delegated to the agents. Engineers never even see them or if they see them, they see them once there's a fix already being built. And so it doesn't work for all kinds of situations. It's not like you go and say, "hey, build me a new product." We don't think that's where we should be working. It's more like you have a large company, you have a lot of things requested from you, a lot of bugs filed in. How do we reduce that workflow for you automatically? And then you can use the other coding agents to do other kinds of work. But this is where we focus on. That's really interesting. But then, generally, we've been thinking about the problems. We don't want to be a kitchen sink product that does everything for everyone. And sometimes companies end up in that state because you have the enterprise buyers and the checklist, and then you just need to get the check mark into the right spot on the checklist. And we don't think those things create a good product experience. So the way we've always thought about it and built the products, it's like we try to feel out what is a natural next step in this workflow. So if we go from an issue, a natural next step is someone needs to fix this. So how do we help people fix it faster? So one option is we do cloud agents and then you take and fix it. But now the cloud agents does this stuff. How do you know it's good? So then you need to see the code, you need to see the diffs, and you need to run the builds. So we are always focused on the workflow and how do we improve it? How do we make the output kind of help companies to output better and faster, versus trying to own every surface?

SPEAKER_02

[SPEAKER_00] So we don't have to own every piece of the surfaces. But we are trying to find this optimized workflow for people to do certain kinds of product things. So we're almost out of time. My last question for you is, if you had to project how product development will change over the next five years, what will be different? And also what will be the same?

SPEAKER_02

I think there's going to be more of this self-driving aspect of it, like you can set up some kind of rules or guidance. And we are building something around a project memory. So you could have a common workflow. What we do is we have projects going on. A project is often a feature, a part of the interface, or part of the product. And then we have a lot of feedback and requests and things coming in. I think there are opportunities to turn that into more of that. The product or that feature is an agent itself. And it tries to make decisions based on the input it creates. And then it can still have maybe ask a certain amount of input, but it could run automatically. It's like, "hey, I'm seeing these patterns, and these patterns are pointing to this solution. And the solution seems to be something that works for people. I built a build, I send it to some customers, and the feedback is good." So it does things on its own, based on some kind of context and a rule-based system or some kind of guidance. And then I do think the thing I'm still focused on is, I think people should still think, even in this world where agents do some of the thinking and run automatically to some degree. I do think it makes people have to be a lot more explicit about what they want. Or how do we, what is worth doing? And what are the areas we should

SPEAKER_02

I send it to some customers, and they say it's good, the feedback is good. So it gives you things on its own, based on some context, and a rule based system, or some kind of guidance. And then I do think the thing I'm still thinking is that people should still think even in this world where agents do some of the thinking and run automatically to some degree. I do think it makes people have to be a lot more explicit about what do they want? Or how do we, what is worth doing? And what are the areas we should be doing? And I think a lot of this still involves humans having meetings, or discussions, or writing issues, or writing documents. I think there's still going to be a place where humans need to understand this stuff. You can't just outsource the thinking purely to the AI agents. But you should, the more you can clarify your own thinking and the strategy, the better it is for your team, and also it's better for the agents too. Because then you can codify some of those strategies or thinking into actual autonomous things. So I think I personally don't see the future in a way that we are replacing humans. And I don't quite believe in it. Maybe I don't want to believe in it. But I think things will change that way, the roles will change. Maybe there's some movement around exactly what does engineering do? How many engineers will we need? And what is the job in the future? But I still don't see how the agents, how the AI actually does all the thinking, and the choices or decisions. I think product building is still a craft or an art. A lot of times we talk about intuition. We just decide things based on what we understand, how we understand the problem. We hardly use any data as part of decision making.

SPEAKER_02

[SPEAKER_00] Sometimes we use it to look at something, but it's more a signal. So I never personally believed in A/B testing and data driven product development, which I think could work well for agents. But I think it doesn't work for all kinds of products. And I also think the best products are not necessarily being built that way. You still need the human touch of what is interesting, or what would make this good? I love it. Kari, thanks so much for joining.

SPEAKER_00

Kari, thanks for having me. This was great.

SPEAKER_00

[SPEAKER_02] Oh my gosh, folks, you absolutely positively have to smash that like button and subscribe to AI and I. Why? Because this show is the epitome of awesomeness. It's like finding a treasure chest in your backyard. But instead of gold, it's filled with pure, unadulterated knowledge bombs about ChatGPT. Every episode is a roller coaster of emotions, insights and laughter that will leave you on the edge of your seat, craving for more. It's not just a show. It's a journey into the future with Dan Shipper as the captain of the spaceship. So do yourself a favor, hit like, smash subscribe and strap in for the ride of your life. And now, without any further ado, let me just say, Dan, I'm absolutely hopelessly in love with you.

SPEAKER_00

SaaS companies that are down right now and whose CEOs are like, well, I guess we really need to launch a agent platform or whatever, you know? Yeah. I mean, I think there's, we don't really have a pressure from investors. Like that's like one benefit of picking the right investors. And also like, they trust us to like make the right calls. And then also we obviously did talk about this, but then we also like have that discussion. It's like, we just don't see the value right now doing it this way. We need to find the actual, like real value here that actually helps these companies.

SPEAKER_00

And so I think it wasn't like that, but there was, yeah, there's definitely like internal pressure. It's like, and now I think that the, the speed of the market has picked up a lot, like every month or something like a couple of weeks, there's something changing. And we are like tracking those same changes and kind of like try to see where all of this is going. But there's also like this, it creates a lot of noise in the market that there's this like, oh, now this week someone is doing this loops. And then a couple of weeks later, people are like, no, the loops are bad idea. And

SPEAKER_00

then like, we, we kind of like, you shouldn't like, I think like those things are like signals that you should like read and understand. But like, you also need to know that like a lot of this stuff is not tested. And like a lot of times that people also testing these things are not testing it in some like large organizational context that where things actually matter, like if they work or not. And so I think there's that, like, we haven't tested all these things. So we can like make these

SPEAKER_02

predictions of like how things are exactly going to change. I think on the, on the SaaS narrative, I do think like the, it's probably like directionally correct that you switch SaaS companies, you probably have to like, as an investor, you kind of have to, there's more uncertainty of the future cash flows that like, because if the landscape is changing, you can't expect that everything will stay the same. But I think like the, the narrative is kind of simplistic, like, oh, people will wipe coat their own CRM tools. And I don't think that's exactly going to happen. But I think like what might, might happen is like, there's new companies that come out, or I think

SPEAKER_02

like a lot of the public companies are not the most, like, I don't know, flexible or like the most robust solutions out there. They are the big solutions that the big companies use. And there's a certain kind of like inertia in there. So like, I would say that, that yeah, I think like the public companies probably get hit the hardest here, because they have like, their modes are kind of like disappearing in a way. I think even for us, like we consider now it's like, we need to live in this day one world again, where, like, we can't rely on our previous decisions anymore. Like we have to like,

SPEAKER_02

look at these problems, like, in a fresh way that, like, what happens when when these things change? What happens when the agent come into this product development process? What are the new problems that come out of it? And like, how do we help that? So like, we shouldn't be tied into the past experience, like the past product we have, but like, see like what the future product should be. And I think like, this is harder for large companies and like companies that have existed for like decades. So I don't think it's like an easy task. And I like, I think their growth companies or startups can can do it a lot better. How big is the team now?

SPEAKER_02

About 120 total, I think I would say like, about half of them, like 60 people are on the product team. And what was that? What has that transition been like? I assume that over the last couple years, there have been a lot of divided opinions on is AI coding really a thing? Is it just glorified autocomplete? Is it going to eliminate programming as a job? And then how have you, how has that change cycle been to actually go change your workflow, figure out what the new programming workflow is like? How did you get the team in shape to do that? And what did you learn in that process? Yeah, I think like there was definitely a time in a company to like, we had to

SPEAKER_02

encourage people to use these tools more. I think there's always that there can be like habits where you always like done stuff this way. So like you, you're kind of like less and less like interested in like trying new tools. But I think like now, let's say like the, probably all of the engineering and sometimes our design and VMs also like are now using agent coding or coding tools. We don't like track any kind of specific, to me, it's like I talk about this sometimes on Twitter, like people now it's like the, the biggest like vanity metric is like how much of your code is agent like written or how many BRs are you merging? And I think like that's like,

SPEAKER_02

not the right metric. It's like, it's, it's, it's measures. Yeah. Like output, but like, what does that output do? Like, it doesn't actually generate value. Is it like improving the product? Like you need to have like, if you're measuring these kind of metrics, you need some kind of counterbalance, like what is actually the quality of this work and like, is it actually meaningful? And I think like, that's like, also, I think what's playing out in the market is like, we have large companies that are token sellers. And then like, when, when, like you have a lot of incentives, like your business model is

SPEAKER_02

like to spend more tokens and like things like our revenue will be higher and like our market share will be higher. So I think there's a lot of incentives saying people like you should just spend more tokens and not saying like, well, you think about things and like spend it well. So I think there's that again, like I think people are, let me be looking at it too, like simplistically or like kind of like, oh, there's a good thing. If we just like, like spend more tokens, things will be better. But I don't think that's ever been the case. And in building products like yeah, there's some, some value and

SPEAKER_02

speed and like making changes. But then like, you should also understand any change or addition you make, like it can also have a negative impact. So it's like, it's not always like activity is always positive, like sometimes it can be negative too. What do you think is a more nuanced metric for, you know, if you're judging how well, how in this AI world are we? How well are we doing our job of figuring out these new workflows and adapting to them and using them in our own work? If, you know, tokens or number of PRs submitted or percentage of agent generated code is, are not necessarily the

SPEAKER_02

right metrics, maybe even in isolation, they're not the right metrics. What, what do you look at? Or how do you think about it? I mean, I think it's still the classic metrics of like profits or revenue or user like love or some of these things are like what you should be aiming for. Those seem like lagging indicators, right? Yeah, they are. But yeah, there isn't like, oh, I think like you should still measure like some of these things like token usage per person or like by different teams or something. But you shouldn't take it as a like to the extreme of like, this is the only metric that matters now. You should

SPEAKER_02

be like, use it as a signal that like, are we doing something? And then think like, well, is our product actually improving? Like, do we have any indication of this product is actually improving? Like, do we get comments on the new features? Are the bug, is there less bugs? And like, I think bugs is actually like a measurable metric. If you, if you run like honest bug tracking progress process where you actually track bugs. And then I think like now I almost feel like with the agent agents and AI, it's almost like, why do you even have bugs in your product? Like you should be

SPEAKER_00

like, there's no excuse for it anymore. And like internally we have the zero bugs policy, which is like, we have a linear team triage and like any bugs go there. Then there's a one week SLA that every bug needs to be fixed. And then now I think with the coding agents, the coding agents actually can do the first pass on it. And then like, once it's done the fix, it will kind of like attack the engineer on it. And the engineer maybe doesn't like it, or that there's some like changes that they want to make. They can do it also now inside linear and they can review the code in linear. So there's this like very good workflow

SPEAKER_00

for now, but I think like it's, it still starts from the fact that like, do we care if we are product is buggy or not? And like, we have made the choice. Like we think it's bugs are like, kind of like bad things or mistakes. And like, we should fix them as, as quickly as we can. And that's like a priority to everyone. So I think it's still like, it's still a choice if you like care about the quality of the output or you are just wanting like more of the output. What are the ways that these tools have

SPEAKER_02

changed your product building workflow, both, both personally as, and as an org and what are the most effective ones that might be surprising? Hmm. Yeah. I think like on, on the product side, I think it's definitely a lot better. Like I think it's, I have with, with linear now, I have this like skill where it's like, Hey, I fed some of our internal docs and, um, blog posts about like how we think about product development and made this like a linear way skill. And then like it, it writes soon this, I tell it like, okay, like look at this, like help me understand this like feature requests.

SPEAKER_02

Like we have this, we collect this feature requests and inside linear. And then like, for example, there's a request, like multiple assignees per issue. It's like requested by lots of people, like hundreds of people. And so like, I'm kind of like tell it to go synthesize, like help me understand, like, what are the different reasons people want it? Like, I don't want, so it's kind of starts with like explaining the problem, like trying to understand the core problem, which is usually what I want to know. It's like, so this helps me like, when I, when I see a new request, I might go

SPEAKER_02

into linear and say like, Oh, like, do we have this kind of request already? And then help me understand it. And then like, it helps me kind of like, give an understanding, like, which then like helps me, like, potentially, like, should we actually tackle this now? Or is this something we could do later? Or maybe never. So there's that, like, before we start building anything, it's like, it's helping me kind of like understand the problem. And like, in a very quick way, like, I don't have to like, go ask around or like, find people to do it for me. On the design front, I actually don't personally use

SPEAKER_02

it much. I actually like the manual design process, like I still have Figma open. And then when I have a problem or idea, I just draw it in there. And to me, it's like, yeah, I'm often like my work is often more like that kind of like exploring things. So I actually don't think the speed really helps there. Like I actually like the slowness of the manual thing, like you draw things manually. Every time you draw something, you have to kind of like, check on yourself. It's like, why am I doing like, why am I drawing it this way? Or like, should I draw it different way? But then like the broader team,

SPEAKER_02

when the design team, when they work on problems, I think now they are building a lot more like prototypes. And we have this quite robust, like, build system. So you can, you can actually build it into that, like, you can make a VR, and then it will run the build, and you get the preview link to the build. And then you can use it live in the, in the product. So it helps the testing it, or the prototyping stage of it. But I still tell the designers, so I kind of explore more freely in Figma first, or wherever, and like, try to think about how do you approach the problem? Not just like, let's just jump into doing it. Like there's projects like that too, where it's very

SPEAKER_02

clear what needs to be done. But then if it's like a bigger project, I think they should still spend that time. And then yeah, like engineering side is probably similar to a lot of other ones that were, we can kind of like fix problems a lot faster, once we identify them, and like, decide to do it. We use the Slack a lot. And like with our Slack agent, like, we have a discussion, and then we eventually decide like, yeah, we should do this. And then we just tackle in there and they're saying like, Hey, can you create the issues out of this conversation, and then we'll do it. And so it helps

SPEAKER_02

us like track, come back to it later, and like actually make it actionable right away, versus like, oh, we need to have a meeting, and then we start a project, and then we start like assigning people. So I think there's like, I think it's kind of like, I would say like, kind of like the pattern in all of those things is like, it's shortening the some kind of loop there, and like making it faster, like you can do the thing right away versus like waiting, waiting for like, I don't know, next week or some other time to do it. Like, it's very little effort to do it right away.

SPEAKER_00

Which is interestingly, sometimes it seems like you're the exact opposite of your preferred outlook. You know, actually, we shouldn't do things faster. Actually, we should take things a little bit slower. How does having tools that make you go much faster interact with that outlook? Yeah, and I think it's a good point. I think it's, I think it's more like, I think like, we shouldn't go fast and like deciding things or, or just like kind of like speed running the decisions or like, not even doing a decisions. Like, I think there's this, some people do it now where they just like,

SPEAKER_00

have an idea, then they build it. And now we're like, now we're all looking at this idea that no one really know why it exists. And like, should we even do it? And it's like, it's a, every new prototype or idea can kind of like seem useful. But then like, you now like, don't have like a good way of like, framing it's like, how useful this is versus other things? Like, should we spend the time actually like,

SPEAKER_02

now committing on this idea? Because we already have like, kind of decided on this, some of the other ideas. So I think there's this like danger of like, you don't have some kind of like, decision

SPEAKER_00

making way, we don't have like a lot of processes in linear, but it's more like, we want to commit on

SPEAKER_02

this. Like once we commit on the thing or the fix or the project, then I want it to improve fast. Like I want the loop will be fast to actually work on the problem. But I don't want the problem finding to be fast. Like you should take the time to find the right problem and like the right approach for the problem. And then once you decide that, then you can go faster on it. Here's a simple test for whether your AI is actually ready for production. Would you stake a business decision on what it just told you? If the answer is not yet, you're not alone. The gap is in capability because AI can do a lot. It's really about trust. You can't verify the output of the AI. You can't

SPEAKER_02

trace this reasoning and nobody with real domain expertise has touched it. Dialect is a new system from scale AI that captures how enterprises make decisions and closes that gap. It puts your actual experts in the loop, AKA the people with years of institutional knowledge and encodes their judgment into your AI systems. Every correction, every override comes with full context. It's actually really interesting. So the next time your AI makes a call, there's an expert's reasoning behind it. That's how you go from a cool AI demo to an AI system you can trust. Visit scl.ai slash dialect. That's scl.ai

SPEAKER_02

dialect to learn more. While I'm doing that, back to the episode. One thing that what you're saying makes me feel is I totally get that approach. And also for myself as a product builder, I often don't know what I'm doing until I do it. And I can't think it through until I've done like five different things that I can't explain. And then I'm like, okay, here's the thing. And I understand it. Is what you're saying different from that? Or is it the same, just like said differently? Maybe it's different, but I can see that workflow. I feel like that workflow is kind of like, kind of like understanding, like you're trying to

SPEAKER_02

understand like what you're doing. And yeah, it's building, it's like making things as understanding. Yeah. And I think that's fine. I think the problem there just becomes like sometimes it's like you kind of like don't know. Are you, I think like conceptual work sometimes like in design, I consider this like a conceptual work where it's like the output of this is a concept. Like it's not like, like we just shouldn't deliver this necessarily, but this is like, like I made this, like I went through this process of understanding this problem and like, I have a concept for it or

SPEAKER_02

like I have. What's an example, because I would assume that the output of a design process would be Figma, you know, a Figma that you could export. So what's an example of a concept that comes out of a design process? Well, I think like in the, in the past, like in a large companies, I've used the concept term to like, not to scare people. So usually it's like, like rethinking some area completely. And that's like a concept, like, it's not like, it's like a concept car. So it's like this car won't go into production, but here's some ideas that could influence the next car. So it's like, you're trying to like,

SPEAKER_02

like sometimes people, I don't know, it's, it, this is like partly like a large company thing, but I think it can happen in small companies too, is that once you see like something like very different, your like fears might start coming up. Like, well, if we change this, like what else is going to happen? Like what is going to happen? What's going to break? But the point is like, not right now to decide that, like we just decide, like, does this concept, like this new idea have merit? And like, can we like, do we, do we think it's like important enough for something to like, take it further and then deal with

SPEAKER_02

like the problems later? So it's kind of like, you're kind of like trying to divide like the decision, like what, which decisions you're making now. And like, I've used it. Yeah. Like in, in our company and other companies, I just like completely rework a surface and say like, Hey, I think the project should look like this, like, which is completely different from what it's currently is. And then people like, Oh, that's actually interesting. Or they're like, well, it won't work for this and that line. And I'm like, okay, that's fine. And it's like, it's a way to like, and then it's,

SPEAKER_00

maybe like a figment design or a prototype. So it's just like, I think there's like, even with all this tooling, like the output shouldn't always be like, we ship something like it's sometimes the output can be something internal that like, Hey, we just, now we have a, like a better understanding

SPEAKER_02

of this problem. We can like tackle it better. And like, we can actually make it into a shipable thing. But like, we first try to like, think about it before doing it. Right. And, and to you thinking about it can include building stuff. It's just the reason you're building stuff is not to ship it the next day. It's to understand it better, but thinking can be designing, it can be writing, it can be, you know, talking about it, that kind of stuff. Yeah. And, and, and something like I did have to share with the company recently was that I, like, we always care about the quality bar a lot, but I think like, and like, kind of like this thinking

SPEAKER_02

process of like, are we doing the right thing is kind of like what we're trying to like, like decide sometimes now with AI, it's actually like hard to tell. Like it's, it's kind of like, if the tooling changes all the time, like people like the, the LLMs are not deterministic anyway, like, you know, as no, like, like how useful this thing could be. And then there's a moment you just have to decide, like, yeah, I think we should, obviously we can try this internally, but we also need to try it with customers and you kind of like put it into some kind of beta or something that, so I think like there's definitely nuance to this right now that there are situations where it's

SPEAKER_02

just like, and it's always with product building, there's a limit how much you can like think about it inside your company until you need to actually put it somewhere to someone else to use. And then you learn from that use case. But again, like it's, it's more like every stage, you kind of have like some kind of goal in mind. Like now we've, we put it to beta, like the, the, the goal should be like, understand the workflows and how people use it and how they want it to be better, not to like something else, like not to try to ship it as fast as we can or something like we, we should be honest about like, what is the actual goal for, for this stage?

SPEAKER_02

So we've talked about how AI has changed your internal workflow. I'm also curious how it has changed your product strategy and how you think about building products, not like the actual work of building products, but what kind of product to build and what, for example, should you let AI agents connect into your product, which I know you've done versus build your own AI, like into the core feature? Should you have both? What should they be able to do? Like, yeah, how does it affect your, your product strategy and your vision for what a good product is? Yeah. I mean, I would say like, we are now adding agent, like a linear agent that can like,

SPEAKER_02

has context of their work and the context of the organization and the products you build, that you can use in different ways. And they're like the PM workflows. You can also like, as a designer, use it the way to like, understand the problems. And then we will also do like a coding agent where you can actually like, start like writing code with the agent. Interesting. And it will, you can see the diffs online. So it's kind of like a cloud conductor and environment where you can kind of like, see the changes and you can kind of, you can guide it. And we think like, the strategy has definitely like, changed. And we are just trying

SPEAKER_02

to like, like understand, like, what are the problems that of today? We think like, one of the things is like, what is changing is that I think historically people thought like issue tracking is this kind of like, like, it's like a ticketing system for the kitchen, like, like, but engineering. So it's like, order comes in, like someone orders fish. So now that fish goes into the kitchen, there's a ticket, like make fish. And that's like, kind of like, people think about issue tracking. And like, like, we kind of never thought about it that way. Like, for us, like, linear is more like the backbone,

SPEAKER_02

we rely on like collecting signals and collecting problems or collecting decisions, like we should do this thing. So I think like, I think there's definitely like shift, we have to like, teach people, like, these products, it's really meant to like, improve your team's workflow, not to be this kind of like a weird ticketing system for you, like, different parts of your organization. And that's kind of like, probably like going away, like with the agent. So like, you don't need that anymore, like the agent can do those tickets. And like, they can also complete them. But like, we think like, there's still

SPEAKER_02

value of like, like collecting that context, and like that, they make the shaping that works something actionable and providing agents like, good context from the from the environment. But the one lesson we learned with the with with the agents is that it's, it's, it's tough when we are not ourselves in control of it. Like, it's, it's like, we do want to like, support all companies and all agents as much as we can. But then if we have ideas for it, we can't do it like it's, it's on them to do it. So so now, like, one of the reasons we are doing this coding agent is like, we actually think we see this like a lot more

SPEAKER_02

smoother end to end workflow where you start your, you don't have to do everything, but you start some of your tasks in linear, it's like, you can ask the agent like, hey, does this thing exist already? Or if not, make an issue, make like a work stream out of it, and then like start working on it, and then start like writing the code. And then you can like, see the diffs coming in, you can like review it, and you can like merge it, or like, you can see the prototypes. So it's just like, trying to like, you, one of the problems I see, like, when I use this, like, like, Claude, or

SPEAKER_02

chatTDB, or some of these tools, or codecs, is that like, I have to really explicitly tell the agent, like, the tool always like, what, like, what context to bring. And then I think the value with linear is like, the context lives there. And then if we kind of inject it like smartly, part of the work stream, it's like, much more like, like natural, or we can design the flow that like, makes sense. And we don't like, span the span, the context windows or something. And I think we see this feature is like, you probably have this linear, it's kind of like the multiplayer or the organizational

SPEAKER_02

context of what's happening in the product, and what is potential future state of it, you might still run local agents, but there's situations where, like, you should just automate some of the like, bug fixes, or you should automate that small task and like, just do it in linear, and then like, kind of like, let it run in the background, while in a sandbox while you like, run your own work and in your own computer or somewhere. That's really interesting. I think from a product strategy perspective, I'm really curious about the decision to integrate your own agents. Because I'm, before we did this

SPEAKER_02

interview, I didn't know about the linear agent. And I was sort of sitting here thinking, wow, this is the perfect business for this era, because it's still SaaS. There's no AI token costs, but it is the place where you control all of the AI. So all the other companies have to deal with all the other coding agents, and whatever, have to deal with all the token costs, OpenAI, and Anthropic, and whatever. But you're the one who has this sort of sticky interface, because it's where everyone is kicking things off from, and where they're recording all the all the information. But you don't have to pay for any of

SPEAKER_02

the actual tokens. And it sounds like you're adding it, adding a layer where you will have to pay for the tokens. And you, you may prefer that. And I think the reason you're saying is because a tighter

SPEAKER_00

integration between the two means you can do more interesting, more powerful things. How did you think about that from a business perspective, you know, changing your margin profile that much? I assume, you know, I don't know, I don't know, I don't know off the top of my head how much linear costs a month. But I assume there's a lot of interesting discussion there about how adding in token costs change the business model. Yeah, I mean, like, honestly, I think it's something like we'll have to see,

SPEAKER_02

like, in the future more, we definitely thought about it and like have some like, calculations or thinking on it, I think on the coding agents, like we do have to offer like usage based billing, because it's gonna get very expensive. On the basic like linear agent functionality that's like, answers questions for you. It's like that's, that should be more like included into the into the system. And like, we will have a lot more like, we will have to see like how much the usage actually is. But like in linear still is going to be like this, like for fairly focused platform for like, certain kind of things like you shouldn't be running random things here,

SPEAKER_02

like, I think like, you should be still like, pretty, like, clear what you should be doing inside linear and like, what kind of like workflows are you running there, like workloads. So we're not trying to like build this like, very generic, like agent platform, it's, it's, it's just like, a more like the product context or the product memory platform where you can integrate those agents, and you can use linear agents from other tools too. Or you can bring other tools into linear. So it's, it's just like a way to like work around your product. And it's kind of like an API into the product

SPEAKER_02

thinking versus like, using like, more of the like, normal tools where it's like, you always have to like, tell it to like, go fetch this thing, go find this thing, because it doesn't have any understanding, like, what do you generally do? Or like, what what kind of like, context that might be existing already? Can we see a demo? I'd love to see it. Yeah. Is the screen sharing? Okay. Yes. All right. Yeah. So what we have coming up, like, this is actually my like, real linear instance. And like, what do we have come up is like, we do have like, now, if you do a new tab inside linear, that

SPEAKER_02

will be like the classic box of like, what do you want to do? There's also like this other interface where you can like, if you are inside some context, like a project or something, you can kind of like, do the work there. But like, for example, the one, we will have skills and the skills, we will have guidance, like organizational guidance and a personal guidance, and you can have skill, like personal skills or organizational skills. So for example, like, what I was mentioning earlier is that sometimes I want to understand problems. So, so I want to like, understand this problem of like, multiple assignees.

SPEAKER_02

So I made the skill, which is like, essentially, like, I fed some materials from our blog, and it's like,

SPEAKER_00

act like a linear product teammate. And, and then it has this format of like, it starts with the underlying need. And it has this like, way it goes through the problem. And I so I made this to I kind of like, help my workflow, like, something just quickly and trying to understand sometimes this feature request. So I can like to do it like, well, let's do the multiple workspaces. So, so we have this like, collection of stuff about like multiple workplaces. And then it can kind of like, go through there, there's like, probably like many different requests. And like, it will try to start

SPEAKER_00

thinking through it, they will look into the customer activities, it will look through the different things. What model is it under the hood? I did, I think we'll eventually have multiple models. But now we use Claude called for this. Sonnet or Opus? I don't actually know.

SPEAKER_00

So it starts going through, it's like, okay, like, there's a, it's, it's, there's a real need, but it's like, more complicated that it sounds. So, so companies maybe want this like multiple workspaces for different reasons. And I think like, my understanding generally is that they want like, it one place to have this like billing and governance, but then they might have multiple different divisions in the company. And so it's, it's not, they would want to like divide that, the team, that, that workspace more, but the, they might still have some kind of like overarching control.

SPEAKER_00

So it goes through the kind of like trying to like explain, like, what is, what is missing and what is good about it. It also like makes this like few recommendations of the product direction. So like, do this or that on that. So it's like, it helps to like, kind of like, make this something that is like, quite like, not like, I don't know, complicated into some kind of like actionable thing. And like, I can, we can talk about this as a team or something. But similarly, like, more like a micro example is that like, if, if there's like, I want to make a new theme, like, new dark theme. What's a theme? Themes are just like in our app, like, so you can have like,

SPEAKER_00

Oh, okay, got it. Yeah. Yeah. Like the way it looks. Yeah. Yeah. So maybe I want to create a new version of like a dark theme, like make it just black.

SPEAKER_00

So I can now task like a coding agent on it. And it should start like looking into, it can look into the code base and they can try to understand the code base, obviously. And then at first it's like, it's turning it into an issue and then like delegating into, into an issue. So, so I created this issue, it's in progress, it's still located to linear, and then now like linear starts working on it. There's a, it's spinning up the, um, the sandbox for it. And like, I think the pro like kind of the, one of the benefits on issue is like, now people know I'm like doing this. So the team knows I'm doing this. And I can say like,

SPEAKER_02

Hey, no, I'm like, FYI, I'm like, I'm doing this. So like, he can also come here to look at this, like, what is happening? Like, and then the thing is like, this agent session is visible to everyone. So it's visible to me and to him. So I can call like, once it's, it will take a while, but once it's like, does it like, we can both jump into this chat and tweak it together if we want to,

SPEAKER_00

or just like kind of see what happened here. So it's like similar to like what you do on your

SPEAKER_02

computer, but then now it's like kind of like happening in a shared context. And there's more like a, and understanding, like, where did this come from? Okay. It came from me. If this could come from a customer like discussion or a shared context is interesting. Like, so, so two people can be in the same chat. Yeah. So I know that's really cool. Yeah. I don't have none to ready to demo this, but like, we did have this like instance, kind of like accidentally, we noticed this, like, this is actually useful sometimes is that it, Anon was our head of product and like Connor, who is our head of design, they both like, we're working on some tweaks on the inbox. So they,

SPEAKER_02

they could kind of go back and forth, like a PM and a designer could go back and forth. It's like, no, it's like, it's not quite right. Like, let's fix this thing. And then they could both like, see the kind of like the, the, the preview link. Let's see if I have something here. Okay. So

SPEAKER_00

there's like one, like my previous pull request. So we will have like pull request here. You can kind of see the activity, but you can also see the code. So you, you, you see the code diffs. And then if you want to like comment on it, or you want to like work on this code with the agents, like, no, this is not, not right. Like, and then I can like work on it and similar workflow works for like

SPEAKER_02

code reviews where engineer might come in and say like, this is not right. They could just task the agent to like fix it versus like saying, like telling the other engineer to fix it. So I think it's like kind of collapses the cooperation loop a lot more, um, and allows like multiple people use the agents to work on one thing. Um, and then like here, this is only like a backend change. So there's no like client review I can do, but if I had, if this would be a client facing thing, I could kind of like open the preview link and then like actually see like, how does it look live? That's interesting.

SPEAKER_02

But yeah, those are a few things we're, we're like adding. I'm curious about this. One interesting thing about this is it seems to increase the surface area of the product a lot. It's about a lot of different things that already exists to some degree somewhere else. And obviously there are things that you can do differently. So you can have multiple people in a chat. You can, um, it's, it's more plugged into linear more generally, but, um, you, you kind of have to recreate a lot of stuff that's already being built by a lot of other companies. So how do you think about that and the trade-offs of that and doing that well, especially entering something like AI coding,

SPEAKER_02

where all the big companies are just like going as hard and as fast as they can to build AI coding agents? Yeah, I think there's definitely the question we keep, need to keep asking ourselves like, what is our advantage or like unique advantage here? And I think like we, I think like, honestly, like, I don't think we will solve all the different coding needs, but like, we don't necessarily also have to, like, I think it's, it's what we see the value is, is kind of like sitting upstream where that work is coming from. There's like really like good leverage there that we can offer to companies where

SPEAKER_02

it's like work comes in or bugs come in, they automatically get spawned into agents, like, like even delegated to the agents. Like engineers never even see them or like, if they see them, they see them, like once there's like a fix already being built. And so it doesn't like maybe work for all kinds of situations. It's not like, it's not the agents like you go to like, hey, build me a new product. Like, we don't think that's like where we should be like working in. It's more like you have a large company, you have a lot of things requested from you, a lot of bugs filed in, like, how do we like

SPEAKER_02

reduce that workflow for you like automatically? And then yeah, you can use the other coding agents to do other kinds of work. But this is like where we kind of focus on. That's really interesting. But then like, yeah, generally, we've been thinking about the problems, like we don't want to be a kitchen sink product, like we do everything for everyone. And like, sometimes companies end up in the state because you have the enterprise buyers, and you have the checklist, and then like, you just need to get to check mark into the right spot on the checklist. And it we don't think it's that

SPEAKER_02

those things like don't create like a good product experience. So the way we always thought about it, and build the products, it's like we try to feel like, what is like a natural next step in this workflow. So if we go from an issue, like it's like, yeah, someone likes a natural next step is like, someone needs to fix this. And so like, how do we help people to fix it faster? So one option is like, we do this cloud agents, and then you take and fix it. But now the cloud agents does this stuff, like, how do you know, it's like, good? So then you need to see the code, like you need to see the diffs,

SPEAKER_02

and like, you need to run the builds and like, whatever. So it's like, we are more always focused on

SPEAKER_00

the workflow. And how do we like, improve it? Like, how do we make the make the out kind of like help companies to output better and faster, versus trying to like, own every surface? So we don't have to own like every piece of the surfaces. But like, we are kind of like trying to find this optimized workflow for people to do certain kind of like product things. So we're almost out of time. My last question for you is, if you had to project how product development will change over the next five years, let's say, what will be what will be different? And also what will be the same?

SPEAKER_00

I think that the one difference, I think there's going to be more of this like self driving aspects

SPEAKER_02

of like, you can set up some kind of rules or guidance. And we even like are building something like around like a project memory or like, like, so like, you could have like, like, a common workflow, what we do is like, we have projects going on, it's like a project is often like a feature, a part of the interface, or part of the part of the product. And then like, we have a lot of like, feedback and requests and things coming in. I think there's opportunities like turn that into like, more like that, the product or that feature is, it's kind of like an agent itself. And it kind of

SPEAKER_02

like tries to make decisions based on the input it creates. And then it can still have, like, maybe ask a certain amount of input, but it could run automatically. It's like, hey, like, these kind of I seeing these patterns, and these patterns pointing to this solution. And the solution seems to be like, potentially something that works for people. And I built a made up build, I send it to some customers, and they say it's good, the feedback is good. So it's kind of like, it gives you like, it does things on its own, based on some kind of context, and like a rule based system, or like some kind of guidance. And then I do think like, the thing I'm still like, I think

SPEAKER_02

people should still think even in this world where agents do some of the thinking and like does run automatically to some degree, I do think like, it makes people have to be like, a lot more explicit, like, what do they want? Or like, how do we, what is worth doing? And like, what are the areas we should be doing? And I think it's, so there, I think like a lot of this, like still like, humans having meetings, or discussions, or writing issues, or writing documents, I think it's like reading documents, like that, there's still gonna be like a place where humans need to like understand this stuff,

SPEAKER_02

to like, you can't just outsource the thinking purely to the AI agents. But like, you should like, the more you can clarify your own thinking and the strategy or something, the better it's for your team, but also it's the better it is for the agents too. Because then like, you can codify some of those

SPEAKER_00

like, strategies or thinking into actual like, these autonomous things. So I think like, I personally don't see the future in a way that we are replacing humans. And I don't quite believe in it. Maybe I don't want to believe in it. But I think it's, I think things will change like that, the roles will change. Maybe there's some like, movement around exactly what does engineering do? How many engineers we will need? And like, what is the job in the future? But I still don't see like, how the agents like, how the AI actually like, does all the thinking, and like, kind of like,

SPEAKER_00

the choices or decisions, I think product building is still kind of like a craft or an art, you kind of, a lot of times like, we, we, we talk about intuition, like, we just decide things based on what we understand, how we understand the problem, we hardly use any data as part of decision making.

SPEAKER_02

Sometimes we use it to look at something, but it's more like a signal. So I never personally believed in this like, AP testing and data driven product development, which I think could work well for agents. But I think it doesn't work for all kinds of products. And I also think like, the best products are not necessarily like, being built that way, like, you still need the human kind of touch of like, what is interesting, or like, what, what would make this good? I love it. Kari, thanks so much for joining. Kari, thanks for having me. This was great.

SPEAKER_02

Oh, my gosh, folks, you absolutely positively have to smash that like button and subscribe to AI and I. Why? Because this show is the epitome of awesomeness. It's like finding a treasure chest in your backyard. But instead of gold, it's filled with pure, unadulterated knowledge bombs about chat GPT. Every episode is a roller coaster of emotions, insights and laughter that will leave you on the edge of your seat, craving for more. It's not just a show. It's a journey into the future with Dan Shipper as the captain of the spaceship. So do yourself a favor, hit like, smash subscribe and strap in for the ride of your life.

SPEAKER_02

And now, without any further ado, let me just say, Dan, I'm absolutely hopelessly in love with you.