SFG 35: Shishir Mehrotra on reinventing team collaboration with AI

‍

In this episode of the Startup Field Guide podcast, Sandhya Hegde chats with Shishir Mehrotra, CEO and co-founder of Coda. Coda is a collaborative workspace that brings together teams and tools to create organized workflows in docs. Started in 2014, Coda serves over 80% of the Fortune 100. Last valued at $1.4B,  Coda is used by over 25,000 teams including ones at Figma, The New York Times, Square, Doordash, and Toast.

‍
Be sure to check out more Startup Field Guide Podcast episodes on Spotify, Apple, and Youtube. Hosted by Unusual Ventures General Partner Sandhya Hegde (former EVP at Amplitude), the SFG podcast uncovers how the top unicorn founders of today really found product-market fit.

‍

If you are interested in learning more about some of the themes and ideas in this episode, please check out the Unusual Ventures Field Guides on coming up with a founding insight and working with design partners.

‍

‍

Episode transcript

‍

Shishir Mehrotra on the early days of YouTube

‍

Sandhya Hegde

Welcome to the Startup Field Guide, where we learn from successful founders of unicorn startups, how their companies truly found product market fit. I'm your host, Sandhya Hegde, and today we will be diving into the story of Coda. Coda is a collaborative workspace that brings together teams and tools to create organized workflows in docs.

Started in 2014, Coda serves over 80 percent of the Fortune 100. Last valued at $1. 4 billion, Coda is now used by over 40, 000 teams, including ones at Figma, New York Times, Square, DoorDash, and Toast. Joining us today is Shishir Mehrotra, CEO and co founder of Coda. Welcome to the Field Guide, Shishir.

You've had this incredible career as a product leader, which, you've shared so many learnings with the whole ecosystem on at Microsoft and Google. And I believe you were actually really early on the YouTube team at Google. So before we actually dive into Coda, I'm really curious kind of what your experience was starting the YouTube product and team while you were at Google.

Shishir Mehrotra

Yeah, maybe it's just a bit of background. I joined Google in 2008. So it was right after the YouTube acquisition.. And I was part of the, what you can think of is like the second wave of people that went in past the founding team of YouTube. But we were pretty early in that journey, and I ended up running the YouTube group until about 2014.

So pretty wide journey, I think the easiest way to describe YouTube in those days is andit almost sounds, hard to believe, but in 2008, YouTube was seen as a failure. YouTube was seen as we were losing a lot of money, hundreds of millions of dollars a year. We were known for grainy videos of cats doing odd things. We had a big lawsuit from from Viacom. And, it took a while for us to work our way through that. I had an old boss that told me that every business goes through...

3 main phases. First you're a joke, then you're a threat, then you're obvious. And when you're a joke, nobody believes in you, then you become a threat, and everybody has to respond. And you become obvious, and everybody assumes everything you're going to do is going to work, and they work around you.

And, I like to say I got to work on YouTube through all three phases. Early days, it was hard to get anybody to pay attention. We were written off, not only by the industry, but even by the other teams at Google. Gradually we found momentum. We found our path to profitability.

We got the business working. We figured out how to grow the creator ecosystem. And all of a sudden we looked like a threat and everybody had a YouTube response, and then we became obvious and all of a sudden it looked like we were the only player in town. Interestingly, the cycle continues, right?

So if you think about YouTube today. It's back to threat and there's now new competitors. But it's an interesting time to go through that journey.

Sandhya Hegde

What's your take on Shorts versus TikTok?

Shishir Mehrotra

Oh, first of all, I give enormous credit not only to the TikTok team, but before them, I think the real progenitor of that format was actually Snap. And I think that we launched a camera product at YouTube like 2010, 2011 and one of the famous features of the camera product was if you took your phone out and you started taking video like this, we would stop recording and make you turn your phone.

We thought that it was so silly to shoot vertical video that you should make people turn their phones to shoot it. Often great businesses have really simple insights. As silly as that insight seems, I think Evan and the Snap team were the first ones to realize actually if you let people keep their phone vertical, you can not only build really compelling video, you open up the opportunity for building a scrollable feed.

And I think that, I think the format of a scrollable feed is just so obviously superior to something you have to click in and out of that it like immediately took off at Snap. And I think Tiktok did a really nice job. Actually, I think most people don't know the history started musically and then became Tiktok.

But they did a really good job taking the best parts of that and marrying it with a sort of new content ecosystem and really growing it. But, it's interesting to me how simple insights can often lead a long way. In terms of the comparison of the products, I think the main thing I am proud of the YouTube team, they recognized that consumers seem to really like the format, and Susan and Neil and team pivoted quickly to go after it. I think they've done a nice job. I think it's a good product. And, there's obvious value propositions for keeping it in one experience.

