08/15/2019

“The world’s been divided into people who can make software, and the people who use software all day, and basically we think that that paradigm is not a good one. It feels kind of broken,” says Lane Shackleton, Head of Product at Coda, where they are building a new kind of document that blurs the line between users and programmers.

A Coda document starts out looking like a familiar online document, a lot like Google Docs. There’s a blinking cursor, you can bold and italicize text, add images, and collaboratively edit it alongside others. But a Coda table is much more powerful than a traditional table that you’d find in a typical word processor. Like a spreadsheet, the a Coda table allows you to create complex relationship between pieces of data via a formula language. Upon closer examination, the Coda table is more structured than spreadsheets and more closely resembles a friendly relational database, like Airtable.

If you’re familiar with Notion, another augmented document medium, this all may sound familiar. Coda differentiates itself in a few ways. For one, it allows users to build complex (but no-code) trigger-based workflows from within the tool, such as when a table is modified or a button is pressed. For another, Coda really sells itself as an app-builder, in that teams can use Coda documents on their phones as native mobile apps. For example, a bike shop can have its employees easily swipe and snap a photo of inventory directly into a Coda table simply by creating a photo column in that table. Coda takes care of converting that column into an interface that automatically pulls up the camera on mobile.

Coda was inspired by the founders’ experience at YouTube, where the company “ran on spreadsheets,” but now they dream of building a medium that fundamentally changes how people see themselves, as creators instead of merely as consumers, and reshapes the way teams, communities, and even families collaborate and function. It’s a big, compelling vision, and Coda has a long way to go.

Transcript sponsored by repl.it

Corrections to this transcript are much appreciated!

SK: Welcome, Lane. Welcome, Lane.

LS: Hi, Steve. Hi, Steve.

SK: Hi, yeah, thanks for making the time. Hi, yeah, thanks for making the time.

LS: Glad to be here. Glad to be here.

SK: So I would like to start with a bit of your background, because most of the guests in this podcast I think are pretty technical, and I think you come from more of a product background, is that right? So I would like to start with a bit of your background, because most of the guests in this podcast I think are pretty technical, and I think you come from more of a product background, is that right?

LS: Yeah, that's right. I'm probably a bit unlike some of your other guests. I don't have a long history of programming languages, necessarily. I guess my background, really quickly, is I studied sciences and anthropology in school, actually didn't start my career in tech, started as a mountain guide up in Alaska. And back in 2005, drove my car across the country to Silicon Valley. There were basically two hot companies at that time, VMware and Google. I started at Google in a customer facing role, and that was a really good introduction to how to make customers happy, and learn how to balance really fast people's emotions with solutions to their problems. Yeah, that's right. I'm probably a bit unlike some of your other guests. I don't have a long history of programming languages, necessarily. I guess my background, really quickly, is I studied sciences and anthropology in school, actually didn't start my career in tech, started as a mountain guide up in Alaska. And back in 2005, drove my car across the country to Silicon Valley. There were basically two hot companies at that time, VMware and Google. I started at Google in a customer facing role, and that was a really good introduction to how to make customers happy, and learn how to balance really fast people's emotions with solutions to their problems.

LS: In a lot of cases these were business owners who were using Google tools to grow their businesses. And then later, kind of got to be a little bit more technical, built some internal tools for support teams, moved over to product. Was really fortunate to be part of a lot of the early monetization efforts at YouTube, launching things like skip buttons on ads on YouTube, that eventually went from zero customers to a whole bunch of customers and a whole bunch of revenue. I guess overall my journey to Coda, though, Shishir, who's the CEO here was starting this company after he left YouTube, and kept showing me demos. And I got really enamored with the problem space, mostly because I have a really, I guess a deep empathy for people with the experience of knowing what they want to build, and not being able to make it with software. In a lot of cases these were business owners who were using Google tools to grow their businesses. And then later, kind of got to be a little bit more technical, built some internal tools for support teams, moved over to product. Was really fortunate to be part of a lot of the early monetization efforts at YouTube, launching things like skip buttons on ads on YouTube, that eventually went from zero customers to a whole bunch of customers and a whole bunch of revenue. I guess overall my journey to Coda, though, Shishir, who's the CEO here was starting this company after he left YouTube, and kept showing me demos. And I got really enamored with the problem space, mostly because I have a really, I guess a deep empathy for people with the experience of knowing what they want to build, and not being able to make it with software.

LS: I feel like I recall this very vividly from being inside of Google, where you have really amazing engineers, and I myself had ideas on what I wanted to make, but sometimes was unable to make those things. Yeah, and since then have just been really sort of enamored with the space, and been since inspired by a bunch of stuff that's probably closer to home for your listeners and you. A lot of Bret Victor's work, recently we've been pretty inspired by Nardi's work, and her book, A Small Matter of Programming. Also, things like Clayton Christensen's and Jobs-Be-Done framework. I feel like I recall this very vividly from being inside of Google, where you have really amazing engineers, and I myself had ideas on what I wanted to make, but sometimes was unable to make those things. Yeah, and since then have just been really sort of enamored with the space, and been since inspired by a bunch of stuff that's probably closer to home for your listeners and you. A lot of Bret Victor's work, recently we've been pretty inspired by Nardi's work, and her book, A Small Matter of Programming. Also, things like Clayton Christensen's and Jobs-Be-Done framework.

LS: So to me, Coda is sort of like this... relating it to my background... it's this way to kind of help people who are smart and capable, just the same way that I felt. So that's a little bit of my background, happy to take you into any of that. So to me, Coda is sort of like this... relating it to my background... it's this way to kind of help people who are smart and capable, just the same way that I felt. So that's a little bit of my background, happy to take you into any of that.

SK: Yeah. Yeah, it makes a lot of sense that this would be a very meaningful product for you, given your background. Particularly, I see the relevance of how your first role at Google, working with business owners, I feel like it definitely makes sense how this is kind of a similar power tool to help people with their businesses. Yeah. Yeah, it makes a lot of sense that this would be a very meaningful product for you, given your background. Particularly, I see the relevance of how your first role at Google, working with business owners, I feel like it definitely makes sense how this is kind of a similar power tool to help people with their businesses.

LS: Yeah. Yeah, absolutely. I mean a lot of those folks were small and medium sized businesses, and if you go look behind the scenes of many small and medium sized businesses, you see that there's a lot of tools that are kind of hacked together. And the businesses often have to create their own tools, because they can't buy really expensive software, so there are a lot of parallels there. Yeah. Yeah, absolutely. I mean a lot of those folks were small and medium sized businesses, and if you go look behind the scenes of many small and medium sized businesses, you see that there's a lot of tools that are kind of hacked together. And the businesses often have to create their own tools, because they can't buy really expensive software, so there are a lot of parallels there.

SK: So I think now would be a good time to do a quick two minute pitch for Coda. Like what it is, and what's the problem it's for. Why would people use it? So I think now would be a good time to do a quick two minute pitch for Coda. Like what it is, and what's the problem it's for. Why would people use it?

LS: Yeah. It kind of depends on who you're talking to, but I think we generally say it's a new type of document that combines the best of docs, spreadsheets, and applications. And that's maybe like the one liner. Yeah. It kind of depends on who you're talking to, but I think we generally say it's a new type of document that combines the best of docs, spreadsheets, and applications. And that's maybe like the one liner.

SK: Sure. Sure.

LS: I guess that- I guess that-

SK: I'd be curious to go into the different audiences, like maybe you could pick two or three audiences and tell me how you tailor the pitch for each of them? That would be interesting. I'd be curious to go into the different audiences, like maybe you could pick two or three audiences and tell me how you tailor the pitch for each of them? That would be interesting.

LS: Yeah, yeah. So I think if I'm talking to someone who doesn't know much about tech or software, I think I often like to frame it sort of at 50,000 feet. Basically, the world's been divided into people who can make software, and the people who use software all day, and basically we think that that paradigm is not a good one, it feels kind of broken. Because there are lots of smart and knowledgeable people out there who don't know how to write code, and shouldn't have to, to make tools to solve their problems. And so the 50,000 foot, 30,000 foot thesis is that we basically just need to give people the right tools to unlock that creativity, and a lot of the domain expertise that's out there. Yeah, yeah. So I think if I'm talking to someone who doesn't know much about tech or software, I think I often like to frame it sort of at 50,000 feet. Basically, the world's been divided into people who can make software, and the people who use software all day, and basically we think that that paradigm is not a good one, it feels kind of broken. Because there are lots of smart and knowledgeable people out there who don't know how to write code, and shouldn't have to, to make tools to solve their problems. And so the 50,000 foot, 30,000 foot thesis is that we basically just need to give people the right tools to unlock that creativity, and a lot of the domain expertise that's out there.

