 Hey everyone, this is Carlos. I am the founder and CEO at Product School and today I'm here with my friend named Shackleton, who is the Chief Product Officer at CODA. Welcome back, Lane. Thanks for having me. Great to be here. It's good to have you on the show again. I was just looking back at our previous interview a few years ago and it's incredible to see how much growth your company has had. Maybe we can start from there. I see you've been a CPO at CODA for seven years. Here's to know how was the product team when you joined and how it has evolved over time? Yeah, definitely. Let's see. When I started at CODA, there was just a couple of us doing product work and I think at the time it went from spending nine years at Google and YouTube where we had a full calendar and 500 emails a day to basically an empty calendar and getting no emails and just being at a whiteboard with Shashir, Matt, and Alex and some of the other folks. So it was a totally different environment. And then in terms of how the product team has evolved, we kept it fairly small in those first years for the first two or three years and then as we had a little bit more market fit as the shape of the product started to become more clear, it was probably time to scale up the team a little bit more. And so then we scaled the team over the course of the next five or so years and now we're about 30 people on the product and design team about 15 p.m. to 15 designers. And in a way, and I know this is not always possible for product people, but you are also the user of your own product. So curious to know how that's impacted the way you think about product. You are using CODA internally, so what are some of the specific use cases that your team is using to also be CODA for other users? Yeah, for sure. I mean, I think it's interesting when you're the user of your own product because you kind of have to hold two users or two rooms in your head, right? You have to hold the room of I'm an opinionated product person, I'm using this thing all day every day. I'm frustrated by this friction. But then you also have to realize that in many ways you are also not the customer. Like you're not the end customer that is being served, that is paying, etc. And so I think you also have to be quite empathetic and also quite curious about what's happening outside your company because it's very easy for a lot of internal feedback to overwhelm a product team when the internal users of the product are sort of in it all day every day and having strong opinions on it. We use CODA to run everything, so everything from planning and OKRs to write ups and decisions to retrospectives to how we communicate with our customers. It's really sort of infused in every specific process and ritual that we have. And I would say generally this is a company that is obsessed with rituals and loves sort of being students of how product is built. End up in a fortunate position of getting a front row seat to hundreds of different product teams, thousands of teams across the world. And so I think what we're trying to do is really learn from the best of those teams and try to apply that to our own process and then also share a little bit of it with the world. And you can see that in the CODA gallery, there's sort of full of insightful ways to do product there. And maybe we can talk about some of those ways to do product because I remember when I started using the product it was I was saying I came from Google Sheets, Google Docs. I mean you, a lot of your members came from that world as well. I remember she was here on the podcast saying like YouTube used to run on Google Docs. So when you move into this new generation collaborative space where you can do a lot of those different use cases, but within the same platform, sometimes it's just not that obvious for the user who's used to a different type of set of tools. So I've seen how templates and artifacts can sometimes help people get ahead to start. So talk to me a little bit more about how you think about that type of welcoming of the new user. How can you help them get to value as soon as possible so they can continue exploring other parts of your product? Yeah, I mean I think when you come into the product, the feeling that we want you to have is that it's a simple starting point. And so there's been a very intentional choice over the course of CODA's history to keep that blinking cursor as like the starting point of the product. So that you can come in and say I can write down an idea, I can write a brief, I can basically share my ideas in the form of a document like I'm used to. So anchoring on the familiar I think is one core component of it. And that's been tested multiple times in our history. And then I think the other kind of core component of it is getting you, like you said, getting you to value basically like knowing that you're not coming in necessarily to just learn some new thing for no purpose, you actually have a job to do. And oftentimes it's I've got to get a decision, I've got to run a planning process, I need to organize my team. My team is sort of in chaos or spread across multiple tools. I think that's probably one of the most common things that we hear these days is my team is spread across five, six, seven different tools. And so the conversation in Slack is where's the link to this and where's the link to that. And like you said, when you're in a world of docs and sheets, those things sort of tend to like my toast, there's some mitosis there like this sort of spread out and everything is sort of in a different spot. And so the thing that I hear back from customers very often is Koda's kind of become a single source of truth because I can have a write up, a brief right next to my tasks, right next to the sort of decision making process that we've templatized. And in that way, we start with again, the familiar, the brief or some of these simpler meeting notes or something like that that you're used to with documents. But then we show you how this thing can evolve with your team, right? And that's sort of the important bit, like you shouldn't conform to how other teams think you should build product. You should treat this just like your rituals and process just like it is with the same intention that you treat your product. And so I think we've seen tons and tons of clever rituals to do that over the course of our history. This is a common path that I've seen in a lot of companies that try to eventually replace the spreadsheet or a more common product. They start with a specific use case or feature that you can hung on to and then eventually you start spending the use cases and hopefully become the platform. But in order to truly become a platform in this time when there's not just one tool that everybody uses, right? Like we are all using like messaging tools, live streaming tools and a thousand others, there has to be some sort of integration to truly become a platform for the user. And then eventually in order to be stickier, you also want to open up that platform so other developers can build applications on top of it. So okay, I get the use case part how you can welcome people into your product and platform. But tell me a little bit more about how you were able to truly become a no-brainer for like the average stack that a tech professional or product professional has to use and then how you thought beyond that to truly start opening that up for external apps. Yeah, I think that's a great point. Like this promise of a single application that can do it all is it's a tough promise to deliver on. And so like you said, you have to integrate well, play well with a broader ecosystem of tools. And early in Coda's history, I think we had that realization. And so we started building initially something that was called PACS and PACS are basically our integration framework. So if you think about, you know, the way most integrations happen between two tools, it's like a point-to-point integration like JIRA integrates with Asana or something like that. And oftentimes you get kind of 80% of the use case that you need. And then the last 20% you can't quite get to because of the way that that integration was constructed. Whereas, you know, the kind of first principle behind PACS is you should be able to use all of these tools in their entirety through our set of building blocks. So if you have a bunch of JIRA tasks, you can sink down all of those JIRA tasks into a table and start using them, manipulating them in Coda, right next to your write up, your brief, et cetera, so that you can sort of bring context and tasks together in that world. That's one kind of scenario example. More broadly though, I think, you know, we've leaned, we've continued to lean into this. And so you alluded to the fact that people can build their own. So about two years ago, we enabled anyone to build a PAC. And so what that did was it took us from a world where we had to build all the PACS and we could only build so many so fast to a world where anyone could build a PAC. And we went from basically 50 PACS to over 600. And so now when you come into Coda and you want to integrate with another tool, you are very likely to find it there. So that's sort of like a little bit of the arc of PACS and how we've deeply integrated with all these other services from the very beginning. More recently, we actually launched something called page embeds. And the basic idea there is, you know, oftentimes you have a legal team that needs to work out of Google Docs for litigation reasons, or you have someone who's really stuck on having a Google Slide presentation for a customer. But you still want those things to live in the same place. And so we basically enabled you to take any of these tools and have them be a full page embed on Coda. So you can, you know, basically have all your written materials in Coda. You can have tasks, you can have all these things and tables. But then you can also add a Figma prototype, a Miro board, a Google Doc, sort of any of these. And so I think we're getting pretty close to a world where customers will repeat back to us this idea that, you know, this really is the one destination for my team. It's really is the one link that I can send around. And I can at least have some confidence that it's all there, right? Like it's been sort of pulled in from the different places in a meaningful way. The way I call this is kind of going from, you know, creator to being a curator. It makes sense, especially at the beginning, to create those best practices so people can understand what a good template looks like or what a good pack looks like. And eventually, in order to truly dominate a market, get an option, you have to allow others to be part of their party and curate that experience a little better. But there's a different type of challenge because now you lose control of your own platform. So from a product perspective, as you try to collaborate with external product teams, like what is your relationship with that? Like how much guardrails do you provide versus flexibility? Yeah, I think, you know, I think the value, the core, one of the core value props of Coda is its flexibility, right? It's that you can basically build anything. But that sort of comes with the other side of the coin, which is like, what should we build? How should we make it? And so oftentimes, the way that we work with other product teams is very consultative. It is, what are you trying to really accomplish? And how do we get down to the core of that? So, you know, if I'm talking to another product leader, it may be, we want to fix decision making, because like our decision making is kind of chaotic, and people are complaining that it's low. Okay, great. What does that actually look like? Let's go design your ideal template for what that looks like. And then let's figure out how to create a system, maybe like a review meeting, or something around that template. So, you know, I view us as kind of like a good coach, you know, we sort of know when to be prescriptive, and we try to know when to listen and learn and really try to help you shape your rituals as a product team. And, you know, we're learning just, you know, along the way. And I think that we're in that fortunate position to see, you know, kind of what's working and what's not. And so, you know, decision, whether that's decision making, or whether that's like reinventing a planning process, or whether that's like, you know, frustration around meetings, and like making sure that meetings are more effective, like those are the types of problems that we often get an intro into. Well, let's talk about the future, kind of the next frontier, as we see evolution in products to take to maintain that close touch with users, but at the same time, they need to do it at scale. We're seeing how AI is definitely accelerating some of that, but it's also uncertainty around like, what are the use cases that are more tangible for people? Like, at what point do you still need a human to provide that type of coaching? And I know we've been talking a lot about how AI is impacting Kota and the broader product ecosystem. So maybe you can tell me more about your own experience and of educating yourself on AI and then finding potential use cases for your own product. Yeah, in terms of personally, the way I like to approach learning in general is try to make it as close to feeling like play as possible. And so, for me, and I think for a lot of the people on the Kota team, that means this phrase, let the makers make. It's like, just let them play with all these new tools. And as much as possible, get a feel for which parts are interesting and which parts may be hyped. And I think learning through play is a good principle in that way. And so, you might not be trying to accomplish some super specific task. You might just be trying to do something in your personal life or trying to do something for your kids. And that's sort of how you develop an intuition for these things. So that's sort of one piece of it. I think in terms of how we're starting to think about it and apply it to specific use cases, our aspiration is really to be much more than just a writing assistant. I think, you know, we kind of probably six, seven months ago, when we were developing our strategy here, the core thesis was there are going to be a lot of tools that build a writing assistant. And those are important and awesome for the ecosystem. But we want to go much further than that, right? Like we want to take the sort of flexibility and power that is core to Kota and help you really be sort of automate the mundane stuff, really be kind of like a work assistant as opposed to a writing assistant. And so, a lot of the product development has been centered around that, right? It's been removing busy work by summarizing meetings, you know, pulling out items that are confusing from write-ups, summarizing customer feedback, you know, those types of use cases. And, you know, we've kind of developed a few different capabilities on that front. One is we call it magic block. It's basically like a thing that sits at the top of a canvas and it can basically take in any context. So you can feed it a whole table of data. You can feed it a page of full of writing. You can feed it sort of data from other tools. So it's sort of wildly powerful if you think about it and you start to get creative about the prompts that you're sort of giving that magic block. And the second is magic columns. So if you think about it, you know, a lot of our work happens in sort of pseudo databases, whether that's tasks or, you know, people or all types of different projects work. So, you know, if you have a column that can use AI and consume the context of the other bits of that row, the other columns in that row, you can do really interesting things. And so I think that we've been kind of focused on making sure that this really feels more like a work assistant than just it's going to help me write a blog post or it's going to help me write, you know, some, some less, less important and faster of our work. I'm in the middle of it as well. I'm playing with it. And as you mentioned, I started actually with some personal use cases, literally like, so from there, let's put together a shopping list to a trip in January and, and like, not feeling, not trying to go too fast. Because I think in this world, we don't know the potential with this type of technology, but at the same time, it's really hard to get to a point where you can do really, really, really advanced stuff, even the prompts like this and that, there's a certain science to it. And so the same way we talked about welcoming users into a product that can do a lot of things and how to make sure that they don't feel overwhelmed and they have some sort of like guidance in templates or other artifacts. When you think about AI onboarding, how can people start taking some of those baby steps to realize that there's a lot of potential and this can truly become an assistant to turbo charge productivity? Yeah, I think, you know, there's one school of thought which is equates the UI of AI with the value in the product itself. So what I mean by that is people because of the proliferation and the growth of chat GPT have sort of started to associate a chat interface with AI, right? And in some sense, that's good because it, you know, takes a consumer-like experience and then it lets that, you know, kind of become the norm, so to speak, in a business context and other places. And so, but I do think, you know, your point on onboarding is important that people may not need the full-fledged chat interface all the time, right? They may need, I'll give you a small example, we have a feature inside of Coda where if you set up a select list, like a status select list not started in progress are done, you can ask AI just to fill that column out for you based on another column. And so that's like a little baby step where the first time you do it, you're like, that was crazy, like it was mostly right. And I only had to correct like three statuses, like this is insane, that would have taken me 20 minutes, right? And so I think there are lots of little experiences and moments like that that are very important to build trust with the user that this thing is not this overhyped thing that VCs are talking about, but instead it is something that can tangibly help me today do my job faster, right? And I think that that also that also sort of leads to another point, which is, you know, I've heard a couple of people talk about this idea of fault tolerant interfaces, and I think that that's a good first principle. So and what that means for us is AI is not going to get it right every time, especially on the generative side. And so instead of having that be an output that is not malleable, that you can't edit, like the first principle when we built magic columns was this isn't a formulaic column that you can't edit like a number output, it is editable by default. And so, you know, we're going to give you a first stab at this, and then we know you're going to tweak it. And so I think as much as we can as as product designers and product managers, think with this this kind of principle of like fault tolerant interfaces, knowing that you're going to get it right 70 80. Ideally, that becomes 99% of the time, but we all have to live in the world as technology improves. And I think for product people, especially as we try to be at the cutting edge of all this new technology, it's important to realize that most of the stuff that is being out there is actually fluff. And that's creating a very basic interface to talk to GPT. It's not really AI, it's just a bridge. And so I think it's going to be very important to really figure out how to leverage technology in a unique way to truly add value to your product and not just try to put AI to raise more money or to try to create a couple of customers, because eventually, as this technology matures, I believe there would be some big winners, as well as some of these companies that are not really going to to be able to survive hype. Yeah, for sure. Yeah, I mean, I think the framework I like is, I think David Kosnick, our AI lead has said this bunch of times, but just thinking of AI as like a team of super smart interns, you know, and like, you wouldn't trust a team of super smart interns to do your whole job, but like you sure would give them a bunch of tasks and figure out how good things can get, right? And so like my recent example of this, I was talking to a friend who's in a similar role, and he gave me this example of using AI to kind of have a strategy conversation, which I really like. So it was basically like, okay, like here, I'm going to give you some context on the company, and then I'm going to give you some context on the strategy. And what I want you to do is apply, you know, this particular strategy framework, the seven powers framework, or apply a good strategy, bad strategy, and sort of bring me back some insights, right? And then we can like kind of have a dialogue almost. And that's really those types of applications, I think are really novel and interesting because it's pretty rare that you get to like call up an author of one of these books and have a conversation that's like super contextual on your strategy, right? But if, you know, I've been impressed with what GBT4 can output when you hand it sort of intentional prompts like that. So as you think about product people on your team, next generation of product leaders out there, what do you think is some of the best approach for them to really take advantage of the opportunity and educate themselves on this type of technology and other things that are relevant so they can accelerate their career? Yeah, I mean, I think if you think some to mind, one is try to put yourself in positions where you're going to learn by default, if that makes sense. So basically, you know, you can stay outside of the arena of AI and sort of look inside and try to learn, or you can like jump straight into the deep end or jump into the arena. And so I think that's probably the first and biggest choice. Like, how do you learn something new? Well, you have to describe it to someone, you have to teach it, you have to, you know, have a conversation with a really smart engineer about it, you have to design an interface around it. So I think there are, you know, that's probably like the sort of first principles answer is like, you got to get into the arena somehow, right? And so that would be my sort of first piece of advice. I think the other advice that I would give is, you know, I think Reid Hoffman, one of our investors reminds us of this every board meeting, but you know, it is extremely early in this journey. And so I think, you know, taking that longer arc mindset of, you know, if this is year one of, you know, mobile phones, I probably even bigger than that. This is year one of computers. This is your one of the internet. You know, what was happening then and like now we're 20, 20 plus years later, it's time to sort of at least have a clear understanding of what's happening. I think once you have a clear understanding of what's happening, you can start to really develop your own opinions, right? And like as product people, I think that's like ultimately what you need to do. You need to like form your own thesis. You need to listen to all the smart people, listen to all the podcasts, play with all the tools. But then at some point, you have to sort of say like, you know, here's my view of how this arc may play out, at least in my context. And that's where I think that's, yeah, it's my sort of quick advice. Well, but then let's use it with you. You're on camera. Let's say AI year to this year, yeah, year one, let's think about a AI year three, for example, these two smart interns are doing really cool stuff. What is, what is your take? What is your vision on what the role that AI will play within your product first, and then maybe within the broader product ecosystem? Yeah. I mean, I think there's like a few different levels of this. I think one is thinking about how roles change. I think there are a lot of facets of people's jobs that are, you know, admittedly low lower value work that is not enjoyable. So, you know, I'll give a product example. I've heard product managers say that they're the human copy, paste, right? And like, no one wants to be a human copy, paste, right? So like, I think, I think there are, there are whole swaths of a job that can be, you know, automated and or handed to agents and or, you know, some version of linking these tools together in novel ways, such that you just don't have to think about it. And then you kind of go closer to the higher value work, which is often closer to humans, right? It's often closer to being like empathetic to what customers are feeling and seeing out there in the market and being curious about customers and stuff like that. And I think honestly, like that's where most product people enjoy spending their time, right? Like you talk to most PMs and they're like, I just want to make a customer happy. Like I just want to go talk to them. I want to go sell my product to them. And so my hope is that the kind of work about work stuff ends up kind of going away. I think sort of maybe to zoom down a level, I think it's going to be really interesting to see how the interface changes to all of this, right? Like we're right now, we're like all sort of monotonously typing text into these things and having a conversation. Actually, the other day I was playing with a tool called Pi, which is sort of a personalized AI assistant. And it just struck me that the AI was sort of asking really clear, crisp questions back to me to sort of build up context and build up understanding. But it felt really laborious. It felt like I was having a, you know, like a 20, 30 minute chat conversation. I wasn't really in the mood to have a 20, 30 minute chat conversation. And so, you know, I think in the future, I think that there'll be sort of much more dynamic forms of this. So, you know, audio and just speaking that conversation, I think is a really interesting change in that interface. But yeah, those are some kind of quick musings. Lots of lots of people out there musing on this topic that are probably smarter than me. I know. And if we have this conversation six months from now, I'm going to ask a guy and we'll probably look back and be like, oh my God, remember this thing that we didn't talk about and became huge. And this other thing that we thought it was going to be huge. And suddenly, you know, it's not that much. So, it was great, Lane. Thank you so much for really sharing your insights from the front lines. And it was great to continue learning more about your own experience building products and building AI within products. Any time. Yeah. Thanks for having me. I appreciate it. Yeah. Love what you guys are doing. Thank you.