But, yeah, it's very interesting. I look back and say, How did we miss vertical video? It just seems crazy.

Sandhya Hegde

YouTube was the original pioneer for great content divorced of a social graph, right? So this in some ways, it was the era of the pre Tiktok era for just if I just want to binge on great content, where do I go? And I think it was it's so widely successful that it's hard to think of other startups as a threat until they really become very big, right? It's the classic innovator's dilemma.

Shishir Mehrotra

It's interesting, one thing I'd say, we were chatting a little bit before we started the call about the term product market fit. And I've always had this love hate relationship with the term product market fit. Because, by the time I left YouTube, we were over a billion users.

And we set this famous goal of getting to a billion hours a day of consumption, which we did hit. And yet, if you were to show up at any of our exec team meetings or retreats or so on, one of our main topics was we did not think we had found true product market fit, and it's interesting how when people use the term, they act like it's binary, like you have it or you don't, but actually that's not quite the way product market fit works.

Product market fit is something that, you achieve it with one group, but you always want this next group. And, for us, we did very well with younger audiences. We did well with teenagers, but we saw other parts of the video ecosystem that were serving an older demographic.

Netflix was doing very well at the same time. And so from our perspective, we didn't think we had product market fit. So we're constantly working on whatever that next group was or might be the next country we were launching in and we didn't have product market fit. So it definitely wasn't a binary like we have it now and we didn't have it, now we do. It was a constant journey on product market fit.

‍

The founding insight that led to Coda

‍

Sandhya Hegde

Yeah, every time innovate on your product, it's a question of how can you further improve the product market fit you already have. Every time the market changes on you, there's a question of does your product need to respond to where the most attractive part of the market is today as opposed to where it was yesterday?

And I love how thoughtful you have been as a, ex product leader and now CEO about what the product community and ecosystem needs to do to think about this topic. And maybe that kind of brings me to Coda. Like, how did Coda start? It sounds like maybe it was germinating during the time you were at YouTube and, was a problem you were thinking about even then.

Shishir Mehrotra

I mean, honestly, it's a problem that I've been Interested 20 years now So you know took my time at Microsoft and even before that and like I said, I think great companies start with fairly simple observation and the Coda observation is a very simple one is we believe that there is an artificial line between docs and apps.

And one way to think about it is if you look at the average company or team, I think the latest stat is the average company is something like 265 different software applications that they purchased which seems like a lot, but then if you go look and watch what they're doing all day, we did this really interesting study with this company, Glean, that does built in enterprise search product, where we found that the average worker inside a company has 2, 000 documents per employee.

So if you have a 1, 000 person company, you probably have 2 million documents. Andover 90 percent of their time spent is in front of documents, not applications. So you spend all this money on applications. And yet, if you were to peer over the shoulder of any person in any workplace, what you'd probably find them looking at is a document, a spreadsheet, or a presentation.

And that was this really interesting observation, is that, we pay all this money for apps, and yet the world runs on Docs, Sheets, and Slides. And a sort of second part of that observation is that those surfaces haven't fundamentally changed in over 40 years now. We have this running joke at the company that if Austin Powers were to pop out of his freezing chamber today he wouldn't know what clothes to wear or what music to listen to but he could probably work a document, a spreadsheet, and a presentation because the core metaphors were all set by the teams that built WordStar, Harvard Graphics, and VisiCalc and they haven't really changed since the 1970s, which is just incredible to us.

So that led to our approach. We said, what if we started with a completely new blinking cursor, start from scratch, build a new surface that's built around this idea that this isn't about just digitizing paper and a professor's slide and so on, but really about how we run teams, and what we're actually building with documents is many applications.

And we said we're going to build an entirely new surface to go and do that with the view of being that blinking cursor of choice for this, what we call the next generation of makers. That's how Coda started.

Sandhya Hegde

 I feel like it's like such a daunting company idea to take on because it's so simple. And yet like you are competing with decades of existing behaviors and assumptions, you're competing with both incumbent companies, two of which you have worked at. I don't know if you were involved in their enterprise suite at all, but like you're competing both with the Googles and Microsofts of the world as well as a slew of other startups that are maybe doing like point solutions for these different things.

How did you think about what was the going to be the positioning? And, if you were challenged by any of the folks around you around okay, why does the world need this? I'm curious what was the seed of conviction in your mind in terms of okay, why is this going to be, different?

Why are we going to be able to like win hearts and minds?

Shishir Mehrotra

Peter Thiel wrote a really good book called Zero to One, where he talked about how a startup is this smallest group of people that you can get together that have a similar view of some idea that everybody else thinks is crazy, but they think is really obvious. And that's definitely what it felt like.

The early days of starting Coda. I would give that some version of that set of observations and people would say, I don't understand what's wrong with office? What's wrong with Google Docs? And it's yeah, it's been that way for 50 years. So what's wrong with it?