LS: And in terms of the product itself, if I were to be demoing it to someone, or showing it to someone, I'd probably start by showing them that it's just a doc surface, so blinking cursor and a toolbar, and something that can kind of grow with the evolution of an individual's project, or family's trip, or a team's evolution, starting out kicking off, all the way to tracking a bunch of tasks, all the way sort of through the life cycle of something. So that's maybe the 30,000 foot view. In terms of specific audiences, if I were to go pitch a product manager in Silicon Valley, that's an easy one, because I have a lot of background in that area. I definitely know this very well, writing specs, and designs and stuff back at YouTube and Google. And in terms of the product itself, if I were to be demoing it to someone, or showing it to someone, I'd probably start by showing them that it's just a doc surface, so blinking cursor and a toolbar, and something that can kind of grow with the evolution of an individual's project, or family's trip, or a team's evolution, starting out kicking off, all the way to tracking a bunch of tasks, all the way sort of through the life cycle of something. So that's maybe the 30,000 foot view. In terms of specific audiences, if I were to go pitch a product manager in Silicon Valley, that's an easy one, because I have a lot of background in that area. I definitely know this very well, writing specs, and designs and stuff back at YouTube and Google.

LS: And I think the main observation I'd start with, with someone like that, is oftentimes you outgrow and have to move around your tool set. And so if you take someone like that, they might start with writing an idea in a doc, and then eventually that becomes a set of structured data, things that they have to do, a set of tasks, and then there's a workflow around those tasks, and then they need to do things like launch that thing. So oftentimes that's four or five tools with someone like a product manager, and with Coda the idea is that really the tool can evolve with those needs. You can add multiple sections inside of one document, one for your high level goals, and then that's right next to all the tasks that the engineer is working on. And so there's this nice sort of all in one place aspect of it for someone who's usually used to traversing a bunch of different tools. And I think the main observation I'd start with, with someone like that, is oftentimes you outgrow and have to move around your tool set. And so if you take someone like that, they might start with writing an idea in a doc, and then eventually that becomes a set of structured data, things that they have to do, a set of tasks, and then there's a workflow around those tasks, and then they need to do things like launch that thing. So oftentimes that's four or five tools with someone like a product manager, and with Coda the idea is that really the tool can evolve with those needs. You can add multiple sections inside of one document, one for your high level goals, and then that's right next to all the tasks that the engineer is working on. And so there's this nice sort of all in one place aspect of it for someone who's usually used to traversing a bunch of different tools.

LS: Yeah, I don't know if that answers your question. Yeah, I don't know if that answers your question.

SK: Oh, yeah, it definitely does. There are a few different directions I want to go in at once, but one of the last things you said struck me, the all in one place aspect of it. Because I definitely see how there's a lot of powerful synergies of having an integrated experience, especially for people who aren't familiar with programming. But even for people who are, just it's nice to have an integrated experience. But I don't know if you're familiar with the Unix Philosophy, but there's this other philosophy of having a bunch of small things that do one job and do it really well, that you can kind of use altogether. Oh, yeah, it definitely does. There are a few different directions I want to go in at once, but one of the last things you said struck me, the all in one place aspect of it. Because I definitely see how there's a lot of powerful synergies of having an integrated experience, especially for people who aren't familiar with programming. But even for people who are, just it's nice to have an integrated experience. But I don't know if you're familiar with the Unix Philosophy, but there's this other philosophy of having a bunch of small things that do one job and do it really well, that you can kind of use altogether.

LS: Yeah. Yeah.

SK: So, yeah. So, yeah.

LS: Yeah, I mean that actually reminds me of the Rich Hickey talk Simple Versus Easy. I mean I think inside the document itself we actually think a lot about those atomic units, and how they compose on each other. So I think the idea of something being sort of simple and single purpose, maybe I'll use an example from our document. Yeah, I mean that actually reminds me of the Rich Hickey talk Simple Versus Easy. I mean I think inside the document itself we actually think a lot about those atomic units, and how they compose on each other. So I think the idea of something being sort of simple and single purpose, maybe I'll use an example from our document.

LS: So inside the document you can create a button, and that button basically does one thing. You press a button and it takes an action, like adding a row, or refreshing data, or something like that. But buttons can obviously be composed in meaningful ways with other things, to do things like take an action outside of the document. So if you want to send a text message, or a Slack message, or something like that, you're sort of taking two hopefully simple parts, a formula that takes an action outside of the document, like send a Slack message, and we're powering that button with that formula. And so that's maybe a pretty involved answer, or maybe an involved example. So inside the document you can create a button, and that button basically does one thing. You press a button and it takes an action, like adding a row, or refreshing data, or something like that. But buttons can obviously be composed in meaningful ways with other things, to do things like take an action outside of the document. So if you want to send a text message, or a Slack message, or something like that, you're sort of taking two hopefully simple parts, a formula that takes an action outside of the document, like send a Slack message, and we're powering that button with that formula. And so that's maybe a pretty involved answer, or maybe an involved example.

LS: There are probably ones that are simpler to your question, but I think in many ways we look at the parts inside of the document as those building blocks that makers and people who need to build tools can compose, and less of a, "We have the answer: this is the single way to do project management." Or, "This is the single way to do CRM." The idea is that you can kind of take these simple parts and build them up. There are probably ones that are simpler to your question, but I think in many ways we look at the parts inside of the document as those building blocks that makers and people who need to build tools can compose, and less of a, "We have the answer: this is the single way to do project management." Or, "This is the single way to do CRM." The idea is that you can kind of take these simple parts and build them up.

SK: Interesting. Yeah, yeah, yeah, I see what you mean. So within the tool you give them a bunch of simple, independent, orthogonal legos, and they can make their own system. Interesting. Yeah, yeah, yeah, I see what you mean. So within the tool you give them a bunch of simple, independent, orthogonal legos, and they can make their own system.

LS: Exactly. Yeah. Exactly. Yeah.

SK: But the tool itself, I guess, needs to have a lot of those legos in order for it to be competitive against a single purpose CRM, versus single purpose spreadsheet system used in combination. But the tool itself, I guess, needs to have a lot of those legos in order for it to be competitive against a single purpose CRM, versus single purpose spreadsheet system used in combination.

LS: Maybe. I think one piece of this is that you have to have... You can't have too many legos on the table, or it becomes difficult to understand which legos you should use when. So I think we think pretty carefully about each of those building blocks that we add. I think oftentimes if you decompose apps, like take a CRM for example, what you really have is sort of a database layer, which we have in our tables. You have a logic layer, which you can build up through automations and formulas, and then you have a presentation layer, and that presentation layer allows you to do things like add new candidates, or add new sales companies to that CRM. Maybe. I think one piece of this is that you have to have... You can't have too many legos on the table, or it becomes difficult to understand which legos you should use when. So I think we think pretty carefully about each of those building blocks that we add. I think oftentimes if you decompose apps, like take a CRM for example, what you really have is sort of a database layer, which we have in our tables. You have a logic layer, which you can build up through automations and formulas, and then you have a presentation layer, and that presentation layer allows you to do things like add new candidates, or add new sales companies to that CRM.

LS: And each of those, I guess, with Coda, is sort of right on the surface for you. And so in that sense, there are really only three, in that case three or four things, that you need to understand, in terms of the building blocks that make up something like that. And obviously, there are things that CRMs do that are quite powerful, but interestingly, I think when you compose things like formulas, and buttons are formulas, and tables, you can get pretty close. And each of those, I guess, with Coda, is sort of right on the surface for you. And so in that sense, there are really only three, in that case three or four things, that you need to understand, in terms of the building blocks that make up something like that. And obviously, there are things that CRMs do that are quite powerful, but interestingly, I think when you compose things like formulas, and buttons are formulas, and tables, you can get pretty close.

SK: You mentioned in a prior conversation that one of the main inspirations from Coda came from yours and the founders' work at YouTube, where the company was run in a collection of mostly spreadsheets. Is that an accurate way to explain it? You mentioned in a prior conversation that one of the main inspirations from Coda came from yours and the founders' work at YouTube, where the company was run in a collection of mostly spreadsheets. Is that an accurate way to explain it?

LS: Yeah. Yeah, that's kind of a fun story. So I worked with Shishir, who's one of the founders, at YouTube, and Alex, one of the other founders, also worked there. Shishir ran product and design, and I helped lead some of our monetization efforts there. Thinking about YouTube as an example I think is interesting. I mean, in many businesses, when you look at the software that they're buying, they're buying all these vertical apps. But oftentimes when you just say like, "Hey, pull open your laptop and show me how you're running the business," oftentimes they've been exporting to a spreadsheet and manipulating that data. Yeah. Yeah, that's kind of a fun story. So I worked with Shishir, who's one of the founders, at YouTube, and Alex, one of the other founders, also worked there. Shishir ran product and design, and I helped lead some of our monetization efforts there. Thinking about YouTube as an example I think is interesting. I mean, in many businesses, when you look at the software that they're buying, they're buying all these vertical apps. But oftentimes when you just say like, "Hey, pull open your laptop and show me how you're running the business," oftentimes they've been exporting to a spreadsheet and manipulating that data.