Usually that means it's stood the test of time. And so by itself, that isn't enough, hasn't changed. It's not enough reason to change. And I would tell them about don't you think it's a little bit odd that you use documents in these different ways and like you stretch your applications other ways and say, yeah, but they're just used to it was hard for them to picture anything different and so to some extent we had to build it to show them and there's some products and companies not many, but there's some products and companies where the concept is enough and you can just say, here's what, but, imagine pitching YouTube that way. Imagine pitching TikTok that way, just it's not possible. You have to build and show them. To some extent, you build that team that has that shared viewpoint and you wait to prove it to the world. I think in terms of the ecosystem, yeah, we have this very interesting ecosystem because at one extreme we have documents that have been roughly the same for 50 years. And the other extreme, the way Coda gets used, is we get used as a replacement for applications. And people will start with Coda and they'll do their meeting notes and they'll build up their wikis and their team hubs and so on in Coda.

But gradually what they're doing is they're getting rid of tools, dedicated tools that they had for project management or for CRM or for an inventory system or for an invoicing system or for a system to email their customers or so on. And so in some senses we have this like on one side, very established hasn't changed in a long time set of behaviors and competitors. And the other side, we have this incredibly wide spectrum. I think we've probably been in a bakeoff with just about every packaged application you can think of which is really interesting.

And our positioning for that is very simple. It's an all in one product. And so it's the only product where you can do all that in one place in a familiar surface. And I think that turns out to really resonate with people that if you become that tool you reach for then we earn all these other use cases. One of the things about the company is we earn our right to the complicated use cases by winning the simple ones first and that's why we see team start with Coda with some very simple ideas and say oh, I just want... one of the things people love about Coda,it looks like a document but one of the simplest innovations is the left hand side of Coda is a set of pages and it looks like tabs in a spreadsheet turned sideways. I don't know why spreadsheets have a monopoly on tabs. We thought that was really stupid. And so we just built another product.

But it turns out to be like a very easy way to work your way into the product. Oh, it's a document with structure. And then you realize, oh, I can use that for my wiki. I can use that for my project. I can use that for my team. I can use that for an account plan. And then you gradually uncover all the other things you can do in Coda and you discover, Oh, I have tables in here that are more powerful than many databases. I have all these integrations. I can go and synchronize from over 600 different applications. It's concepts of buttons and automations. And I can now build up these workflows. I can build forms and layouts. And you gradually, but you start incredibly simple. And our promise is it's an all in one product.

You won't run out of gas.

Sandhya Hegde

So cool. I also love the name Coda itself.

Shishir Mehrotra

 You know the history of the name Coda, the reason for the name is that it's "A doc" backwards. And it was interesting we went through our naming exercise in a Coda doc, it wasn't called Coda at the time, we had a code name for the company, and the company was called Krypton at the time.

And we had  200 names on this list. Our head of brand had us do a different brainstorm every day for five straight days. It was like one day it was things that represented building blocks. Another day was like interesting sounds. Another day was like interesting acronyms and so on.

And Coda ended up on this list, I can't even remember how it ended up on this list. It was like in the middle of the list. And one of the designers picked it up and said you know that name is "a doc" backwards. And he actually made an animation of the name flipping around to be "a doc". And then this went from being in the middle of the list to right at the top of the list.

And all of a sudden, all of us fell in love with it. 

‍

Coda's Alpha launch

‍

Sandhya Hegde

Such a simple choice, obvious in retrospect, right? Going all the way back to 2014, so I know you spent, two years before you actually launched the product and had a GA moment. I'm curious if you go back to that when you first started building.

One, how much surface area did you feel like you have to build before you could say, especially given the value prop is all in one? What was the foundational set of use cases that aligned to that all in one value prop that you felt like, okay, we are ready to have, people outside the team start using this, what was like the alpha, private beta stage like for Coda?

Shishir Mehrotra

Yeah. Actually, just to clarify timeline, we actually didn't launch Coda 1. 0 until 2019. So it's about four and a half years in is when we launched Coda 1. 0. We launched a lot of things along the way. We did three, what we called alphas. And then we did a large beta in 2017, where we started pulling in more people.

But the official first release was in 2019, which sounds like a long time, but it was... One of my primary investors is Reid Hoffman, and he has a well worn saying on if you're not embarrassed when you launch, then you launched too late. I'll go back to the beginning. So we started the company and we made a bunch of cultural decisions early on.

 We made a decision that we'd be a distributed team, which was not not as in vogue then as it is now. But it turned out to be very important for us. But one of the other decisions we made is that we would operate in stealth which is not a thing I recommend to most companies. With most companies, it's better to do your development in public.But in our case, it made sense for a whole bunch of different reasons. Is that the we knew the timeline for a true launch was going to be a long time, so doing that all out in the open would be hard. We also didn't have, like usually, you need to be out in public in order to recruit customers, so we didn't need that.

It was like, Coda is fundamentally a product that basically any team can use. So it just wasn't that necessary to need any of that. We had our own networks for recruiting and fundraising. And so we decided to do it in stealth, which meant that... We controlled the first few releases of customers that we worked with.

The first one but we thought, even though we were in stealth, it was very important for us to get customer feedback as early as possible. Even though we didn't launch 1. 0 for four and a half years, We launched our very first alpha in about six months. We had our sort of first version out there.

And it went to this company called SpringFul. There was only one customer in this first alpha. So this company called SpringFul was run by a guy named Noam Lovinsky who is now the Chief Product Officer at Grammarly. And he had um, they were similarly sized. We were both six people, we both had six people in each of our companies.

And we were now using Coda regularly to run things inside of, Krypton at the time, to run things inside of our company. And so I called him up and said, Hey, would you mind giving it a try? I have thick skin, any feedback is fine, but I'd really love to see how you guys use it, what you use it for, and so on.

And It's interesting early on it took pretty well. They were in the product every day. And we had our usage chart basically stopped at six. It was like, the highest we could get on any given day was six users. And so we'd watch this chart every day. Okay, we hit six users. And now we can go on to the next day.

And one day this chart drops to zero. And it was interesting because at first we're like, ah, it's okay. It must be they're doing something else. And second day it stayed at zero. And I call up Noam and I said, Hey we noticed that this, that your usage tailed off a bit. Are did you guys take a vacation?

Are you doing an offsite? I just wanted to check if everything's okay. And he said, yeah, I've been avoiding calling you. And he said, I have good news and bad news. I said, okay, give me the bad news first. He says the bad news is we had a team meeting and the team told me that if I made them keep using Krypton, they were all going to quit.I was like that's pretty bad news. I don't know how to recover from that. So what's the good news? He said the good news is we really believe in your vision. And the team made a list of these are the very specific things we need. And once these are achieved, we'll be happy to start again.

And, if you can do them in two weeks, we'll start in two weeks. If it's two months, we'll do two months. If it's two years, we'll,do it in two years. But just tell us when you're ready, and here's the list of things. There are about 30 things on that list. And it was an interesting moment in lots of ways. It was a total gift, right? It was a terrible experience, losing 100 percent of your user base in one day. It’s like one of those days you go home and question what you're doing. The level of feedback was really good. All the ideas on the list were really good.

And the sort of belief in the vision was really good. And so that was what this first one looked like. Interestingly, we did not build those 30 things. And there was a lot of pressure to. There, was a lot of discussion about like I said, the word gift, it felt like a gift. It's like this really thoughtful product team has given us a roadmap. We'll just do these things. But what we knew was that they were being exposed to this tiny part of the product. At the time, Coda was mostly about tables. So we actually built the structured part of Coda first. The heart of the Coda engine is a structured database.

And we hadn't built the rest of the product. There was no document, there was no forms and layouts, there was no equivalent of applications and presentations and so on. And we knew that if we overfit at this period, we would miss what the real mark of the product was. So it's interesting, I've watched that list carefully, and it probably took us all of the next two or three years before we actually made it through  Noam's team's list, because we were busy building out the rest of what we were trying to get built. I'd say in terms of and maybe answer a little bit of your question on surface area. Coda is a particularly challenging product that way. It is a product where because the promise is an all in one product, you have to meet this minimum bar. And because the things we're replacing are so familiar, you have this interesting challenge at every step. One of our four main values of the company is right versus familiar. And I think we've become very good at taking something and saying are we going to do it the exact same way or different? When are we going to purposely pick different? How are we going to educate people on that? And so it meant like every piece of design had to be very carefully thought out. And what it led to was it almost feels like when you're building Coda, it feels like I make the analogy to it feels like playing music, where if you miss a couple notes, everything kind of feels wrong.If you just miss one or two notes in the middle, the whole thing just doesn't feel quite accurate. And that's what it felt like. It felt like we were building this product and it was like 99 percent of it works. But this one thing, the cursor doesn't behave the right way in this one situation. Or, the page lays out a little bit funny in this one case. Or, whatever it might be would just make the whole thing feel wrong and people would give up and so you'd have to go back to it. And so that's what took a long time. It took a long time to both build up to those fundamental expectations and build the innovation we're going to build and get them to match and get them to feel like one, one cohesive product, and I wouldn't say we had that feel of product market fit until probably after our first beta.

So it's probably three and a half years in when, and for us, the definition was very simple. It was we feel product market fit when the product spreads. Because it's a team based product. You know that you're finding fit when you see the product spread, not only through one team, but when somebody from that team picks it up into another team and you see the product spread that way. And so we started seeing that happen then. And that was really what sort of made us start feeling like, okay, that's, we're really onto something. But it was a hard period leading up to it.