LS: And that's certainly the case at YouTube. Despite having amazing engineers capable of building all types of different tools, the leaders of that business chose to run on spreadsheets. And I think the main, I mean a few different reasons. One is, and I think this is really common, it basically enabled the team to flex a specific perspective on how a process should run, so that they weren't confined to a specific tool's way of doing things. So a few examples: you want to run a calibration process across 1000 people, you want to do comp planning across 1000 people, you want to run a OKR process for all your teams. Oftentimes we had a perspective on how those things should get done, and so instead of having some engineer change a front-end or add columns to a database at our request, it's much easier to just build those things up out of a spreadsheet. And that's certainly the case at YouTube. Despite having amazing engineers capable of building all types of different tools, the leaders of that business chose to run on spreadsheets. And I think the main, I mean a few different reasons. One is, and I think this is really common, it basically enabled the team to flex a specific perspective on how a process should run, so that they weren't confined to a specific tool's way of doing things. So a few examples: you want to run a calibration process across 1000 people, you want to do comp planning across 1000 people, you want to run a OKR process for all your teams. Oftentimes we had a perspective on how those things should get done, and so instead of having some engineer change a front-end or add columns to a database at our request, it's much easier to just build those things up out of a spreadsheet.

LS: So it's sort of one of those, I think a good example of having an opinion on how something should run, and so the team basically picks up the flexible tool that everyone could access. It's as simple as hitting the share button on a spreadsheet, to give people access to your tool. And a lot of that, I think, served as inspiration for some of the things that you see in Coda. So it's sort of one of those, I think a good example of having an opinion on how something should run, and so the team basically picks up the flexible tool that everyone could access. It's as simple as hitting the share button on a spreadsheet, to give people access to your tool. And a lot of that, I think, served as inspiration for some of the things that you see in Coda.

SK: So yeah, why is it do you think that spreadsheets have been so successful, as opposed to docs? Why wasn't things being run in a Google Doc, for example? So yeah, why is it do you think that spreadsheets have been so successful, as opposed to docs? Why wasn't things being run in a Google Doc, for example?

LS: Yeah, great question. I mean, I guess I would start by saying spreadsheets are completely amazing. We have a lot of folks inside of the company that are wizards when it comes to spreadsheets, and I think one of the main reasons, to answer your question, is that it's a very flexible thinking surface. It has this kind of open grid that makes it feel like anything is possible. That comes with some positive and negative consequences later, but I think as a starting point, it's quite approachable in that way. You don't really have to know anything about formulas, you don't really have to know anything about the deeper parts of a spreadsheet to get started. Yeah, great question. I mean, I guess I would start by saying spreadsheets are completely amazing. We have a lot of folks inside of the company that are wizards when it comes to spreadsheets, and I think one of the main reasons, to answer your question, is that it's a very flexible thinking surface. It has this kind of open grid that makes it feel like anything is possible. That comes with some positive and negative consequences later, but I think as a starting point, it's quite approachable in that way. You don't really have to know anything about formulas, you don't really have to know anything about the deeper parts of a spreadsheet to get started.

LS: And for the most part, it's based on a pattern of direct manipulation. You kind of highlight what you want to highlight, you touch what you want to touch, and for the most part, you get what you expect. So I think that's part of the reason. I think the other part is that spreadsheets, in their upper reaches, with a really flexible formula language that, interestingly, started for accountants, has grown into something that you can actually do a lot with. And I'm sure you've seen some of the crazy spreadsheets that people build, so I don't have to go too far into that, but eventually I think what happened is that it kind of became a tool of choice for everyone with a computer, and an obvious starting point for things that were going to include numbers, or calculations. Basically, a place where you could drop a bunch of information and then add some structure to it. And for the most part, it's based on a pattern of direct manipulation. You kind of highlight what you want to highlight, you touch what you want to touch, and for the most part, you get what you expect. So I think that's part of the reason. I think the other part is that spreadsheets, in their upper reaches, with a really flexible formula language that, interestingly, started for accountants, has grown into something that you can actually do a lot with. And I'm sure you've seen some of the crazy spreadsheets that people build, so I don't have to go too far into that, but eventually I think what happened is that it kind of became a tool of choice for everyone with a computer, and an obvious starting point for things that were going to include numbers, or calculations. Basically, a place where you could drop a bunch of information and then add some structure to it.

LS: Whereas, I think that historically, to go back to your question, docs haven't always been a great place to add that structure. And by structure, I mean even the most simple things, like having a task with a status, or really, really basic things. The tables inside of docs historically have been more layout based, and so it's less of a space that can grow with your idea. Whereas, I think that historically, to go back to your question, docs haven't always been a great place to add that structure. And by structure, I mean even the most simple things, like having a task with a status, or really, really basic things. The tables inside of docs historically have been more layout based, and so it's less of a space that can grow with your idea.

SK: Yeah, I see what you're saying. Well, spreadsheets are also almost superficial, in a way that Airtable's kind of innovated in making it not, and you guys also. It's more like the table is the data, and then you have also a presentation layer as well, but you guys make a clear distinction, when a Google Doc is... it feels like it's less semantic in some ways. Yeah, I see what you're saying. Well, spreadsheets are also almost superficial, in a way that Airtable's kind of innovated in making it not, and you guys also. It's more like the table is the data, and then you have also a presentation layer as well, but you guys make a clear distinction, when a Google Doc is... it feels like it's less semantic in some ways.

LS: Yeah. Yeah. Yeah. Yeah.

SK: So it seems like we're in a bit of a renaissance of the next version of spreadsheets. It seems like Airtable, and then there was also Fieldbook, which I don't think is anymore. And Notion recently added a kind of data spreadsheet model, and you guys. Why do you think now is the time for everyone to be rethinking the future of docs and spreadsheets? So it seems like we're in a bit of a renaissance of the next version of spreadsheets. It seems like Airtable, and then there was also Fieldbook, which I don't think is anymore. And Notion recently added a kind of data spreadsheet model, and you guys. Why do you think now is the time for everyone to be rethinking the future of docs and spreadsheets?

LS: Yeah, that's a great question. I guess the first thing we're saying is we're big fans of anyone trying to make it easy for makers to build what they need. I think this is a really positive step forward for a lot of people who are subject matter experts, and knowledge workers. In terms of why we're seeing it now, that's a good question. I think in many ways, what you see is people starting to take back control of the tools that they use. And this isn't necessarily a new phenomenon, at least in the last few years, but just if you look at the IT purchasing process, it used to be that there would be one person who oversaw it, and they would have to sort of procure software in a way that they distributed it to everybody inside of a company. Yeah, that's a great question. I guess the first thing we're saying is we're big fans of anyone trying to make it easy for makers to build what they need. I think this is a really positive step forward for a lot of people who are subject matter experts, and knowledge workers. In terms of why we're seeing it now, that's a good question. I think in many ways, what you see is people starting to take back control of the tools that they use. And this isn't necessarily a new phenomenon, at least in the last few years, but just if you look at the IT purchasing process, it used to be that there would be one person who oversaw it, and they would have to sort of procure software in a way that they distributed it to everybody inside of a company.

LS: And I think in the last few years, you've seen a lot of bottom's up growth of some of these tools, like Slack and others, where people were having an opinion and choosing the tool that they wanted, and then bringing that to their business, or to their families, or whatever. I mean I think it's hard to look past some of the other big innovations that got us here, so bringing something like a spreadsheet from your machine to the cloud was a big one. It made it possible for this to be a truly collaborative surface, and I think that was a big step. And I think in the last few years, you've seen a lot of bottom's up growth of some of these tools, like Slack and others, where people were having an opinion and choosing the tool that they wanted, and then bringing that to their business, or to their families, or whatever. I mean I think it's hard to look past some of the other big innovations that got us here, so bringing something like a spreadsheet from your machine to the cloud was a big one. It made it possible for this to be a truly collaborative surface, and I think that was a big step.

LS: And then to go beyond that, I think everyone has their own take on what it is, and what it should be. I kind of like to think about it as there are three big buckets in the landscape. You have people that are starting with a doc, or a doc or a wiki-like environment, which I think Notion started with. You have the table, which obviously Airtable has done a great job with, and then you also have this bucket of apps. Everything from small niche apps to big things, like Salesforce. And then to go beyond that, I think everyone has their own take on what it is, and what it should be. I kind of like to think about it as there are three big buckets in the landscape. You have people that are starting with a doc, or a doc or a wiki-like environment, which I think Notion started with. You have the table, which obviously Airtable has done a great job with, and then you also have this bucket of apps. Everything from small niche apps to big things, like Salesforce.

LS: And so we end up competing, or we end up in the space of all three of these tools, depending on how the user chooses to use Coda, and what they're trying to do. So some people use us just as a simple document surface. It's interesting, we were pulling some stats the other day, and it looks like about half of our documents are basically used without a table. So people really kind of just leaning into the document with multiple sections, to structure prose and written text. And so we end up competing, or we end up in the space of all three of these tools, depending on how the user chooses to use Coda, and what they're trying to do. So some people use us just as a simple document surface. It's interesting, we were pulling some stats the other day, and it looks like about half of our documents are basically used without a table. So people really kind of just leaning into the document with multiple sections, to structure prose and written text.

SK: That seems surprising to me. Why aren't these people using Google Docs? In theory, I would expect Google Docs to be full featured as a document than Coda. That seems surprising to me. Why aren't these people using Google Docs? In theory, I would expect Google Docs to be full featured as a document than Coda.