‍

Net Promoter Scores versus Disappointment Scores

‍

Sandhya Hegde

Yeah. No, I think the beautiful thing about what you said there that translates to any product, even if it's not a collaboration based product is that the heart of having found PMF is your customer is your evangelist as opposed to we set out to do this workflow and we have done it.

And there are some people now using us for this workflow. That's not quite enough, right? Like you need evangelism. In your case, you need evangelism for the product to be used at all, right? Because it's a bottom up product led collaboration platform. But even if that were not the case, like the best indicator that you have product market fit, I think it's not so much like what's being clicked on in a survey, but how much your existing customers are trying to tell other people about the experience they had.

Shishir Mehrotra

For your listeners who are interested in learning more on this topic, there's actually a really thoughtful template on this in our gallery. So Rahul Vohra, who is the founder of Superhuman the the email application, he ended up writing this piece, I really liked and Rahul and I have known each other for years.

And so we went back and forth on it, and it has this really simple idea that you can measure product market fit through something called a disappointment score. And it's a very simple idea is that you ask your users how disappointed would you be if you could no longer use... the product and basically the benchmark, you can say very disappointed, somewhat disappointed or not disappointed in the benchmark is that I believe he puts a benchmark at 40%.

If you get to 40 percent of your audience saying very disappointed, then you've achieved product market fit. The interesting thing about it is we would have all these debates about the other alternative way people think about product market fit is generally doing a Net Promoter Score, which is really an advocacy score. How likely are you to recommend the product? And it's interesting. Superhuman is a couple of years older than us. But we both came to market in similar ways, both started in stealth, both gradually worked up to our big first release. And interestingly, his product Superhuman and Coda had nearly opposite challenges. We had, even from the start, we had really high disappointment scores, but initially low Net Promoter Scores.. And his was the opposite. They had really high Net Promoter Scores, but really low disappointment scores. And you can think about why, right?

For Superhuman,  the alternative, if you ask somebody how disappointed would you be if you couldn't use Superhuman, the alternative is Gmail. And it wasn't like, you'd be pretty disappointed. I'm a big Superhuman user. I really love Superhuman. But there's an alternative product that you can switch to and so on.

But on the other hand people were very quick to say I would totally recommend it. I think it's really good. For us, it was the other way around. It was that the disappointment scores were sky high. Because once you start using Coda, you really can't use anything else. Our approach is so unique relative to any other product, you'd have to use 10 products to replace it. It's very hard to for people to go back. But on the other hand, it requires change management. It's a different way of working. And so people would say, would I recommend this? If you're up for the challenge to go and change how your team works, then absolutely I recommend it. How disappointed would you be if you couldn't use it anymore? Most of our customers would say devastating. Like  we have incredibly low churn as a company because, it's very hard. Once you see the world in the Coda way, like it's very hard to see it any other way. And it's an interesting way to think about product market fit.

I had this really interesting conversation with the the inventor of Net Promoter Score from Bain and we were talking about this dynamic, and it's very interesting because what he was saying is, so I didn't know Net Promoter Score was an invented thing, but they've invented it, built a whole practice around it and they do all these studies for people. And I mentioned this idea that, you know, which is better Net Promoter Score or Disappointment Score. And what he said was really interesting. He said he thinks it's an indication of maturity of market. So the more mature your market is, the more you need net promoter score. And the reason is simple.

The more mature your market is, the more likely it is that the products are similar. And so if you go ask in the car market, for example, for disappointment scores for Mercedes, people will say, how disappointed would you be if you couldn't have a Mercedes? They'd say, I'll be disappointed, but like BMW is like right next door.

And I'll figure it out. But you'll still get high net promoter scores. People will say, I love my Mercedes, I'd be happy to recommend it. And the view is that as goods become more and more equivalent, Net Promoter Score becomes more important. But I think actually in early days, one of the reasons disappointment score is such a great signal is because your product is likely to be quite differentiated.

So your first indicator may actually come out of disappointment scores before it comes out of net promoter scores. Maybe just, for the science of product market fit. And there's a really good template Rahul built on how to do it. You can go find it in the Coda Gallery.

‍

Shishir Mehrotra's approach to product rituals

‍

Sandhya Hegde

And I think it's, highlights how important an understanding of human psychology is when you are trying to build something new. Which I think it's not something like as in VC or as a technical founder, often you think about a lot, like you don't, go out of your way to really understand human psychology and put words to it, but I think some of the best product people I know have this really great intuition for human psychology and understand outside of the problem their product solves, like, how does it affect your customers identity, their status, their, joy, their mental emotions, And, since you talk a lot about kind of product rituals, I wanted to maybe segue a little bit into that and circle back to the Coda journey, how do you help your product org , especially given that you started the company with such a clear, big, long term vision?

How do you help your product org kind of keep that DNA in the company as you get bigger and, you have more kind of product owners for different parts of the company. I'm curious how you think about that. Is there a specific playbook you are following that works for Coda or, have you had to make it up as you go?

Shishir Mehrotra

So I think as although some of your listeners may know, this is a topic that I really enjoy and become a student of. I'm actually writing a book on this called Rituals of Great Teams. And people want to read. I've been publishing a chapter at a time at ritualsofgreatteams. com. So you can go take a look.

And it's a fairly simple idea that as we form our teams we build two products as a company. We build one for our customers. We build one for our employees. The one we build for our employees, we call that culture. And if you ask somebody to define culture, they will often describe it in terms of rituals. These are things we do, these are ways we do things. But they're actually kind of mirrors. That way we operate isn't just an operating system. It's a mirror of our culture. So this second product we built, the product to build the product is one that I've become a big student of.

And obviously it's very relevant to Coda because Coda becomes a tool for people's rituals quite commonly. And so every team has different rituals. For this book I've now interviewed over a thousand different companies. I picked out a hundred top rituals, and I put them in these buckets together. And so you can go learn about everything from how people do strategy and planning, how they do decision making, how they run meetings, how they onboard employees, how they hire employees,there's all sorts of different things that people do to build and manage a culture. For us, I think there are a few things that are maybe somewhat unique to us, and based on the type of product we're building. And, maybe I'll just give a couple different examples. One is our decision making culture. And it just turns out that when you're building a product like Coda to use a term that Jeff Bezos made pretty famous, We have a lot more one way doors than two way doors.

There's just a lot of cases of when we're building something where this wasn't as true at YouTube. At YouTube, there was definitely a lot of one way doors, mostly because it's a marketplace and an ecosystem, so once people depend on you one way, it's hard to change. But overall, that market changes fast enough that you could make a decision and you could change it. In Coda, it's just harder. People get used to it a certain way, the docs get built a certain way, it's hard to go change, change things out. Not impossible, but harder. And so it's important that you get choices right in the first place.

 We've put a lot of attention to our decision making processes. Yeah, there's a couple different things we do that are unique there. And then I'll tell you about an innovation ritual as well that I think is interesting. Probably the most important thing is that in our core decision making we do a thing called Dory and Pulse.

It's rare to have a decision making or basically any meeting at Coda and not have what we call Dory and Pulse. Usually in most cultures, you would have a write up or a slide deck or so on, people would add comments to it, and then you'd run through the comments or maybe you'd just let somebody present the slides and you'd blurt out questions, and you'd use that as a way to try to drive decisions in a Socratic kind of method. I was at a dinner with a set of founders and one of them mentioned that it feels like the most important decisions in our company are made in the bright hundred pixels of a Google Doc, like that can't possibly be the best way to do it.

And so what we do at Coda is it's called Dory and Pulse. At the bottom of every write up there's a Dory, which is a place where everybody asks questions and you vote them up and down. It's named after the fish who asks all the questions. And that's a way to make sure we get everybody's questions out. Focus on the most important ones. And then the most important thing we do is a thing called Pulse, where everybody is supposed to write their response to the write up. So you say, hey, we need to make a decision. Are we doing it this way or that way? Are we going to hire this person? Are we going to buy this company? Are we going to launch this product? Whatever it might be. And everybody writes their viewpoint, often with a score, saying, I agree one I agree five, or I disagree one, or whatever it might be. And the way we do it is we hide everybody else's responses until you're done writing. And so we try to remove the groupthink of this process.

And that turns out to be really critical for making good decisions. Because I think in most cases, decision making cultures are built around the loudest voice. And so the loudest voice or the most senior voice or so on. And it's not to say that like my voice doesn't matter, but the best ideas in the company often don't come from me. And so if you're building a company with a lot of critical decisions, which I think actually ends up being most companies, I think having a clear decision making process is really important.

So that's one, one ritual I'd say. The other one is totally different extreme is how we do hackathons. And maybe there's a little bit of a story there. At YouTube, we used to do something called Innovation Week. So we would take a week, a year, and we would do a hackathon. And, actually we used to do it twice a year, and then gradually we turned it into once a year, and eventually I killed the whole thing.And the reason was, it actually turned out to be perversely bad for the team, and we would do these hackathons of these Innovation Weeks. And inevitably, some team would pick up a project that they were trying to get some other team to do say, Hey, you guy,. Don't you know aren't doing this thing or you think it's a bad idea.