LS: Yeah. Yeah, that's a good question. I mean, Google Docs is certainly... and Word... are certainly very mature document surfaces. You can do all types of formatting, you can do things that I think you would need to if you were printing regularly, if you're writing a novel, things like that. But I think the reality is that a lot of the prose that's written nowadays is written for collaboration. It's written to send out to a team, it's written as a plan, or a goal, or a spec, or something like that. Yeah. Yeah, that's a good question. I mean, Google Docs is certainly... and Word... are certainly very mature document surfaces. You can do all types of formatting, you can do things that I think you would need to if you were printing regularly, if you're writing a novel, things like that. But I think the reality is that a lot of the prose that's written nowadays is written for collaboration. It's written to send out to a team, it's written as a plan, or a goal, or a spec, or something like that.

LS: And so some of the more mature features of something like docs become a little less important in that world. And I mean, to kind of go directly at the question, I think one of the reasons that people pick us up is because, I love the Alan Kay quote of, "Simple things are simple, and complex things are possible." I think in our case, the simple things should be simple. You should be able to just start with some prose, or an idea, and write some text, and then you should also be able to grow, and evolve that. And I think that more and more people are choosing alternatives to things like Google Docs, because I think in some senses, you end up outgrowing... just in the life cycle of like, one project, or one family trip, or one whatever it is... you end up outgrowing the capabilities and migrating to a spreadsheet. What we really commonly see in businesses when we first talk to them is this combination of docs and spreadsheets. Where you have docs that are pointers to spreadsheets, and back and forth. I've definitely lived through that world, and it's... I think there's probably a better way, so. And so some of the more mature features of something like docs become a little less important in that world. And I mean, to kind of go directly at the question, I think one of the reasons that people pick us up is because, I love the Alan Kay quote of, "Simple things are simple, and complex things are possible." I think in our case, the simple things should be simple. You should be able to just start with some prose, or an idea, and write some text, and then you should also be able to grow, and evolve that. And I think that more and more people are choosing alternatives to things like Google Docs, because I think in some senses, you end up outgrowing... just in the life cycle of like, one project, or one family trip, or one whatever it is... you end up outgrowing the capabilities and migrating to a spreadsheet. What we really commonly see in businesses when we first talk to them is this combination of docs and spreadsheets. Where you have docs that are pointers to spreadsheets, and back and forth. I've definitely lived through that world, and it's... I think there's probably a better way, so.

SK: That makes sense. I guess it's impressive that you're able to sell the vision of, even though you only need a doc right now, start with us, because we'll grow with you. Because I feel like most of your value-add, and the exciting features that you bring to the table, they might not get to them until they've already written a couple of docs. So that's what I'm impressed by. That makes sense. I guess it's impressive that you're able to sell the vision of, even though you only need a doc right now, start with us, because we'll grow with you. Because I feel like most of your value-add, and the exciting features that you bring to the table, they might not get to them until they've already written a couple of docs. So that's what I'm impressed by.

LS: Yeah. Yeah, I mean I think one thing that goes a long way in that respect is just having a template gallery that has lots and lots of examples of things that our makers have built, and submitted to us. Or templates that we've made for them. So it cues you in to the fact that, "Oh, this later can have a table of tasks that I can use to track things, but right now all I have in my head is an idea." I hope that our users glean that from seeing a lot of the examples that we put out. Yeah. Yeah, I mean I think one thing that goes a long way in that respect is just having a template gallery that has lots and lots of examples of things that our makers have built, and submitted to us. Or templates that we've made for them. So it cues you in to the fact that, "Oh, this later can have a table of tasks that I can use to track things, but right now all I have in my head is an idea." I hope that our users glean that from seeing a lot of the examples that we put out.

SK: Yeah, that makes a lot of sense. So based on the conversation we've had so far, I get the feeling that this is a tool that is very easy to sell to a product manager, but I'd be also curious to hear what other sorts of initial users you're targeting now. Like of course it's a very general purpose tool, so you know, everyone uses spreadsheets, so in theory everyone would use this, but are you focusing on some initial people? And another thing I'll add to the question is, it sounds like you're focused on companies and teams collaborating, as opposed to more individual use. Would that also be accurate? Yeah, that makes a lot of sense. So based on the conversation we've had so far, I get the feeling that this is a tool that is very easy to sell to a product manager, but I'd be also curious to hear what other sorts of initial users you're targeting now. Like of course it's a very general purpose tool, so you know, everyone uses spreadsheets, so in theory everyone would use this, but are you focusing on some initial people? And another thing I'll add to the question is, it sounds like you're focused on companies and teams collaborating, as opposed to more individual use. Would that also be accurate?

LS: Yeah, so definitely like you said, it's a very horizontal tool, so it's always kind of challenging to define a specific target. But we do see a lot of success in teams, and I think that just comes back to the fact that it's a document surface, it's collaborative, you can see the avatars and the people that you're working with in there, and they can collaborate in real time. I also think that we have a fairly deeply held belief that these makers can come from anywhere, so I think we're careful not to label or categorize people too much. And I think we've been inspired, in part, by jobs-be-done and Clayton Christensen's work there. I guess, so just some other examples to make it more tangible- Yeah, so definitely like you said, it's a very horizontal tool, so it's always kind of challenging to define a specific target. But we do see a lot of success in teams, and I think that just comes back to the fact that it's a document surface, it's collaborative, you can see the avatars and the people that you're working with in there, and they can collaborate in real time. I also think that we have a fairly deeply held belief that these makers can come from anywhere, so I think we're careful not to label or categorize people too much. And I think we've been inspired, in part, by jobs-be-done and Clayton Christensen's work there. I guess, so just some other examples to make it more tangible-

SK: Maybe... sorry, just to interrupt... could you talk more about jobs-be-done? I haven't heard of that. Maybe... sorry, just to interrupt... could you talk more about jobs-be-done? I haven't heard of that.

LS: Yeah. So I guess the general thesis behind jobs-be-done is users hire, or people hire products in their daily lives to solve specific jobs. And that's sort of in contrast to, this set of demographics will buy this product sort of causally, because of their demographic. And the classic example that he uses is a fun one, it's the milkshake analogy. I don't know, have you heard this? Yeah. So I guess the general thesis behind jobs-be-done is users hire, or people hire products in their daily lives to solve specific jobs. And that's sort of in contrast to, this set of demographics will buy this product sort of causally, because of their demographic. And the classic example that he uses is a fun one, it's the milkshake analogy. I don't know, have you heard this?

SK: No. No.

LS: So I think they were doing, I may butcher this story, but I'll recount it as best I can from memory. So basically, they were doing some research for, I think it was McDonald's or something, and they were trying to figure out why people were buying milkshakes between seven and nine AM, and this was sort of confusing everybody. And what they figured out was that people were buying these to take on their commute. And so he uses this analogy of jobs and commuting with the milkshake, basically the job, or the task, that a user or person needs an answer for is something to keep them occupied on their commute. So I think they were doing, I may butcher this story, but I'll recount it as best I can from memory. So basically, they were doing some research for, I think it was McDonald's or something, and they were trying to figure out why people were buying milkshakes between seven and nine AM, and this was sort of confusing everybody. And what they figured out was that people were buying these to take on their commute. And so he uses this analogy of jobs and commuting with the milkshake, basically the job, or the task, that a user or person needs an answer for is something to keep them occupied on their commute.

LS: And they could solve this with a banana, but that's only two minutes on a 30 minute commute. And they could solve this with a glass of water, but that's kind of boring. Nowadays, people probably use podcasts on their phones to keep them entertained, but the general idea is that- And they could solve this with a banana, but that's only two minutes on a 30 minute commute. And they could solve this with a glass of water, but that's kind of boring. Nowadays, people probably use podcasts on their phones to keep them entertained, but the general idea is that-

SK: Right now, someone's listening right now. Right now, someone's listening right now.

LS: Exactly. Exactly.

SK: This is the job being done. This is the job being done.

LS: This person, yeah. But the general idea is basically that a milkshake solves this job really well, because it's sort of the slow burn of happiness to the person who's commuting. It takes them 20 minutes to drink this milkshake. And so this sort of presents as a nice metaphor for other instances where people have a very specific job, or a very specific task, and it's sort of unimportant what their demographic is, and what's more important is that they have a specific job to solve. Yeah, I don't know if that makes sense. This person, yeah. But the general idea is basically that a milkshake solves this job really well, because it's sort of the slow burn of happiness to the person who's commuting. It takes them 20 minutes to drink this milkshake. And so this sort of presents as a nice metaphor for other instances where people have a very specific job, or a very specific task, and it's sort of unimportant what their demographic is, and what's more important is that they have a specific job to solve. Yeah, I don't know if that makes sense.

SK: Cool, thanks. And just, I guess, to remind you where you were going before I interrupted you, you were maybe going to give some examples of specific people, and the problems they're using Coda to solve. Cool, thanks. And just, I guess, to remind you where you were going before I interrupted you, you were maybe going to give some examples of specific people, and the problems they're using Coda to solve.

LS: Yeah. Yeah, so on what you might call the consumer side, I think we have people doing everything from organizing trips to planning weddings, to splitting expenses with their friends. There's sort of a very wide... Actually, more recently, some of our community has been really into building games. So people sort of go all over the map on that side of the house. In terms of businesses and teams, obviously engineering teams, design teams, product teams, salespeople, recruiting teams. Those are sort of, to name the laundry list. Just to maybe dig into one of those for a second, it's kind of a story that I really like. Yeah. Yeah, so on what you might call the consumer side, I think we have people doing everything from organizing trips to planning weddings, to splitting expenses with their friends. There's sort of a very wide... Actually, more recently, some of our community has been really into building games. So people sort of go all over the map on that side of the house. In terms of businesses and teams, obviously engineering teams, design teams, product teams, salespeople, recruiting teams. Those are sort of, to name the laundry list. Just to maybe dig into one of those for a second, it's kind of a story that I really like.