Let me just show you. I'm just gonna build it, I get a week to build it and you know that I'm gonna convince you right? Actually vertical video was one was a was one of the projects done in one of these things So it's back to the very start of our conversation with the but we get to the end of the week. I represent their ideas and you have all this fighting It's wait, we told you that's a bad idea. We own that piece of code. We think that's a bad idea. Here's why. We're not shipping your thing. And because the whole thing was built around that, it all felt like a failure. And so we started doing these less and less.

And so at Coda, we were a few months in, and one of the engineers who came from Facebook, he said hey, we should do a hackathon. And I said, I don't know. I gave him the stories. I don't actually think it's that positive. And he says, oh, that's silly. That's just misconstructed hackathon. He said, I have an idea.

Let's do it as an anti hackathon. I said, what does that mean? And he says let's set a simple rule. We're going to do a hackathon, but you're not allowed to ship anything we make. And it's going to be the first anti ship, anti hackathon. I was like, okay we'll give it a try. We do it three or four times a year now. And I'd say, easily 75 percent of the best ideas in Coda have come out of hackathon. The vast majority of them shipped months or years after that first hackathon. And so one of our values here is great ideas take time to grow.

And it's when you're building something like Coda, it's really important you get all the little elements of something right. I think it's really critical that you build into your culture, space for an idea to form. And, the initial one may not be that great. One of my favorite examples is Coda has a feature called Buttons which went through I think 5 hackathons before it turned into a shippable feature. And, only in hackathon three did we even come up with the name Button. Which seems like really obvious in retrospect. We had all sorts of other crazy ways to describe this thing we were trying to do that takes action from a doc and it could send an email or it could create a row somewhere or it could create an order or an invoice or so on.

And at some point somebody sais, normal people say if I press this thing and it does exactly what action, we call that a button. Why don't we call it a button and work backwards? But it was like Hackathon the third time we went after it that we actually got to that, and it was the fifth time before we could ship it.

I think there's a lot of great ideas like that take time, but those are a couple of the rituals that being really good at decision making in the moment is really critical, but also giving space for open ended innovation without the pressure of just needing to immediately present it to customers, I think has become a key part of how we operate.

‍

The launch of Coda 4.0 and leveraging AI

‍

Sandhya Hegde

So you just also launched Coda 4. 0. Congratulations. I'm curious, obviously, there must have been a lot of conversation about how to incorporate AI and LLM over the past couple years, I'm very curious, what was that process like at Coda? And what was your original thesis around the right way to leverage AI for your customer base and, curious whether it's playing out the way you thought it would.

Shishir Mehrotra

Yeah, it's interesting we caught the AI bug similar to everyone else in a slightly different way. About a year ago now, November of 22, somebody shipped a OpenAI pack in Coda. One of the unique things about Coda is that anybody can build an extension of Coda, we call those packs.

The vast majority of them are used for integrations between Coda and some other system. At this point there's about 600 of them that have been developed by the community and shipped out to the world. There's thousands more that have been built inside companies as well, because you can build it for private use as well.

So anyway, somebody built a pack for OpenAI and turned it into a set of function calls that you could then use as building blocks in Coda and, put them in a table or put it in the Coda canvas or so on and go and ask AI to do anything for you. It immediately became the number one most used pack in Coda.

This is before ChatGPT shipped. This is before most people had realized how powerful the LLM models that we're about to see really were. And honestly caught us a little bit by surprise too. At the time AI felt like a important thing, but not the important thing. But we saw the excitement, I set aside a team to go work specifically on AI and they started working away and finding what are the right ways to blend this into the product and make it really feel like a core building block of Coda. And we started getting feedback on what people did with it.

And we learned something. It was pretty interesting. I think the, first of all, everyone's impression of AI quickly got shaped by ChatGPT. It just felt like such a magically different experience. I've been working on AI for almost 30 years now. And YouTube was run by hundreds of AI systems. But the idea of taking these AI systems and making 'em feel human, something we can chat with, just felt really different, felt really new. But there were a few things that clearly ChatGPT couldn't do.ChatGPT felt like this person who had read the entire internet, and was like this encyclopedia of knowledge and you could ask anything of this sort of hypothetical person but as people thought about it coming to the workplace, there were a few expectations that were not met there.

Probably the most important of which was, you expect this thing to not only have read the internet, you expect it to have read your actual data. What's happening in your company. You also expect it to be present in your work surface. It being a place you go and then come back to wasn't really the experience people wanted.We were watching people, copy and paste out of Coda and ChatGPT and back, and that didn't seem quite right. But probably the most, and probably the most important thing is I want this thing to actually produce productivity for me. I want it to not just answer questions, I want it to do stuff for me.

And it turned out that all of those led to Coda. In terms of understanding your work, we have, at this point, one of the most connected document services on the planet. So over 600 different integrations, everything from Salesforce to Slack to Figma to Miro to Jira to, all sorts of different products that you can blend into your Coda experience. Which turns out to be, from an AI perspective, incredibly useful. Because this now knows everything about about about your work. We're also a heavily engaged service. Our average users are active five out of seven days a week in Coda. And finally we're an action engine. And, because you can use buttons and automations and so on in Coda, I think last year we did four billion tasks. We automated four billion tasks for our users. So there's a lot of scale that can be applied to it. And so we basically built our AI system, what we launched with Coda 4. 0, with those insights in mind. It's a, first off, it's a knowledge assistant. It looks and feels like ChatGPT in your doc, but it happens to understand everything about your work.

So you can go ask a question about your calendar, about your orders, about your email, and it'll actually respond to you with things that are permission aware and specific to you. Secondly, it's a writing assistant, so as you're working, it's sitting next to you. It can go finish your sentences, it can go and correct your grammar. One of the favorite uses we see is you do a page of write up, and you can just say, go correct it, and it'll go and act like a collaborator, and go add comments and suggest changes. And then finally it's a task assistant and we basically built it into every building block so you can go and build AI powered buttons and AI powered automations and so on.

And you can go and have this thing actually do things for you at scale. So as an example, I was talking to a customer that took Coda and uses it to rebuild his entire CRM system in Coda. Leads come into this table, they get scored by AI, he goes through and triages them. Then AI goes and writes a draft reach out email to each person. He can go and edit that. Then a button gets hit that gets automatically triggered and goes and sends it out to everybody. The responses get cataloged. Every step of this is some mix of... traditional Coda building block, AI building block, Coda building block, AI building block, and that blend together leads to a really powerful experience.

‍

Shishir Mehrotra's advice for founder in enterprise productivity

‍

Sandhya Hegde

And I'm curious what would be your advice for new startup founders just getting started in this broad enterprise productivity space? What are your takeaways on how to figure out if you have picked a good problem to work on? What's the right framework to think about it?

Because I feel enterprise productivity is an unlimited canvas, lots of opportunity because the way we work is so painful with so many inefficiencies. And yet, it's very daunting. What you've done with Coda is just so impressive and took, so much in resources and knowledge and thought to be able to just get something right into the market.

So I'm curious, what would be your advice to founders thinking about opportunities in enterprise productivity today, especially with the new opportunities made available by AI?

Shishir Mehrotra

It's this thing I'd say we talked a little bit about earlier is I think great companies are built on really simple insights. And so think about your observation, hone it really down to this is what we think is the assumption that everybody else has made that we view slightly differently. And then you got to go and look at that as hard as you can and say, how true is this? Oftentimes people ask the question, is it a feature? Is it a product? Like, why have people not done that? And when you can, especially when we were starting Coda, people would first say, why do you want to build Office, Google Docs, doesn't seem like there's anything wrong. And and I'd say no, we think there's a better way. And they'd say, oh, and then they'd rattle off their ideas. And the number of times I got suggestions on oh, yeah, you're right. I really wish somebody built Office that had different line spacing. Or used this font that I didn't, I don't have access to. I don't think you can build a business around that. I think if Microsoft hasn't done that yet... It's probably just a matter of time and you can't really go and build a whole new product on that.

So you got to go take your insight and say, first off, is it true? If it's not true, you've got a big problem. And then what has the barrier been? What has kept people from being able to do this? In our case, I think the biggest barrier to innovation in the document space was file format. Again, it turned out that if you go look at the history of documents, I think the best innovator in especially late 90s, early 2000s, it was actually Apple.

They built Numbers, Pages, and Keynote. And all three were fundamentally a little bit different from Word, Excel, and PowerPoint. And none of them really took off. And the reason was really simple. If I built something in Numbers, or in Keynote, or so on, and I send it to a friend, they have to have... Numbers, Keynote, and so on. They had to have a Mac, which at the time wasn't that popular. And it just meant that these products couldn't survive. You needed this incredible network effect. And file formats turned out to be a real lock in. And so even when Google Docs shipped, being able to export and import from Word, Excel, and PowerPoint was really important.

And interestingly, I think, has completely changed. In a world of web based tools, and, there is no client, there's no download, you don't need any of that anymore, and so it gives us an opportunity to innovate. And so in my mind, why has this market not changed? And to come up with my insight, I think that the line between docs and apps is artificial, and you have to think about the barrier, like what has kept that from happening? It’s very rare that an insight is really important and nobody's thought of it. So you have to think about what is that structural thing that kept this from happening?

And then you can go after it. And in some cases, the structural thing is not that big a deal, and you better move really fast, before everybody else figures it out. In some cases, it's a really big deal, and you better be right. I think our case was the latter. It was hard to do was part of the reason. Yeah, sometimes it's a scientific breakthrough. Sometimes  there's lots of reasons why something hasn't happened yet. But I would say, generally starts with a really simple insight. And then it grows from there.

‍

​

‍