LS: So one of the first times I feel like I realized that we were kind of on to something was when I sat down a few years ago, now, with a 23 year old recruiter. And he started the conversation by saying, "I'm not a spreadsheet person. I don't know how to code," and I was like, "It's okay, let's see what you need to do." And I kind of watched, and helped him build a tool for his team to track... at the time this was engineering candidates. And the tool was basically an editable database with a bunch of views for each person, and a few controls, like select list, where you could let people filter. There's a few interesting parts, to me, about this example. So one of the first times I feel like I realized that we were kind of on to something was when I sat down a few years ago, now, with a 23 year old recruiter. And he started the conversation by saying, "I'm not a spreadsheet person. I don't know how to code," and I was like, "It's okay, let's see what you need to do." And I kind of watched, and helped him build a tool for his team to track... at the time this was engineering candidates. And the tool was basically an editable database with a bunch of views for each person, and a few controls, like select list, where you could let people filter. There's a few interesting parts, to me, about this example.

LS: One is, almost three years later, they're using the same tool, so it was custom and sticky for their team. And I guess more personally, the neat part for me was watching him roll out this tool, and the sense of pride that he had in rolling out this tool. Clayton Christensen, again, talks about how every great product has a social, functional, and emotional aspect. And this was, it was really neat to see the pride emotion of him making software for the first time. Like really presenting a tool that he had made. And then this social aspect, of his team really feeling like, "Oh, this person's capable and really valued, and contributing to our team." One is, almost three years later, they're using the same tool, so it was custom and sticky for their team. And I guess more personally, the neat part for me was watching him roll out this tool, and the sense of pride that he had in rolling out this tool. Clayton Christensen, again, talks about how every great product has a social, functional, and emotional aspect. And this was, it was really neat to see the pride emotion of him making software for the first time. Like really presenting a tool that he had made. And then this social aspect, of his team really feeling like, "Oh, this person's capable and really valued, and contributing to our team."

LS: And so I think that when we do our jobs right, that's the result. People feel like they can take their subject matter expertise, their domain expertise, and present it to their teams, and build what feel like perfectly-customized tools to that group of people. And actually to maybe take that example a step further, what's really interesting to me is like, in a traditional software model, what would have happened when that team evolved. So that team ended up going from 5 people to 20 people over the last three years. What would have happened is, they would have had to go back to, if that tool was built in code, they would have had to go back to some engineer and ask for changes continuously. And instead, they were able to actually change that tool themselves as the team evolved. And so there was a really concrete sense of agency that I think is quite powerful when we do it right. And so I think that when we do our jobs right, that's the result. People feel like they can take their subject matter expertise, their domain expertise, and present it to their teams, and build what feel like perfectly-customized tools to that group of people. And actually to maybe take that example a step further, what's really interesting to me is like, in a traditional software model, what would have happened when that team evolved. So that team ended up going from 5 people to 20 people over the last three years. What would have happened is, they would have had to go back to, if that tool was built in code, they would have had to go back to some engineer and ask for changes continuously. And instead, they were able to actually change that tool themselves as the team evolved. And so there was a really concrete sense of agency that I think is quite powerful when we do it right.

SK: Yeah, it sounds like a really obvious value proposition: impress your coworkers with your superpowers. Yeah. I, and I think many engineers, we feel that sort of pride all the time. It's a lot of what drives us. So it's cool that you get to democratize that: I built a thing that you can all use, and you'll think of me fondly while you use it. Yeah, it sounds like a really obvious value proposition: impress your coworkers with your superpowers. Yeah. I, and I think many engineers, we feel that sort of pride all the time. It's a lot of what drives us. So it's cool that you get to democratize that: I built a thing that you can all use, and you'll think of me fondly while you use it.

LS: Yeah, and you know, I think there's something really impactful about having someone think about themselves differently in that way. Think, "Oh, I'm just as capable as other people at making things again." The analogy I like to use is, when you ask a group of four year olds who's an artist, everybody raises their hand. But then you get the same group at 40, and zero people will raise their hand. And I feel like in general, the artist has kind of been beaten out of people when it comes to software and tools, and so far as we can reinvigorate that, that makes me happy. Yeah, and you know, I think there's something really impactful about having someone think about themselves differently in that way. Think, "Oh, I'm just as capable as other people at making things again." The analogy I like to use is, when you ask a group of four year olds who's an artist, everybody raises their hand. But then you get the same group at 40, and zero people will raise their hand. And I feel like in general, the artist has kind of been beaten out of people when it comes to software and tools, and so far as we can reinvigorate that, that makes me happy.

SK: So do you find that the story you told of someone starting this new system from scratch, and it growing over time, to being central to the business, that that's kind of more the approach? Or do you also find people migrating existing spreadsheets or CRM systems into Coda? What's the breakdown? I don't know if you have the numbers on that, what's the breakdown of starting from scratching and growing, or migrating into it? So do you find that the story you told of someone starting this new system from scratch, and it growing over time, to being central to the business, that that's kind of more the approach? Or do you also find people migrating existing spreadsheets or CRM systems into Coda? What's the breakdown? I don't know if you have the numbers on that, what's the breakdown of starting from scratching and growing, or migrating into it?

LS: Yeah. I mean, interestingly, that process was... I think if I recall correctly... that process was run out of a custom tool, or a niche vertical tool, that then they realized that that tool kind of didn't fit them, and so they ended up migrating that into a spreadsheet, and then from a spreadsheet into Coda. So in terms of the numbers and where we see migration from it's really all over the map. There's no simple statement to make there. We see people migrating from docs, we see people migrating from project management tools of all kinds, vertical apps, like little mini CRM systems, specific recruiting tools, and a lot of spreadsheets. Yeah. I mean, interestingly, that process was... I think if I recall correctly... that process was run out of a custom tool, or a niche vertical tool, that then they realized that that tool kind of didn't fit them, and so they ended up migrating that into a spreadsheet, and then from a spreadsheet into Coda. So in terms of the numbers and where we see migration from it's really all over the map. There's no simple statement to make there. We see people migrating from docs, we see people migrating from project management tools of all kinds, vertical apps, like little mini CRM systems, specific recruiting tools, and a lot of spreadsheets.

SK: And are you... I don't exactly know how to ask this question in a precise way, but I guess, how often are people customizing things, versus just using them. Like, customizing them once... I wouldn't be all that surprised if people customize things once a year, and then maybe made a few tweaks here and there, but mostly were just using it as an app, or app/spreadsheet. And are you... I don't exactly know how to ask this question in a precise way, but I guess, how often are people customizing things, versus just using them. Like, customizing them once... I wouldn't be all that surprised if people customize things once a year, and then maybe made a few tweaks here and there, but mostly were just using it as an app, or app/spreadsheet.

LS: Yeah, good question. I mean I think this is, it's sort of worth pointing out that it depends on the type of doc that you're talking about. So as I was mentioning before, half of our active docs don't have tables, and so in that sense, they're constantly being customized, because people are writing meeting notes, or people are writing ideas, or designs, or whatever. Yeah, good question. I mean I think this is, it's sort of worth pointing out that it depends on the type of doc that you're talking about. So as I was mentioning before, half of our active docs don't have tables, and so in that sense, they're constantly being customized, because people are writing meeting notes, or people are writing ideas, or designs, or whatever.

NS: But sort of maybe more to your question, for more involved docs that might wholesale replace another system, or a workflow that the team previously had, oftentimes what we see is this pattern of two or three makers co-creating the tool for their team. And this makes sense, given a role, like something that's probably familiar to your listeners is if it's a product team, the product manager and the engineering lead, or the product manager and the design lead, are kind of building the ideal workflow for their team. And that's basically a general setup process, and so the doc goes through lots of iterations in that early phase, and then like you said, it may get used for a period of time, and then something changes, right. The project winds down, or the team grows, and the effort expands considerably. And then you go through another iteration of that building process. But sort of maybe more to your question, for more involved docs that might wholesale replace another system, or a workflow that the team previously had, oftentimes what we see is this pattern of two or three makers co-creating the tool for their team. And this makes sense, given a role, like something that's probably familiar to your listeners is if it's a product team, the product manager and the engineering lead, or the product manager and the design lead, are kind of building the ideal workflow for their team. And that's basically a general setup process, and so the doc goes through lots of iterations in that early phase, and then like you said, it may get used for a period of time, and then something changes, right. The project winds down, or the team grows, and the effort expands considerably. And then you go through another iteration of that building process.

LS: To use a real example, there's a customer, set of folks at Uber, who used us to redesign the driver app. It was kind of like the largest redesign of the driver app that Uber has done. And that followed a very similar pattern. You had really two people setting up a construct for hundreds of engineers to go work, and so for a week they were building out the perfect system. (That's actually in our template gallery. Kind of in that top row, if you're curious.) They were building up this perfect system so that all these teams that are distributed all over the world could then enter their information about how that project is going, and break apart this massive project into coherent parts, and then they let hundreds of engineers, hundreds of people loose on that tool, and then over the life cycle of the project they ended up building out other aspects of it later, so at the midway point they built this really neat kind of pie chart, which is basically a progress of how close they are to code complete. And that became the thing that they started every meeting with, it was, "How close are we to actually shipping this thing?" To use a real example, there's a customer, set of folks at Uber, who used us to redesign the driver app. It was kind of like the largest redesign of the driver app that Uber has done. And that followed a very similar pattern. You had really two people setting up a construct for hundreds of engineers to go work, and so for a week they were building out the perfect system. (That's actually in our template gallery. Kind of in that top row, if you're curious.) They were building up this perfect system so that all these teams that are distributed all over the world could then enter their information about how that project is going, and break apart this massive project into coherent parts, and then they let hundreds of engineers, hundreds of people loose on that tool, and then over the life cycle of the project they ended up building out other aspects of it later, so at the midway point they built this really neat kind of pie chart, which is basically a progress of how close they are to code complete. And that became the thing that they started every meeting with, it was, "How close are we to actually shipping this thing?"

LS: And that's kind of what I mean by this is ideally a tool that can evolve with the life cycle of a really small project, or a really small set of tracking requirements, to something very, very large. And even within that project, kind of evolve with it. And that's kind of what I mean by this is ideally a tool that can evolve with the life cycle of a really small project, or a really small set of tracking requirements, to something very, very large. And even within that project, kind of evolve with it.

SK: Yeah, so I'd be curious to know what sort of agency people have farther down the food chain. If certain engineers wanted to customize things, do they have the permissions to do that, and how do they make sure they're not stepping on other people's toes, or messing with other integrations that are core? Yeah, so I'd be curious to know what sort of agency people have farther down the food chain. If certain engineers wanted to customize things, do they have the permissions to do that, and how do they make sure they're not stepping on other people's toes, or messing with other integrations that are core?

LS: Yeah. Yeah, that's definitely... it's a tough question when you're organizing hundreds of people. Yeah. Yeah, that's definitely... it's a tough question when you're organizing hundreds of people.

SK: It's almost like the flexibility of the tool is working against you here. Because there's certain things that you want to have be like, "No, no, no these are rigid, that we're top down deciding for you as the organizers, but we also want to give you flexibility on things we don't care about." It's almost like the flexibility of the tool is working against you here. Because there's certain things that you want to have be like, "No, no, no these are rigid, that we're top down deciding for you as the organizers, but we also want to give you flexibility on things we don't care about."

LS: Right, right. Yeah, there's probably a couple things to say about that question, like maybe the first is that because it's a document, you have what you're used to seeing in documents, which is some basic set of permissions. So you can give people view only access, you can give people comment only access, or edit access. And so in this case, like for the executive team, I think they only gave view access, because they didn't want executives going in there and changing a bunch of things. Right, right. Yeah, there's probably a couple things to say about that question, like maybe the first is that because it's a document, you have what you're used to seeing in documents, which is some basic set of permissions. So you can give people view only access, you can give people comment only access, or edit access. And so in this case, like for the executive team, I think they only gave view access, because they didn't want executives going in there and changing a bunch of things.

LS: But to your question on further down the chain, and if I'm an engineering manager in Dublin, what does it look like to change this tool? One of the things that we see really commonly is people creating their perfect view of a set of data. So in this case, you might have one Uber task table, or one features table or something like that, and then an individual team goes in and creates a section, and that section is, they title it, like, "This is our section as the design team," or something like that. And all they're doing is creating a filtered view of that larger dataset. But kind of importantly, it's all the same dataset, right, so it's kind of right through from that view to the core table and back. But to your question on further down the chain, and if I'm an engineering manager in Dublin, what does it look like to change this tool? One of the things that we see really commonly is people creating their perfect view of a set of data. So in this case, you might have one Uber task table, or one features table or something like that, and then an individual team goes in and creates a section, and that section is, they title it, like, "This is our section as the design team," or something like that. And all they're doing is creating a filtered view of that larger dataset. But kind of importantly, it's all the same dataset, right, so it's kind of right through from that view to the core table and back.

LS: And so the part, if you were to ask the folks from Uber, I think that they have said to us that this is sort of the central piece of this: there's one source of truth for all of this data, and yet I can have as many different views of that data as I want, and I can add controls on top of that to do additional filters, and I can add buttons to make it easy for people who are just contributors to that document to come in and add a new feature, or whatever it is. So- And so the part, if you were to ask the folks from Uber, I think that they have said to us that this is sort of the central piece of this: there's one source of truth for all of this data, and yet I can have as many different views of that data as I want, and I can add controls on top of that to do additional filters, and I can add buttons to make it easy for people who are just contributors to that document to come in and add a new feature, or whatever it is. So-

SK: I just want to- I just want to-

LS: Yeah. Yeah.

SK: A quick, quick idea. So we have a single source of truth for features for the whole Uber company, and then we're in Dublin, we have a filtered view for just the features we're responsible for. And let's say, for whatever reason, we want to add a column to... because we care about some extra piece of metadata on features that isn't in the source of truth table. I guess the question is two part. One, if we added a column, would it accidentally... like, would we kind of unintentionally add a column to the whole table, and then people at HQ would get upset at us? And then the second question is, is there a way to add that attribute in a way that doesn't, other people don't even see it? A quick, quick idea. So we have a single source of truth for features for the whole Uber company, and then we're in Dublin, we have a filtered view for just the features we're responsible for. And let's say, for whatever reason, we want to add a column to... because we care about some extra piece of metadata on features that isn't in the source of truth table. I guess the question is two part. One, if we added a column, would it accidentally... like, would we kind of unintentionally add a column to the whole table, and then people at HQ would get upset at us? And then the second question is, is there a way to add that attribute in a way that doesn't, other people don't even see it?

LS: Yeah, that's a very deep question, but I'll do my best to kind of summarize a few parts of this. So I guess to maybe start from the concrete, in this case one of the first things that the designers of this document did was go off and get all the trackers that each team wanted to use. And so there was a common understanding of which columns are important. And interestingly, the alternative that they were looking at was literally dozens and dozens of spreadsheets. And all of those spreadsheets had slightly different column names, but effectively representing the same thing, right, and so there's one obvious win for them as the designers of this tool, that they now don't have to reconcile all these different, slightly different names that represent the same thing across all these things. Yeah, that's a very deep question, but I'll do my best to kind of summarize a few parts of this. So I guess to maybe start from the concrete, in this case one of the first things that the designers of this document did was go off and get all the trackers that each team wanted to use. And so there was a common understanding of which columns are important. And interestingly, the alternative that they were looking at was literally dozens and dozens of spreadsheets. And all of those spreadsheets had slightly different column names, but effectively representing the same thing, right, and so there's one obvious win for them as the designers of this tool, that they now don't have to reconcile all these different, slightly different names that represent the same thing across all these things.

LS: So as the designers of the tool for 300 plus people, what they did was, they did the column reconciliation, if you will, and agreed upon that. Sort of down a level from that, let's say that they still missed that column for the person in Dublin, that person, if they have edit access to the document, can certainly add that column. And it turns out that that's actually really important and useful too, because they may want to branch some variant of that features table in a way that's helpful for them. And so as long as they're not "polluting" the other views by forcing that column to be added everywhere in all the other views, then that mostly gets out of the way for everybody else. So as the designers of the tool for 300 plus people, what they did was, they did the column reconciliation, if you will, and agreed upon that. Sort of down a level from that, let's say that they still missed that column for the person in Dublin, that person, if they have edit access to the document, can certainly add that column. And it turns out that that's actually really important and useful too, because they may want to branch some variant of that features table in a way that's helpful for them. And so as long as they're not "polluting" the other views by forcing that column to be added everywhere in all the other views, then that mostly gets out of the way for everybody else.

LS: At certain points, I think folks are finding the tool very useful, and adding lots of columns, and so I think that there was this question around like, "Oh, is there a different level of permissions here, where we can say people should only be able to add rows, and edit rows, but not change the columns, or the formulas in some of the existing columns," and stuff like that. And that's something we're certainly thinking about, and have been prototyping some answers to. But at its core, I think in a place like Uber that's super collaborative, and trusts people to do the right thing, the ability to add columns as that engineering manager allows you to evolve the tool in a way that's helpful to you. And ultimately, that's probably a good thing. At certain points, I think folks are finding the tool very useful, and adding lots of columns, and so I think that there was this question around like, "Oh, is there a different level of permissions here, where we can say people should only be able to add rows, and edit rows, but not change the columns, or the formulas in some of the existing columns," and stuff like that. And that's something we're certainly thinking about, and have been prototyping some answers to. But at its core, I think in a place like Uber that's super collaborative, and trusts people to do the right thing, the ability to add columns as that engineering manager allows you to evolve the tool in a way that's helpful to you. And ultimately, that's probably a good thing.

SK: Yeah, that makes a lot of sense. And then if we wanted to do it, it occurs to me that the Dublin team could create a new table that just references the old table, and then has as many columns as we want, additionally. Yeah, that makes a lot of sense. And then if we wanted to do it, it occurs to me that the Dublin team could create a new table that just references the old table, and then has as many columns as we want, additionally.

LS: Yeah, that's right. If it actually became, if it was materially different in its data structure, or it was, it sort of felt divergent enough from that first features table or whatever it was, that's right. They could also create a table, and then look up from the other table. Yeah. Yeah, that's right. If it actually became, if it was materially different in its data structure, or it was, it sort of felt divergent enough from that first features table or whatever it was, that's right. They could also create a table, and then look up from the other table. Yeah.

SK: Cool. Cool.

LS: Yeah. Yeah.

SK: So the tagline seems to be, "Docs as powerful as an app." Is that right? Or did I missay it? So the tagline seems to be, "Docs as powerful as an app." Is that right? Or did I missay it?

LS: No, that's right. I mean I think the thesis is that you can build a doc as powerful as an app. And so we haven't really talked much about mobile, but we spent a bunch of time on mobile making sure that it actually felt app-like. I think we've been saying this phrase for a while, and before we launched mobile people would sort of hold up their phones, and say, "Oh, you mean like this. This mobile app on my phone?" And we'd kind of say, "Yeah, eventually." And nowadays, we can more confidently say, "Yes, it's something that feels just like an app on your phone," and there's a couple... I'm happy to go into it... there's a couple things that we do to make that feel like an app. No, that's right. I mean I think the thesis is that you can build a doc as powerful as an app. And so we haven't really talked much about mobile, but we spent a bunch of time on mobile making sure that it actually felt app-like. I think we've been saying this phrase for a while, and before we launched mobile people would sort of hold up their phones, and say, "Oh, you mean like this. This mobile app on my phone?" And we'd kind of say, "Yeah, eventually." And nowadays, we can more confidently say, "Yes, it's something that feels just like an app on your phone," and there's a couple... I'm happy to go into it... there's a couple things that we do to make that feel like an app.

SK: Yeah, how did you pull that one off? Yeah, how did you pull that one off?

LS: Yeah, we're really just getting started on pulling it off, I would say. But our first version of it does a couple of things. I mean I think the first thing that's probably noticeable is we take the section list that's on the left, if you're on desktop, and the whole idea behind the section list is basically you can add, effectively, multiple pages, or multiple different spaces, to the same document. And so what we do is we take that section list, and then we flip it and make it feel like native navigation on iOS and Android. And that kind of gives you this sense right away that you're in an app. Yeah, we're really just getting started on pulling it off, I would say. But our first version of it does a couple of things. I mean I think the first thing that's probably noticeable is we take the section list that's on the left, if you're on desktop, and the whole idea behind the section list is basically you can add, effectively, multiple pages, or multiple different spaces, to the same document. And so what we do is we take that section list, and then we flip it and make it feel like native navigation on iOS and Android. And that kind of gives you this sense right away that you're in an app.

SK: And so you put it at the bottom? Is that where you put it? And so you put it at the bottom? Is that where you put it?

LS: That's right. Yeah, like on iOS it's just a little tab bar on the bottom. That's right. Yeah, like on iOS it's just a little tab bar on the bottom.

SK: And where is it in Android? I don't even know where Android navigation is, and I have an Android phone. And where is it in Android? I don't even know where Android navigation is, and I have an Android phone.

LS: Yeah, in Android it's sort of similar. Yeah, in Android it's sort of similar.

SK: Oh, okay. Oh, okay.

LS: Yeah, and then I mean there's some like material design choices that we're in the midst of finishing, but sort of generally the same principle. So yeah, that's sort of the first noticeable thing is that you get this experience of, "Oh, I open this up, I open one of these docs, and it feels application-like because the navigation feels native to the platform." I guess some of the other things that we do that are noticeable, so one interaction that feels very app-like is in tables. When you have buttons, and especially multiple buttons, we allow you to kind of like, first of all we create a card, that is a nice clean summary of that row. And then we allow you to swipe the card, an interaction most people are probably familiar with from stuff like Gmail, where you can swipe to archive. Yeah, and then I mean there's some like material design choices that we're in the midst of finishing, but sort of generally the same principle. So yeah, that's sort of the first noticeable thing is that you get this experience of, "Oh, I open this up, I open one of these docs, and it feels application-like because the navigation feels native to the platform." I guess some of the other things that we do that are noticeable, so one interaction that feels very app-like is in tables. When you have buttons, and especially multiple buttons, we allow you to kind of like, first of all we create a card, that is a nice clean summary of that row. And then we allow you to swipe the card, an interaction most people are probably familiar with from stuff like Gmail, where you can swipe to archive.

LS: But in our case, maybe to use a customer example, we have a customer who built an inventory tracker to track bikes from a bike shop. And the realities of being in a bike shop all day is that you're not behind a computer all the time, and this particular set of people were out in the field, and so they were constantly on their mobile device, and if you want to check in or check out a bike, or say, "This bike needs repair," on desktop, there were three buttons. (And this is also in the template gallery if you want to go look at how this works.) But in our case, maybe to use a customer example, we have a customer who built an inventory tracker to track bikes from a bike shop. And the realities of being in a bike shop all day is that you're not behind a computer all the time, and this particular set of people were out in the field, and so they were constantly on their mobile device, and if you want to check in or check out a bike, or say, "This bike needs repair," on desktop, there were three buttons. (And this is also in the template gallery if you want to go look at how this works.)

LS: But on desktop this is three buttons that say "check in", "check out", and "needs repair". And on mobile, when you pull up that same list of bikes, you get a nice little picture of that bike and some of the details about the bike and its status, and then you can swipe to take those actions, and that feels native app-like. And interestingly, as a person who created that doc and configured that doc, it's like, you don't really have to do anything, we just take those actions from buttons and transform them to those swipe actions on mobile. So it's kind of- But on desktop this is three buttons that say "check in", "check out", and "needs repair". And on mobile, when you pull up that same list of bikes, you get a nice little picture of that bike and some of the details about the bike and its status, and then you can swipe to take those actions, and that feels native app-like. And interestingly, as a person who created that doc and configured that doc, it's like, you don't really have to do anything, we just take those actions from buttons and transform them to those swipe actions on mobile. So it's kind of-

SK: Yeah, so swipe right is one of the buttons, swipe left is the other, and what's the third button? Yeah, so swipe right is one of the buttons, swipe left is the other, and what's the third button?

LS: We actually split the swipe right. Right now it's only swipe right, and we split it into three actions. If you've seen, I think this is also a fairly common pattern, but you swipe and then you get three options. We actually split the swipe right. Right now it's only swipe right, and we split it into three actions. If you've seen, I think this is also a fairly common pattern, but you swipe and then you get three options.

SK: Yep, and you press one, yeah, yeah, yeah. Okay. Cool. Yep, and you press one, yeah, yeah, yeah. Okay. Cool.

LS: Yeah, so that's, I guess, that's a couple ways that we've done so far. Have a bunch of other ideas. I guess one of the other ones that people have really started latching onto recently is, imagine you're doing that same inventory tracking, and you want to take a picture of every bike, so you can just be out in the field, and take a picture of the part that needs repair, or whatever, and upload it directly to that row from the phone's camera. So you have a nice entry point to native things that you're used to doing on your phone all the time. Yeah, so that's, I guess, that's a couple ways that we've done so far. Have a bunch of other ideas. I guess one of the other ones that people have really started latching onto recently is, imagine you're doing that same inventory tracking, and you want to take a picture of every bike, so you can just be out in the field, and take a picture of the part that needs repair, or whatever, and upload it directly to that row from the phone's camera. So you have a nice entry point to native things that you're used to doing on your phone all the time.

SK: A camera, an image column- A camera, an image column-

LS: That's right. That's right.

SK: Presents itself as a camera button, and you can either upload, or take a photo. Presents itself as a camera button, and you can either upload, or take a photo.

LS: That's right, yeah. That's right, yeah.

SK: Oh, I see, there are all these little clever things you can do, that just automatically, behind the scenes, adapt the interface to a mobile. Oh, I see, there are all these little clever things you can do, that just automatically, behind the scenes, adapt the interface to a mobile.

LS: Yeah, that's right. That's right. Yep, exactly. I mean, that's sort of the fundamental premise here, is that you shouldn't have to be an app designer, app developer type person. We do most of that automatically for you. We switch the tabs for you, we switch buttons for you, we take abstractions like the image column and do that for you. Yeah, that's right. That's right. Yep, exactly. I mean, that's sort of the fundamental premise here, is that you shouldn't have to be an app designer, app developer type person. We do most of that automatically for you. We switch the tabs for you, we switch buttons for you, we take abstractions like the image column and do that for you.

SK: So I'd be curious to hear a bit about where Coda's going, the fuller vision. So right now, I get the impression that it's an internal tools product. Like we spoke about before, you have to have a certain amount of trust with the people you share edit access with, you know, they're on your team, they're not going to be nefarious agents. And it feels kind of like Google Docs, or like spreadsheets, you know? Use it with your friends and your coworkers. Do you ever see it as being... you say the word app, do you ever see it as being something that a company would make as an external app? That they'd sell things on it, or have external users? So I'd be curious to hear a bit about where Coda's going, the fuller vision. So right now, I get the impression that it's an internal tools product. Like we spoke about before, you have to have a certain amount of trust with the people you share edit access with, you know, they're on your team, they're not going to be nefarious agents. And it feels kind of like Google Docs, or like spreadsheets, you know? Use it with your friends and your coworkers. Do you ever see it as being... you say the word app, do you ever see it as being something that a company would make as an external app? That they'd sell things on it, or have external users?

LS: Yeah. Absolutely. I mean I'll get back to the full vision piece in a second, but just to answer your latter question, I mean we ran... Recently, we ran a kind of contest called "Maker Fest" with Product Hunt, and the idea behind that was to get people building app-like things. And you can see, I mean there's just a crazy array of things that, of varied application-like concepts that people built on that, and those are sort of purpose built to be external, in the sense that those people weren't building it for their internal company. In many cases, they were an individual person with no company, or doing it on the side. So for sure, we're already starting to see this pattern of people building tools for other people, and- Yeah. Absolutely. I mean I'll get back to the full vision piece in a second, but just to answer your latter question, I mean we ran... Recently, we ran a kind of contest called "Maker Fest" with Product Hunt, and the idea behind that was to get people building app-like things. And you can see, I mean there's just a crazy array of things that, of varied application-like concepts that people built on that, and those are sort of purpose built to be external, in the sense that those people weren't building it for their internal company. In many cases, they were an individual person with no company, or doing it on the side. So for sure, we're already starting to see this pattern of people building tools for other people, and-

SK: Could you give me an example of something? Could you give me an example of something?

LS: Yeah, yeah. Probably like the... let's see. Let's see what the most interesting examples are. I guess a couple of the examples that were interesting to me, first people building very basic things that are first instances. If you were to like, pick up a programming language, you might build a to-do list or something like that. And then to take it a step further, because we have things like a now formula, and you can write complex functions, people started building Pomodoro-style techniques, where I can start a timer, and time my to do list. All the way to some fairly crazy games people built. More recently someone had four buttons that control up, down, left and right, where you can walk a rectangle around. Yeah, yeah. Probably like the... let's see. Let's see what the most interesting examples are. I guess a couple of the examples that were interesting to me, first people building very basic things that are first instances. If you were to like, pick up a programming language, you might build a to-do list or something like that. And then to take it a step further, because we have things like a now formula, and you can write complex functions, people started building Pomodoro-style techniques, where I can start a timer, and time my to do list. All the way to some fairly crazy games people built. More recently someone had four buttons that control up, down, left and right, where you can walk a rectangle around.

LS: And some of these examples start to feel very much like apps that people very much want other people to use. And right now, I think we still have a lot of work to do on the publishing side of this. How do we make it easy for those people to take one of those concepts, and really publish it broadly? We're starting from a nice foundation, in the sense that sharing a document's fairly easy, you hit the share button and then you decide who should have access to it. But there's probably a lot more that we can do. I know that there's a bunch more things that we can do to make it easy to take one of these app-lite concepts and distribute it more broadly. And some of these examples start to feel very much like apps that people very much want other people to use. And right now, I think we still have a lot of work to do on the publishing side of this. How do we make it easy for those people to take one of those concepts, and really publish it broadly? We're starting from a nice foundation, in the sense that sharing a document's fairly easy, you hit the share button and then you decide who should have access to it. But there's probably a lot more that we can do. I know that there's a bunch more things that we can do to make it easy to take one of these app-lite concepts and distribute it more broadly.

LS: I think the other interesting thing is when you start to have derivative work, and we see this in the template gallery a lot. Where someone will take a template. To use a simple example, my to-do list is in there. They'll take a simple example like that, and then they'll sort of build upon it, and then they'll resubmit it to us, and they'll say, "Oh, this is a variant of that," so you get this interesting branching effect of being able to have someone else's perspective layered on to other people's. I think the other interesting thing is when you start to have derivative work, and we see this in the template gallery a lot. Where someone will take a template. To use a simple example, my to-do list is in there. They'll take a simple example like that, and then they'll sort of build upon it, and then they'll resubmit it to us, and they'll say, "Oh, this is a variant of that," so you get this interesting branching effect of being able to have someone else's perspective layered on to other people's.

SK: Do you have a story for managing variants, and merging things that are kind of similar together? Do you have a story for managing variants, and merging things that are kind of similar together?

LS: Yeah, so we've thought about this a bit, and we have some prototypes. We don't have a perfect answer for it right now, but it's certainly something that we're thinking about. In many ways, the merging the variants sometimes feels unnecessary, because someone has taken a different perspective on it, and what we want to see is the breadth of these different perspectives. So eventually, when you're searching in the template gallery, or you're searching for a solution, really, you can sort of see all the permutations and get to play with each of them, and then decide which variant works for you. So in some sense, we could go solve that problem, we have some ideas of how we might do it, but it probably starts with fundamentally questioning the problem. Yeah, so we've thought about this a bit, and we have some prototypes. We don't have a perfect answer for it right now, but it's certainly something that we're thinking about. In many ways, the merging the variants sometimes feels unnecessary, because someone has taken a different perspective on it, and what we want to see is the breadth of these different perspectives. So eventually, when you're searching in the template gallery, or you're searching for a solution, really, you can sort of see all the permutations and get to play with each of them, and then decide which variant works for you. So in some sense, we could go solve that problem, we have some ideas of how we might do it, but it probably starts with fundamentally questioning the problem.

SK: That's an interesting point. So I think when I asked the question of the full vision, and for if you'd be able to build externally facing tools, I thought that was the same question, but apparently there's a different... there's a distinction between that question, and what's the full vision for Coda. That's an interesting point. So I think when I asked the question of the full vision, and for if you'd be able to build externally facing tools, I thought that was the same question, but apparently there's a different... there's a distinction between that question, and what's the full vision for Coda.

LS: Yeah. Yeah, I mean I guess the full vision might be a little more kind of back to where we started. I guess I like to think about it in two ways. There's basically the micro level, and there's sort of bubbling back up to the macro level. On the micro level, I personally really like to think about the individual stories of how we change people's lives, and how we have the opportunity to make them feel different about themselves in a really positive way. Taking that domain expert, that subject matter expert, and enabling them to actually build the tool that they need, and have a thinking surface that can evolve with their thought process. That, on an individual level, I think is our core aim. And it's a little bit back to the story I was telling you about that recruiter, on an individual level. Yeah. Yeah, I mean I guess the full vision might be a little more kind of back to where we started. I guess I like to think about it in two ways. There's basically the micro level, and there's sort of bubbling back up to the macro level. On the micro level, I personally really like to think about the individual stories of how we change people's lives, and how we have the opportunity to make them feel different about themselves in a really positive way. Taking that domain expert, that subject matter expert, and enabling them to actually build the tool that they need, and have a thinking surface that can evolve with their thought process. That, on an individual level, I think is our core aim. And it's a little bit back to the story I was telling you about that recruiter, on an individual level.

LS: I mean I think if we bubble all the way back up to the macro level, I think we have a really unique opportunity to marry something that is really approachable, i.e., A doc, with the power of application-like concepts. And the sort of punchline there is that we can change how teams, and communities, and families can grow, and evolve. And that, I think, is incredibly powerful if we can do that right. Actually, it makes me think a little bit about my oldest son. I mean I think if we bubble all the way back up to the macro level, I think we have a really unique opportunity to marry something that is really approachable, i.e., A doc, with the power of application-like concepts. And the sort of punchline there is that we can change how teams, and communities, and families can grow, and evolve. And that, I think, is incredibly powerful if we can do that right. Actually, it makes me think a little bit about my oldest son.

LS: So I have a four year old who's finishing preschool at a Reggio Emilia school. I don't know if... are you familiar with Reggio philosophy? So I have a four year old who's finishing preschool at a Reggio Emilia school. I don't know if... are you familiar with Reggio philosophy?

SK: Mm-hmm (affirmative). Mm-hmm (affirmative).

LS: Yeah. Yeah.

SK: But I guess maybe just give us a brief overview. But I guess maybe just give us a brief overview.

LS: Yeah, yeah, yeah. So the basic idea behind Reggio is that kids... Like, learning should be self guided and rooted in experience and exploration, and kind of importantly, they're equal members to the broader community of adults and kids. And so a lot of learning environments, teachers are viewed as the ones that hold all the knowledge, and they impart that knowledge to their students, but Reggio sort of flips that. And I think that in a Reggio philosophy, kids are meant to construct knowledge through exploration, and observation, and discussion. I don't know if you want to add anything to that, based on your knowledge of... Yeah, yeah, yeah. So the basic idea behind Reggio is that kids... Like, learning should be self guided and rooted in experience and exploration, and kind of importantly, they're equal members to the broader community of adults and kids. And so a lot of learning environments, teachers are viewed as the ones that hold all the knowledge, and they impart that knowledge to their students, but Reggio sort of flips that. And I think that in a Reggio philosophy, kids are meant to construct knowledge through exploration, and observation, and discussion. I don't know if you want to add anything to that, based on your knowledge of...

SK: I didn't actually quite realize that it was so... anyways, I knew that it had a very progressive feel to it, but that sounds very similar to my own educational philosophy, so that's kind of interesting to find out. I didn't actually quite realize that it was so... anyways, I knew that it had a very progressive feel to it, but that sounds very similar to my own educational philosophy, so 