Ep. #33, Innovation Stories with Shishir Mehrotra of Coda

Grant Miller: All right Shishir, thanks so much for joining.

Shishir Mehrotra: Thanks for having me Grant.

Grant: Let's jump right in. Tell us a bit about your background. Sort of how you got into building software.

Shishir: Sure. Let's see. I'll do it going backward. So I'm currently the CEO and co-founder of Coda.

It's a new type of document. All in one document, blends the best parts of documents, spreadsheets, applications into one new surface.

So anyone can build a doc as powerful as an app. I'm presuming we'll end up talking more about Coda later.

Before that I spent about six years at Google. I was amongst other things, responsible for the YouTube products.

You know, I joined YouTube in 2008, pretty soon after the acquisition and helped grow it from, you know, an emerging community into a pretty big business.

Before that I spent about six years at Microsoft, I worked on Office, then Windows, then SQL Server.

And before that I started a company called Centrata. My first startup. That was in the dot com boom.

It was a utility computing company. And before that I was in school. I went to college at MIT.

I grew up mostly in Virginia, although we moved around a bit and that's me.

Grant: Awesome. Okay. So let's kind of dive into the beginning. So you studied, I guess maybe computer science?

Shishir: Yeah, it's interesting.

I went to MIT and I studied computer science and math, which I guess is its own interesting story because the, both my parents are computer scientists.

My dad works at NASA. He's worked at NASA for 30 years now and runs the supercomputing division there.

And my mom runs a consulting firm focused on mostly government work as well, but both are computer scientists.

And so when I went to college, I told my dad that, "Hey, I think I'm going to major in computer science."

And he told me I couldn't. And I was kind of surprised because you know, why not?

I mean, you guys are computer scientists. I was, I thought you'd be proud. Like I get to do what you guys do.

And he said, he's not paying for college unless I majored in something where the books are at least 50 years old.

That was his viewpoint. And his viewpoint was computer science to him felt like a vocation.

Like you sort of, everything changes by the time you graduated. And so the education isn't worth as much.

And so I ended up double majoring in computer science and math and in his head, I think I was a math major that happened to do computer science.

And it was definitely true. My math books were mostly more than 50 years old.

Grant: Funny. That's an interesting framework that I hadn't thought about for choosing a major.

Age of the knowledge. Okay. So then you came out of college and straight into founding a software company?

Shishir: Yeah, I mean, again, sort of by mistake, which is, I think how a lot of startups get started.

I was talking with a friend of mine, David Ratacheck, who was my co-founder for Centrata, and he and I were finishing up college and we both finished a little bit early and we're getting recruited for a bunch of jobs.

And neither of us were really that excited about any of the jobs we saw.

And so David convinced me, he said, "Well, why don't we stick around and do grad school?"

And we managed to convince MIT to let us do a joint thesis, which was not very typical at the time.

And so we started working on this project together and MIT has this entrepreneurship competition, that is now called the 100K competition, at the time it was called the 50K competition.

I guess that's 20 years of inflation. And David convinced me, he says, "We should just take this idea "and write a business plan around it and put it in "and see what people think."

And it wasn't our primary focus when we were sort of working on this as a thesis.

And we ended up doing better on this business plan competition than we expected.

We came in second and attracted a bunch of investors and Vinod Khosla over at Kleiner Perkins, ended up doing the round.

And before we knew it, we were, you know, we quit grad school and we started this company.

Grant: And what was the company doing? And how did Vinod get involved?

Shishir: The Vinod story is quite funny actually.

What the company was doing is, in today's terms, you would call it a utility computing company.

I think the whole category got branded multiple times through that period and over the course of the last two decades, but the original vision was let people buy computing.

You know, like you buy any utility. Buy as much as you need.

And these days I think it would be more comparable to what people do with AWS and Azure and so on.

The company, and we can talk more about Centrata in a bit, but we were basically five years too early. It was, at the time there was no virtual machines.

There was no containers, none of that stuff existed. And the company had an okay path, but it's an interesting lesson in market timing.

But we had written this graduate thesis on how to handle distributed data in an un-trusted topology.

Our professor was one of the early professors for Akamai.

So it was built on very similar ideas to what made Akamai work in those early days.

If you remember content delivery networks were really hot at the time. So that's what we did.

I can maybe talk a little bit more about what we ended up doing with the company in a bit. The Vinod story is fun.

Basically we're building up this company and you know, this is my first company. We're pretty young.

Don't really know much about starting companies. So, you know, the market is fairly hot for startups. This was 1999.

Grant: I heard that was a good time to start companies.

Shishir: Yeah. Although, I mean, I don't remember it.

I think nowadays we look back and it's like, everybody pictures like gunslingers.

Like everybody's like, "Ah, start a company." Like I don't remember it like that when we were in the moment.

Like, I think, it almost, it had to like collapse before it felt like that.

And also we were in Boston and there wasn't as much of like a fever pitch as there was, I think in Silicon Valley.

So we're starting this thing up and we do well in this competition.

And we get enough interest from venture capitalists that we say, "Oh, maybe we should start this thing."

And we start having these meetings and so on. And the competition was kind of a high point because the venture capitalists were, all of them were willing to kick the tires, but nobody was really willing to commit.

And so we're like four or five months in to trying to raise money for this thing.

And we have a couple of angels that are committed and we have this group of investors that like had this really terrible term sheet for us that we really didn't want to take.

And then I get this email out of the blue from Vinod Khosla.

And for people who know Vinod, one of his hallmarks, and this is still true today is he sends these emails that are usually incredibly short and full of misspellings and very to the point.

And he says, "I read your paper. I think it's great. "I'd like to fund the company, call me."

And, you know, with five misspellings in the middle of what I'd probably said was like 20 words.

And so I'm looking at this thing, and this is going to sound dumb, but I had no idea who Vinod Khosla was.

And so I call up one of the three of these angels that were semi committed to the round.

And so I called one of the angels and this was someone who had committed to putting $500,000 into the company.

And he'd committed like a month earlier, but he hadn't wired the money.

And so I call him up and I say, "Hey, I got this email. "Like, I don't know, is this a joke? Like, is this real?"

And this angel says, "You don't know who Vinod Khosla is?" And I say, "I don't know. Not really."

Again, remember no LinkedIn, no Wikipedia. Like none of that stuff exists.

Right? So there's no like, go just look it up and no Crunchbase.

And so he says to me, "Why don't you walk down to the student center "and go to the bookstore."

This bookstore still existed. "And go to the magazine rack. "See the guy that's on every cover of every magazine. "That's Vinod Khosla."

Because that's basically what he was at the time. He was on every cover of every magazine.

And so I go read a little bit about him and come back to my dorm room and my "CFO", who is just, you know, one of my college classmates lived down the hall from me.

I go and I tell him and I'm pretty excited.

I'm like, "I think this email is real. "Like I think this guy wants to fund the company."

And you know, we should get on a plane to California "and go figure it out." And he's like, "It's funny you mention it "because we just got a $500,000 wire into our bank account.

"Where did that come from?" It's an interesting lesson in how fundraising really works. But yeah, that's how we started with Vinod.

Grant: Yeah. That's amazing. Someone commits, waits until there's a lot more signal, then, oh, we've got to get this money in before round goes up.

That's amazing. So, and then, you know, talk more about the company.

Were you selling to enterprises? Who were you like targeting? What happened to the company?

Shishir: So the, like I said, this category got renamed multiple times and early on it was called peer-to-peer computing.

'Cause it was, the idea was, is a form of distributed computing, but it was, there was no centralization.

That was a hot label given to Akamai at the time. And so that was being used by all these companies.

And, you know, a bunch of companies emerged at the same time.

This often happens in a category is, I don't know quite how this happens, but I got this email actually, when we won this or we came in second in this business plan competition, you know, we're all excited.

You know, we have some celebration dinner and so on.

And the next day I wake up and I have this email in my inbox that says welcome to the party.

And it had a list of 30 companies that were doing, you know, in the same space and I had never heard of, right?

And so this was pretty high. I mean, probably for your listeners, probably the most memorable company of that set was LoudCloud, which became Opsware.

That was Mark Andreessen and Ben Horowitz's company. So that's probably our most direct competitor.

And everybody started off with a sort of similar viewpoint of, you know, some way to make computing resources feel more like a drip utility.

What happened to basically every company, including ours, was a quick discovery that the infrastructure wasn't quite ready for it.

And what was really needed was a bunch of automation tooling.

And so before we could do things like our fancy algorithms for distributing data across large sets of machines.

Kind of like very similar, in some sense as to what ended up being built with S3 and at Google was called GFS.

And that was kind of the underlying idea. That ended up being mostly irrelevant.

And we ended up building basically enterprise software for large data centers.

And, you know, so for example, our first big client was Quest Communications.

People may not remember this but AT&T had gotten broken up in the different parts.

It's since been mostly put back together, but basically Quest was AT&T of the Southwest.

And they were launching a data center utility service where you would call them up and say, "Hey, I need this many machines and this much, "this much storage," and so on.

And they would just provision it for you. You know, that sort of similar to what you do with AWS and Swan today.

But at the time what would happen behind the scenes there is that those were physical machines.

Like somebody would go find a rack, put machines into it, install network cards, write down Mac addresses and assign IPS and send you back a set of IPS for you to use.

And that's what utility computing was at the time. And so we built software to manage that.

And it was basically a big enterprise application.

Most similar these days to ticketing applications that manage an order to host process, order to provision process.

I forget exactly what term Quest used for it, but that's what we built. And that was our first client.

Grant: Oh, funny. So it wasn't even something that actually like, did this really automatically.

It just like you put some process around the manual process of doing this, right?

Shishir: It's, so I, my first meeting with the Quest CIO, so a guy named Chris Coles.

And I meet with Chris and I'm pitching him, this, all this stuff, and we've got this thesis and look, I've got this data distribution algorithm and here's how fast it is and how reliable it is.

And it can tolerate, you know, 40% of the nodes going down and not lose any data.

And it's like all these geeky grad school stuff that we're talking about. I asked him a question. I said, " What do you think your utilization "of your machines and storage inside your data centers are?"

And he says, "You're asking me the wrong question."

And I said, "Okay, well, you're the customer. "So what's the right question?"

And he says, "Ask me how many machines "are in my data center?" And I said, "Okay, how many machines are your data center?"

And he says, "I have no idea."

And it took me, I mean, this deal took a while to get closed, but it was the stone ages of this.

We completely take for granted now. And he proceeds to tell me about their situation and says, "Look, I'm totally excited about your vision. "And I'm happy to help you get through that. "And it's going to take years, but I got to tell you, "I got some blocking and tackling to do first. "And before you can automate anything, "and before you can do redistribution of computing and data "and so on, you just have to handle "the provisioning process." And they actually had an RFP for it going out. A request for proposal. And he said, "Why don't you just bid in the RFP? "And if you win, then you can go solve this problem with us. "And if you partner with us, "you can solve the mundane problem "and then get around to the thing you really want to do." Which never really happened. But well, we did solve the mundane problem for them, which was exciting. But yeah, that was the state of the industry at the time.

Grant: And how big was that deal?

Shishir: You have a lot of listeners that know enterprise software, so the size of the deal.

So it was $12 million, and there's a little bit of fun story there as well.

So if your first deal at a startup is $12 million, there's some really awesome things that happen.

And there's some really bad things that happen. And maybe I'll get to that in a second.

But the way we came up with that price was also kind of hilarious.

So they put us in this RFP and we're this tiny startup.

We have 20 people, we're building up this product that is like mostly irrelevant to their needs.

So from their perspective, we have nothing. But we're responding to this RFP.

And it's, you know, this is a hundred page response and there's a bunch of demos and bunch of meetings to show prototypes and so on.

And somehow we get shortlisted. There's like 30 companies that apply for this RFP. We get shortlisted with five companies.

And what the next phase was called a request for quote, or RFQ. Very formal process that they were running.

And I just ask them, I say, "Who else is in the RFQ process?"

And we do a little bit of back channeling. It turns out the other people were HP, Oracle, IBM and KPMG and us.

Like this tiny, tiny, tiny startup against these huge companies.

So we discuss it and say, "Okay, well, let's do it. I mean, we're going to be differentiated. We look pretty different than everyone else."

And so we go through the process and at some moment in the RFQ process, there's a little box that says price.

Like, what is the charge for the product? And I have this advisor, this guy, Mike DeCaesar.

He ran sales for a company called the Sera, that we were partnered with at the time.

But previously he was one of the head sales guys at Oracle.

He later went on to, he ran Documentum and so on and a really good enterprise sales guy.

And so Mike is my advisor in this.

So I go to Mike and we're kind of working through this contract together and I say, "All right, well, they want a price."

"Well, I think it's going to take us, you know, X number of engineers to build this thing and this is how long.

You know, I think it's going to take like a million bucks to an investment to build the thing they want. So how about I like mark that up two X and I put $2 million into this?"

And Mike looks over at me, he says, "Shirshir, you cannot put $2 million in that box."

I said, "Why not?" Then he says, "Just trust me, write $30 million."

I said, "$30 million? Like, what kind of like crazy margin is that? Like, I own the software at the end of this thing, right?

I mean, there's no like, they just pay for the development. That seems like an egregious price."

And he says, "Just trust me. If you put $2 million, you will not be taken seriously."

So I write down $30 million and then we proceed and we have a series of meetings in Denver.

And the meetings are like out of a movie. Like this big, long table. They sit at one end with their lawyers.

We sit at the other end with our lawyers and we negotiate back and forth and we have these little breakout rooms.

And it literally out of a movie. It's quite funny. And, you know, Mike came along and negotiated with me and we start at 30 million and they gradually whittle this down to $12 million. And, you know, we shake hands and agree.

And then we have a celebration dinner. And I was just talking to one of the people on the Quest side and I said, "So tell me a little bit more about what happened."

He said, "Well, you're not going to believe it, but there were five criteria for picking a vendor and you guys nailed four to the five.

And like everything about the product service, you guys nailed it. The thing that you guys were lacking on was price. You were the highest price out of the five bids.

And we decided that if we could get your price down to anywhere close to any of the other bids, then we would do the deal.

Because you got down to 12 million, thank you so much for getting down to 12 million. We were able to do the deal."

It's just such a great lesson in pricing.

Grant: That's amazing. Also just you made it, you were the highest. Like I wouldn't have thought that you would have been in the highest of that bid, but I guess--

Shishir: Yeah, I mean, this is, I mean, Mike had a pulse for it, which, and pricing, is really hard.

I mean, and figuring out how to price products and so on is really hard.

And I mean, the thing I probably didn't know, and I didn't understand was for all those other four companies, they weren't really selling a product at all.

I mean, the reason we won was because we were the only one of the five that had any ambition of turning this into a product, which is from an enterprise perspective is a positive, right?

It means they're going to get the benefit of innovation that isn't just for them. So that's a positive thing.

But the thing I didn't understand was that in their mind, and it was $12 million of mostly software revenue.

And we booked very little of it as services revenue, but in their mind, they were really thinking they were signing up a consulting contract.

And one thing I think that many people don't recognize is if your first client is too big, it can cause a different type of issues for your company.

And so basically what happened was, you know, this was our first client, our next client was American Express.

That was a $3 million deal. We were less aggressive on the pricing there.

And, you know, we had a few other clients but those two were by far the biggest.

And you know, for most companies getting $12 million in your first year out from your first client is like crazy awesome.

But what happened in that, was because they paid us so much money, they effectively owned us and they might as well have been an investor.

'Cause they, anything they did, we had just had to jump and do it. I had an apartment in Denver because I was going back and forth so often.

I was literally going back and forth two days a week. I would sit in on their staff meetings, like, 'cause anything they needed, I had to be there.

Like when 9/11 happened, I was in Denver and I got stuck in Denver for a month.

And, worked out of there, kind of similar to the phase we're in right now for a different reason.

And so there's lots of pros and cons to that story, but I mean, it was super awesome, fun journey.

I learned a lot. Learned some positive lessons and some negative lessons too.

Grant: And then, what happened to the company?

Shishir: Yeah, so the company basically became a consulting company.

And there's a lot of these in in the SaaS world where the company is kind of a service company, kind of a product company.

And it's always a little hard to tell, but I often tell people, if you can't tell, you're probably a services company.

And not, there's nothing wrong with that. I mean, there's lots of great services companies out there, but it's different.

And I personally got quite bored. I just, you know, we started hiring people that were more of that consulting background and, you know, staffing people to accounts and so on.

And I basically decided to step aside.

So, in 2002, I went Vinod and I said, "Hey, I want to go do something else. I'm happy to continue helping the company."

He asked me to stay on the board, which I did for a number of years, but I want to go do something else.

And we had a good conversation about it, but eventually he agreed.

The company got sold a couple of times and you know, wash out investors after the second sale and eventually became an arm of a company called Otter.

And then I kind of lost track of it.

Grant: Oh, interesting. So it's sort of just like kind of kept going and I'm sure the software is still is inside of some of these organizations, right?

Shishir: Yeah. I have no idea. That's a good-- I hope not.

This is like, in this time, like when we sold software at the time, you sold it with hardware, right?

So you would expect the software and you would also sell a bunch of sun microsystem boxes to run the software.

The meta problem of this was very interesting, right? Because there was no hosting really at the time.

We were building software to enable other people to do hosting.

And so, you know, I don't think it can be running anywhere.

Because I don't think those machines are. I don't think anybody uses them anymore.

Grant: You'd be surprised. With some mission critical application that's on there. You know, something that's happened.

Shishir: Yeah. That's true. I guess your business is closer to that.

Grant: Yeah, we, there's a friend of mine that used to work for a company that sold to power companies.

And he said that one time they had to find the server where their software was running and they figured out by tracing the wires, that it was actually behind a wall.

They had built a wall, a brick wall between the server and the rest of the room at some point.

And so to take down the wall in order to get to the server, which had been running for like, you know, 25 years.

It's kind of wild, right? Okay, and then, so, and then you went to Microsoft and this is where you worked on, you know, a bunch of interesting enterprise products.

And so let's talk a little about, you know, why you went there and what your experience was and what you're working on there.

Shishir: Yeah. and it's actually relevant to Coda.

So maybe one more quick story about Centrata that I'll tease why I went to Microsoft, may not be obvious otherwise.

So, you know, we're building up Centrata and somewhere along that process, I asked one of my advisors, you can probably tell I had a network of great advisors and this guy, Peter and I asked Peter, "Hey, people keep using this term enterprise software. And I don't really know what that term means."

It's not really a, there's no class in college to teach you enterprise software. To my dad's point. There's no book that's 50 years old. So that's about enterprise software.

And so I said, "What is this term? What does it actually mean? And I'm kind of getting like out of context, I'm getting a sense of it, but what does it mean?"

And so he gave me two definitions of enterprise software.

And one was enterprise software is where you take a group of people, you watch their processes, you figure out what they do that is repeatable and you build software that kind of forces them to do that repeatable part over and over and over again the same way.

And it's a almost dystopian definition of enterprise software, but probably not an inaccurate one, of what a lot of enterprise software feels like.

His second definition was you take a group of people, you find the spreadsheet they're using to run themselves and you turn that spreadsheet into software.

And that definition rang very true for me. And I was a spreadsheet junkie already.

And I think I got much better at it over time, but I was already pretty good with the spreadsheet.

And as we were onboarding Quest, is their brick wall story is interesting.

They sort of similarly, when we onboarded Quest, there was like part of that process where it was like, "Okay, we're going to transition your systems."

And we went and said, "Okay, you know, "help us understand how you're doing it today."

And literally it was entirely spreadsheets and post it notes.

And the reason that, you know, Chris Cole had no idea how many machines were in the data center was it was spread out among these spreadsheets and post it notes.

And so this definition of enterprise software really rang true for me and everything we built at Centrata was basically trying to balance between being as flexible as a spreadsheet and being as structured and powerful and trustworthy as an application.

And so, okay, so I go to Vinod, 2002 and say, "I want to go do something else." And Vonid's first reply is, "No, please don't."

And we talk about it for awhile. And second, his reply is, "All right, if you're going to do that, at least do something in the Kleiner Perkins portfolio."

And Kleiner Perkins was the hottest venture capital firm in the Valley at the time.

And so he said, "Why don't you go look at our portfolio "and tell me what you'd be interested in."

And I said, "What do you recommend?"

And he said, "Well, you should go over and talk to these two Stanford guys. They're starting a company called Google and it looks like it's going really well. You should go talk to them."

And so I went over and talked to Larry and Sergei.

And interestingly, as you know, from the story, I ended up turning them down and they made me an offer to be their first outside product manager.

They just hired a guy named Jonathan Rosenberg to run product.

And they had converted a few PMs at the company, actually some famous ones.

The three PMs at the time where Susan Wojcicki, Salar Kamangar and Marissa Mayer.

And they wanted me to come in as their first outside hire product manager.

And I ended up turning them down, which my wife still calls my billion dollar mistake.

And the reason was I had this old boss when I'd been an intern at Microsoft in college, Microsoft was like the prize internship back in the late nineties.

And so I'd been an intern at Microsoft and my old boss had written me and said, "Hey, we're starting this project that I think you'd be really interested in. You should come to Microsoft."

And the project was called Gideon.

And the idea was to turn Office into a front end for business applications.

And that just felt so obvious to me. I had just gotten done with this whole journey on enterprise applications and this line between spreadsheets and apps and so on.

And this group was basically, it was five people, sort of cherry picked out of the Excel and Outlook teams.

And we were basically, we were ripping apart the Excel and Outlook code bases and turning it into a platform for building business apps.

And I was just so excited it. And I looked at Google and Google was all about, you know, search and advertising, neither of which I knew much about and was not excited about.

And honestly, I think I'm a better investor now, but I think I just underestimated the Google potential.

And so I went up to Microsoft to go work on this crazy project to turn Office into a front end for business applications.

Which in some ways people familiar with Coda is roughly the same insight that drives Coda.

I mean, it was a very different approach, but so I always tell people, I've kind of been working on Coda for almost 20 years now if I take that as my starting point.

Grant: Oh. Funny. And so Gideon was the project then, you joined that?

Shishir: Yeah. Yeah. That's right.

Grant: Yeah. Did it happen?

Shishir: No. Another important lesson is joining large companies.

I didn't know this, but the core Office leadership, hated this project. And it was interesting, I thought it had great sponsorship.

My, actually my skip level boss was this guy named Satya Nadella who now runs Microsoft, this is much earlier in his career.

But at the time the Office leadership team was focused in a completely different direction.

And they were very focused on simplicity. They were very focused on getting to a broader market for Office.

And the idea of building a development stack for Office just seemed nuts to them.

So basically the project got killed inside of nine months. And here I am, you know, I moved to Seattle.

I was engaged to get married to my now wife and I could somehow convince her to move to Seattle, which was not easy at all, but now I'm there.

And so now I got to figure out what to do.

And you know, this was kind of, Microsoft's trick is, you know, you get up to Seattle and even when your project gets killed, you end up staying.

And so I ended up having a six year career there, even though this first project ended up not working out.

Grant: And you worked on some, I mean, some really kind of important enterprise software applications while you were there. Right?

Shishir: Yeah. So the next thing I worked on--

I worked on two primary things after that. One was called OneFs. And OneFS, I'm guessing many of your listeners won't have heard about it, but back in that time, it was the hot thing.

And the best analogy I can give for OneFS is, OneFS was to Bill Gates and Microsoft, what Google Plus was to Larry Page. It was Bill's dream project.

I mean, if you go back and listen to Bill's interviews, both Bill and Steve's interviews from that time period and ask them what their biggest mistake was, they'll usually talk about OneFS.

It was this complete bet the company project. And the idea was to merge a file system and a database together into one product and build a single storage system, that was both semi structured and structured.

And, you know, kind of interesting idea, certainly a technically interesting idea.

It turned out to be completely mistiming the market. Nobody was interested in evolving their file system.

And just think about the file system on your computer, your laptop, you know, what's the last innovation that happened to that file system.

And do you want anything to innovate in that file system? And, you know, answer that question is probably not, right?

It was the wrong part of the stack to really focused on, but we bet the entire company on it.

Kind of like Google, you know, bet the entire company on Google Plus.

Basically every product took a dependency. You know, this massive team of really smart people assembled to go work on this thing that ultimately ended up being a failure.

Not only was it, the project didn't ship, you know, it was supposed to ship in a thing called Windows Longhorn, was what it was called.

That release of Windows got shelved and Vista shipped instead.

And though there was a seven year gap between Windows XP and Windows Vista, which is a very long time for Windows.

Vista ended up not being very successful either. And so it ended up being almost eight years before Windows had a real release.

And in that time period, the reason Bill and Steve always talked about it as their big mistake, in that same time period, Google was created, the iPhone was created, Facebook was created.

All of this while we were distracted by trying to build this sort of massive thing inside the file system.

But on the plus side, an amazing group of people got assembled for this project.

And we built some really cool stuff that ended up just not shipping.

After that, the team got in sort of outside corporate terms, the team basically got aqua hired into the SQL Server division of Microsoft.

So we're not going to ship it. We'll ship this feature set as a part of SQL server.

And for people who know the database world, the feature that OneFS eventually shipped as, is something called File Stream.

It's a column type in SQL server where you can store files, full files inside of a column in a database.

But for me, I ended up in this interesting quandary of, you know, do I go with a team and work on SQL server?

Or my other option was to go back and go back to working on Office.

And I ended up staking with SQL server and I ran what was called the program management team.

That's for most other companies, you can call that product management for SQL server and had a great run.

I mean, as your listeners can probably tell, I was kind of, at this point in my career, I was owed for three.

You know, nothing I had done had really worked yet. And SQL server was my first real win.

I mean, this business grew from, we were like an $800 million business when I started, it was about $4 billion by the time I left.

You know, we were number three in the database market by the time I was done.

At least in units sold, we had beaten IBM and Oracle and we're quickly spreading as the fastest growing database.

And so it was a fantastic journey for me.

But the other thing that happened in that period was I fell in love with databases as a technology.

And database is one of those, it's one of those interesting technologies where I think people mostly take it for granted.

Yeah, there's a database somewhere underneath my application.

And it was kind of hard to convince me to go work on it.

The guy who convinced me to work on SQL servers, Paul Fluster, he was running the division at the time.

And he's one of these kind of legendary Microsoft executives from that period.

He sort of started the division and grew the business and he just helped me fall in love with databases and the impact they have on businesses.

The elegance of the technical design. I always described databases as one of those products where when you work on a database and you go to any engineer and you look up at Microsoft, everybody had their own offices.

And so you go into their office and you look up at the wall, they have their degrees on the wall.

Every single person has a PhD. And in most cases, their PhD has their thesis on it.

And whatever their thesis statement says, that's what they still work on.

Because it's like that, once you like get into a database world, and pick, I'm going to be a query processor guy, you work on query processors for like your entire career.

And so the depth of understanding innovation in that product space is just really interesting, fascinating.

It was a great learning opportunity. And then from a business perspective, you know, it was finally a real business, right?

And everything I've worked on to that point just kind of didn't work. And so I just learned an immense amount in that period.

Grant: And what helped it succeed? Was it just like, you had a great go to market?

I mean 800 million sales is pretty good to start. So like it had a base of success, but like what helped it continue to grow?

Shishir: Yeah, I mean, it's a great question.

And I'm a pretty big believer in most great products, have a very simple thesis, that if you believe that thesis, everything else sort of falls into place.

And you know, what we'll talk about in a minute on YouTube, like the YouTube thesis was that online video would do to cable what cable did to broadcast.

The SQL servers thesis was pretty simple. It was as powerful database as Oracle, but a hundred X easier to use.

And that sounds kind of simple in retrospect, but it wasn't at the time.

Oracle was an incredibly hard database to operate and being an Oracle DBA was a real career.

I mean, it's kind of like the Maytag repairman. You could get paid, you know, high six figures for being an Oracle DBA.

'Cause it was like being an engineer. And Oracle had exposed thousands of hooks and ways to customize things.

But you are like, if you administer an Oracle database, you were an extension of their engineering team.

All we did was we took everything that people did with Oracle and we found ways to automate and simplify it and turn it into a set of either completely hidden knobs or very, very simple knobs. And we just made databases way more accessible. So that was the core theory.

The other thing we did that might be relevant for audiences, we changed the pricing model.

And this is one of the subtle things, you know, we talked about pricing with Centrata, and how that had all sorts of interesting implications.

Pricing for SQL server was also interesting.

And this was one of Paul Flustner's, I think great geniuses was database at the time were sold per processor and SQL server was mostly sold per client access license.

So the number of users that use the product, whereas Oracle was sold by, basically the size of the hardware that you ran the product on.

The net impact of that was enormous. You know, one fun story. I, pretty early on in my SQL server journey, I go do this set of customer visits.

I go out to Indianapolis and I'm meeting with one of the insurance companies. Big, huge company.

And I'm going in to meet the CIO and I'm being driven over by the sales team.

By the way, as a side note, I always find that when you're doing customer visits, you learn more in the car driving to and from the client, from like talking to the sales person than you do in the actual meeting.

'Cause you get like, you get the real scoop. I mean, this person is very motivated by and they know their customer super, super well.

And so we're driving over to the sales person says to me, "Hey, we're going to talk to the CIO, and I need to give you one warning. "You need to please don't tell them how much SQL server they buy."

And I said, "What? That's kind of odd."

Like my go to question in these conversations "is how do I get you to buy more SQL server? What do I need to do to get you to buy more SQL server?"

And he says, "No, you cannot tell them that."

And I said, "Okay, why not?"

And he says, "Well, here's the deal. The CIO is convinced he's an Oracle shop because their big insurance claims application runs on Oracle."

But if you look across his enterprise, we have something like 10 X, the number of SQL server instances than Oracle instances in the company.

And his check that he writes to SQL server, he doesn't really realize it, but it was almost three times as big as the check he wrote to Oracle.

But he was convinced that Oracle was his primary database because his biggest application ran on Oracle.

And it was like really interesting lesson because it was all started with per processor pricing.

Basically he, every time he made a decision to use Oracle, it was an active decision.

'Cause you know, we're going to set this thing up and it's going to be, you know, a 32 processor system and here's how much it's going to cost.

And with SQL server, once he had paid the licenses, he never had to ask about it again.

If there was one application that justified a client access license, basically number of users using SQL server, then every subsequent application was free.

And so we just spread like a weed. We were simple to use and a pricing model that actually incented that growth.

You know, we can talk more about that with Coda and you know, some of the lessons that have turned into--

It's very similar in some ways to what we've done with Maker Billing, in creating the right incentives for growth.

But the simple model of this was, you know, we overtook the database market in a very short period of time.

You know, in the period of like three, four years by simpler product and better aligned pricing model.

Grant: Interesting, and so to clarify, simpler specifically for the administration, or is it simpler for the developer that was using, creating applications?

Shishir: Yeah, that's a good question. I mean, there was developer innovation, but I would say it aligned between the two.

Those audiences for databases are more clear now. At the time the audience was not that different.

So you kind of had to be both when you use these databases.

And just to pick an easy example, one of the things you have to do in a database is decide what to index and what not to index and people less familiar with databases.

You know, basically when you set up a database, you say, "Hey, here's a piece of data that I'm going to need to search through often."

And you can instruct the database to create an index that will make it a little bit harder to insert data, but a little bit faster to get data out.

And there's always a trade off. In Oracle, you had to, as a DBA, you had to know how to set up.

They had like a thousand different ways to set up indices. And as a developer, you had to be aware of it.

And you had to write your queries in a certain way to make sure you actually use these indices.

And so by making it simple, you actually ended up making it simpler for both.

And so we put a lot of energy into support. Like one of the things SQL Server is really good at is as a really good query optimizer.

And it would auto discover for you, which index to use, which is now pretty typical.

And database is actually as fun side note for people who use Coda.

A lot of the smarts of a database are actually built in to Coda as well.

Like there's a query optimizer in Coda too.

So for database geeks, that means that if you write a query in Coda, that operates on a table, it will decide whether to use the index or not, and use what's called a hash match or an index lookup based on the data set.

And so that type of idea has made it simpler for both. It was both the IT administrator and the developer.

And Oracle made it not only harder for both, it meant that both had to know about each other, which makes it much harder to deploy anything.

Grant: I feel like, this effort of getting SQL Server adopted and getting it out there.

So it's a combination of ease of use, simpler pricing, or like kind of probably wasn't lower pricing for every one of your customers.

Probably some customers, where that would have been a higher price, right?

Shishir: Initially, yes. There were definitely cases where you could deploy Oracle and say, "I'm going to stand this thing up."

And it's a process or system, but I'm going to have the entire company use it.

And SQL server would come along and say, "Well, okay, you have to pay for all the users."

Technically we supported both types of licensing. So you could pay per processor or pay per cal. There's another advantage to paying per---

Grant: So you let them go either way. So they could pick whichever was probably cheaper for them.

Shishir: That's right. But we set the pricing to heavily incent client access licensing.

This was also strategic for Microsoft, which is basically what happened over time.

And this was not early on. I mean, early on, as another reminder, Microsoft was a client software business.

Microsoft was a, you went to at the time price didn't exist, but you went to a CompuServe and so on and you bought, when we say packaged software, it was literally packaged, shrink wrap, right?

Grant: True.

Shishir: The idea of selling server software was just not in the Microsoft DNA at all.

And so what happened over time was this client access model, you know, you would buy Office for a hundred bucks and that's it.

You had it forever. There was no ongoing payment. There's no subscription so on.

And what happened was all of Microsoft shifted their licensing model to match this.

And so this model of client access licenses became how you bought everything.

How you bought Windows, Office and so on. And so the other reason, the other incentive for Microsoft was you bought one bundle for Microsoft.

You bought all of the things you need for every employee.

And so SQL server being priced that way was hugely valuable because all of a sudden, you know, maybe a much longer conversation to be had about bundling, but the net impact was most Microsoft bills were as simple as just count up the number of employees in your company, multiplied by whatever your price per employee is, and you're done.

And you've got a whole bunch of different products and that was pretty strategic for SQL server as well.

But in the early days, that's not why it worked. I mean, we weren't really part of what was called the Enterprise Cal at the time.

We had to, not only we had to sell on our own, we often had to sell against the other Microsoft salespeople because the other Microsoft salespeople want the whole budget to go to Windows and Office.

And we didn't really have a model to incent cross selling.

People often talk about how, when big companies get into a space, they can, you know, these small products, you can just piggyback through distribution and so on.

And it's not easy to do that.

I mean, I watched the same thing happen at YouTube, where you would think that YouTube would be heavily advantaged by being sold to the Google Salesforce, but it really wasn't.

The new product, the different product, is mostly just a pain in the butt for the sales team. And they don't really want to sell it.

Especially for like a sales team arm to sell Windows and Office, for them to go through what I just talked about with SQL server versus Oracle.

And that was not a pitch they wanted to make.

They were not interested in talking about, whether or not you had to understand hash match indices as you'd sold Office.

This is totally irrelevant to them. And so early on, we had to sell our own this way, but over time it ended up being not only strategically good for SQL server, it became the heart of how, now, how the Microsoft business model works is a big enterprise license fee per employee.

Grant: And there was kind of a product and I've never really used it a lot, but it feels related-ish in the Office suite, which is like Access. Isn't that kind of like a database, you think?

Shishir: Oh that story of Access is like one of the most tragic stories of software on the planet.

I mean, it's honestly, I think if Access had continued investment for the last decade, you know, I don't know that like my category with Coda and so on would exist.

'Cause I think, the Access was totally beloved software.

And much of what we were doing with SQL Server was writing off the backs of Access.

What would happen with Access was a, I mean, it still exists.

I don't know that people really use it much anymore, but at the time, I mean, it was tens of millions of users and it was everywhere and it was spread like a weed.

Grant: And I got, college classes were taught on it. Right. I had like, I took one, right?

Shishir: Yeah. Most people did. And it was actually kind of a crappy database, but so what we would do is we'd come in and we'd, you know, one of the easiest migrations was we'll move all your Access deployment to SQL server.

And it was one of the key funnels for us. And because we were the simpler database and so on, it was not a, it was more complicated than Access, but not at nowhere near as complicated as Oracle. And so that was very effective.

Grant: Yeah Access was kind of that like, I mean, it ran on your desktop, right? Like it was--

Shishir: Yeah, so the IT value proposition was so simple.

You have all these people running Access on their desktops and hey, all I'm going to do is take it and run it on SQL server, sitting on a server where you actually have some idea where the data is and if this employee leaves or the computer blows up or whatever, you don't lose, you know, all your insurance records.

Grant: Right. So it's funny because Excel is basically a database or a table, you know, in some regard and then Access is a little more advanced and then SQL server. So it's sort of like--

Shishir: This progression.

Grant: Yeah of you know, I mean, product disarmament in a way, right?

Shishir: That's right. That's right. That was the upgrade path, right? Excel to Access to SQL.

Grant: Yeah. Real quick, just kind of an aside on Microsoft and this ecosystem, you know, you've seen the move more recently.

Like, I mean, I think at least Microsoft SQL can run on Linux now.

There's a lot more like open source and about Github. And they're just like, they're embracing Linux a lot more in the open source world, a lot more Microsoft.

And it feels like when you were there that wasn't quite the like party line.

Shishir: Linux was enemy number one.

Grant: Yeah. What are your thoughts on that? Like, you know, in strategically was it a, you know, hindsight, a mistake was it---

Shishir: I mean, I think there were a set of misreadings, but if you start with a certain world view, it's very hard to shake it.

And Windows was to Microsoft, what Google Search is to Google. It was synonymous. It was the same thing.

It'd be like asking Google and saying, "Hey, like build a bunch of stuff that works on every search engine except Google."

Or intentionally enables the other engines. It's not a great analogy because you know, there's not really any other search engines that quite matter.

But I mean, maybe that's very here too. Is it like Linux was this, it felt like a buck. It felt like a, how's this thing working?

Like there's a bunch of hackers that are not even employed by a company are building a thing that's threatening our crown jewels, threatening Windows.

And so the message, I mean, Bomber, Gates, and a lot of it is I think the company's DNA forms around a product.

It's incredibly hard to let go of that. And I think you almost had to have a leadership change to do it.

So I give Satya a lot of credit for that change, but I'd also say that it's not that like, Bill and Steve weren't smart enough. It's just like, it's very hard to do.

It's very hard to let go of the thing that was the heart of your creation.

And so, yeah, I mean that period. Yeah. It was a travesty to talk about running on Linux.

That was unheard of. And nowadays it's not, Windows is not the profit engine for the business, it's clear.

And so it's unnecessary and I think that's mostly, it's certainly a good thing for the industry, right?

Is that it moved the whole industry forward very fast.

Grant: Yeah. Yeah. I mean, I, you know, maybe that was a part of just the sort of competitive nature of Microsoft wasn't really compatible with the collaborative beliefs of the Linux and open source world.

Shishir: Well, I, maybe. I don't-- I think it's more just like when you're crowned, sort of the center of your castle is under threat, it's just hard to think objective.

I mean, Microsoft is always a very good partnering company in many other places.

Windows itself is a massive developer ecosystem, right?

The heart of what made Windows work for so many years was being incredibly open.

I mean, it's a, if you think about the difference between, at the time, like Microsoft and Apple, we would regularly open up APIs.

We would preview releases. We would-- I mean, in fact, we were often panned for it, that we were so open with the community because you know, Bomber would get up and chant developers, developers, developers, developers.

Like Microsoft was not a closed company. And Microsoft was a very open company, but they just drew the line at Windows.

And it was this the point, where like, after this it's just us.

Like above this it's everybody and everybody, not only it's everybody, we want everybody to be really successful.

Ben Thompson from Stratechery has a really good set of articles about the difference between different types of platforms and talks about, in Microsoft's case, if you built on Microsoft, you could build a massive business.

Like that is a, like if you think about other things that are sometimes called platforms, like is Facebook a platform and so on?

It's like, not really, right? It's really hard to build a big business on top of it.

Microsoft took much pleasure in the fact that businesses like SAP and Into It, and so on were created on top of Microsoft.

So the idea of like, you know, share with others, enable others, don't capture all the value for yourselves.

The Windows license was usually the by far cheapest part of any deployment. So, you know, Bill was well justified in his viewpoint.

It's like, "Hey yeah, Linux is free, "but this that's like dumb."

And most of these deployments, Windows is almost free. Like, it wasn't really, that's not why Linux was winning.

You know, it was better.

Like it was, and he would go and give speeches to the company about like, it's more secure, like these bunch of hackers working outside of an organization, built something more secure than Windows.

Like, how is that possible? They built something that's faster in all these different ways.

How's that possible? I mean, it was never more user friendly, but that was never a target either.

And so I don't think, I would say Microsoft had like an anti ecosystem DNA.

It just had a castle and it had a blind spot of defending that castle.

And you just needed a change of leadership to realize that actually, that's not where the game is anymore.

Nobody really knows which operating system things are running on.

I mean SQL server, we had projects all the time to run SQL server on Linux or SQL server on Unix.

And it was big deal because Oracle ran on both. Oracle ran on Windows and ran on Linux and Unix.

And so on. It meant that Oracle could run on any piece of hardware. And there was an enormous amount of innovation.

And I mean, people may not remember this, but at the time it was much more about scale up versus scale out.

Like these days, all the big systems, like my systems at YouTube and so on, ran on tens of thousands of machines.

But at the time, the way you build bigger systems was you built bigger hardware and companies like HP and Fujitsu would build these like, you know, 64 way processor machines, and that's splitted into 128 cores and so on.

And you get these massive things with terabytes of memory and so on, and you'd run these systems on it and Oracle could run on them and SQL couldn't.

And so we were like a leg down in so many deployments. And once you've deployed that hardware, like that's a sunk cost.

So the SQL server team was pushing on this for years.

Like, why are we locked out of running on hardware that our customers already have? Like, who cares?

Like nobody's going to see the operating system, who cares?

And the company was just adamant about it. Like Windows is our franchise.

We will risk the server business in order to ensure the Windows business works.

I would characterize this closer to innovator's dilemma than like change of ecosystem ethics.

This was just the ecosystem was developers on top of Windows.

And it was just hard to imagine any other worldview and, you know, Satya's certainly, massive credit.

I recognized it. And I think he just kind of unleashed the thing that the whole company was feeling. And it worked.

Grant: Yeah, it's a good point. And it also feels like Microsoft made this transition of being, what I would call primarily like a consumer company to eventually what became like a real enterprise software company.

Obviously still do consumer things, but you know, with the sort of start of Windows and everything they were doing, it was really not targeted at like massive enterprises.

It ended up becoming a huge part of the market, but it was like that computer on every desk, right? That kind of stuff though.

Shishir: Yeah, I mean, everybody missed that. At the time, and this is not missed, right.

This was the whole world was moving the other way.

We were moving from everything was client server to everything was client.

Because the early days of the internet all work like today.

Like you had these really light terminals, these Unix terminals that connected up to servers and everything ran in what we didn't call it a cloud, but it said it ran in a rack of machines that was not on your desk.

And so Microsoft, you know, led the path on the client revolution and then the world turned back and pushed back to the server and got the machines out of even your office and into the cloud.

And that's, you know, big, big transition. And I know Microsoft didn't move fast enough on it, but I wouldn't say it was that.

And I'm not sure anybody really did.

And the fact that Amazon did before everyone else, I think still for the history books, how the shopping company managed to win that market when it was clearly Microsoft's to win.

And I mean, the story's not done. And I think, I mean, I have no dog in that fight, but the intensity there, we'll see.

But Satya's making a lot of good moves towards it. And so is Google. A lot of good things happening.

But I think, you know, massive shifts like that often bring in a new player and that can be quite interesting.

Grant: Yeah. Yeah. That's super interesting. You know, contacts on Microsoft, you know, in your early career.

Let's talk about Google, 'cause I think, you know, how you got there and then what you did at YouTube is really interesting.

And obviously that business was a rocket ship, right?

Like that was one of the more valuable properties on the, you know, in the world right now, so.

Shishir: Yeah. So you want to talk about YouTube?

I can start with sort of the journey of how I got there, 'cause it was a little bit unexpected.

So it's, let's see, it's 2008 and my wife and I had a conversation and basically decided that we would move back to the Bay area.

We'd been living in Seattle for six years.

We had one kid, we had another one on the way and my wife is a physician.

And so when we had moved to Seattle, she got a residency there at a children's hospital in Seattle, just a great hospital.

And then she stayed and got her fellowship there and now she was ready to start her practice.

And she told me, "Hey, I can start a practice anywhere. I can be a doctor anywhere."

But once you start somewhere, it's really hard to move. Doctors have a hard time physically moving.

"And so just pick a place, but don't tell me in five years to go move."

And I said, "Okay, if I'm going to pick one place to live for what's likely to be the rest of my career, then it's got to be the Bay Area."

It was hard to imagine being anywhere else.

So, you know, I went and talked to my boss and said, "I, you know, it's no rush," but I gave him months and months of notice and said, "but we're thinking about moving. And I think I want to, I'm going to use this as an opportunity to move on from Microsoft."

And at the time, I was pretty sure I was going to start a company.

And you know, when had joined Microsoft, one of my key advisors was this guy named Bill Campbell.

A lot's been written about him since he's, there's a book written called "Trillion Dollar Coach", which is really awesome and celebrates amazing person.

He passed away a few years back. But he was the coach for a lot of the Kleiner Perkins companies in those early days.

And so when I was making the decision about going to Microsoft or Google, he was interestingly, he was Eric Schmidt's coach at Google.

And so he gave me some advice and he gave me a bunch of positive stuff about Google.

And he said, "Look, to just tell you honestly, "like Centrata was a startup, Google's another startup, you'll learn here and you'll probably make a bunch of money and so on, but the opportunity to go learn at a really strong product development organization, like Microsoft is probably an opportunity that you should take."

And so he encouraged me to do it and he said, "Just put a cap on it and go for two years and come back and start another company."

And so that was in his instruction to me. And so I call him up, and you know, six years later and I say, "I know you told me two years, but I took six, but I'm ready. I'm ready to follow the playbook."

You know, I've gone from entrepreneur to lots of different product journeys.

I've worked on client software and server software, things that were early and things that were a later stage, things with a big sales team, things with a consumer element, like, I'm ready. I'm going to go start a company.

And you know, Bill was excited and he's introducing me to all those people, but that was the formula.

And he said, "By the way, you should probably go talk to Google again."

And I told Bill, "Like, I don't know. Google's a really big company. I'm leaving Microsoft. Not because, I like Microsoft, but I didn't really want to go to another big company."

And he said, "Just go and talk to them." Jonathan Rosenberg was still running product at Google.

And he basically, he's one of those very persistent people.

So he was emailing me every year.

"Like, okay. Are you ready to come? Are you ready to come? Are you ready to come?"

And so I go and meet Jonathan and Jonathan has, he turns, you know, what was supposed to be an hour meeting into a whole day.

And has we meet all these other people and, you know, go meet Larry and Sergei again. And they just hired Andy Rubin and Vic Gudontra.

And all these people were doing this, like Google in 2008 was like this magic land, right?

It's like every person was working on this crazy project.

I'm going to go map the whole world and we're going to replace the operating systems and we're going to build a whole new browser and so on.

And every conversation was quite inspiring actually.

So I ended up in Jonathan's office at the end of the day and I sit down and he says, "What do you think?"

And I said, "Yeah, you know, I really appreciate it. And it's really exciting, but I don't, I really don't think I want to be at a big company."

And Jonathan is for people that don't know him, he's very animated, very direct.

He's a little bit crass. So he curses a lot. And, much more than I do.

And he says, "You know, you're missing the f'ing point."

I said, "What do you mean?"

And he says, "Look, I know you saw all these different things we're doing and this Chrome and Android and all this other stuff, but at its heart, Google is an ads company.

And we have so much opportunity ahead of us. Google is like back where Microsoft was in 1994, is where Google is in 2008.

And all the growth is ahead of us, even in our core business, not just all these new businesses.

And just one way to understand that is the ads business is, most of the money in advertising is spent on television and nobody even watches those stupid TV ads."

And, you know, he kept giving all of his cases on why Google at the time, was going to be much, much, much bigger than it was in 2008.

And by the way, which he ended up obviously being right about. But the line that stuck with me as I left his office was this line about television advertising.

And, you know, as you can tell from, we've done a pretty good, we've done a nice job with thorough background to this point, is I haven't mentioned the word advertising once, right? I didn't know anything about advertising.

I didn't, I'd never bought or sold an ad in my life.

And so his statement that all of the advertising money goes to television, this sounds dumb in retrospect, but that was like a surprise to me. I had no idea.

And I could tell you everything about the database market at the time, but I didn't know anything about the advertising market.

So I get on a plane as I'm leaving at his office and fly back up to Seattle.

And I do, it's a weird quirk of mine, but I do a lot of thinking on planes.

Actually kind of annoys me that they now have wifi on planes because there's one of the best places to go think.

And so I get on this plane and I take out a sheet of paper and I write at the top of this sheet of paper, this sentence.

What would it take to make television feel like the Super Bowl every day?

And you know, this is February, 2008, so it's two weeks after the Super Bowl.

And the thing that's running through my head is we had all our friends over to watch the Super Bowl.

And people don't remember this time period.

This was the Patriots versus Giants and the Giants pulled this huge upset on the Patriots.

But the thing I remembered from it, wasn't the game, the thing I remembered was people kept asking me to rewind not to see the replays, but to see the commercials again.

And I said, "That's weird." Like he tells, he said this sentence to me, that everybody, all the money is in TV ads and nobody even watches those stupid TV ads anymore.

And so I wrote this little paper and I said, what would it take to make television feel like the Super Bowl every day?

And I had three ideas on it. The most important of which was, what if every ad on television had a skip button on it.

And what if like the advertiser didn't pay, if you skipped the ad. And like, so then the ads would just get better.

Like 'cause the thing about the Super Bowl is the ads are really good.

Like they feel like content. Like what if you could just reset that balance and make the ads much better.

And there's a bunch of other ideas in the list, but that was the main one. So I get back home.

It's midnight. My wife's asleep already. Nobody to talk me out of my dumb ideas.

And so I get up in the morning and I write Jonathan an email.

I said, "Thank you so much for the visit. I really appreciate it. But I think my heart is still in starting a company, but your sentence really stuck with me.

I thought about it all night and I wrote this paper that I think you might find interesting on what would it take to make television feel like the Super Bowl every day?

And I don't know anything about advertising and I'm sure you're already working on this 'cause it seems like such an obvious idea, but just in case, you know, you find it interesting, here's what I think.

And I sent it to him. Jonathan's an early morning person.

And so he writes me back instantly and says, "This is awesome. Let's get on the phone."

So he gets on the phone with me and he says, "Love the ideas. Actually, nobody is working on it."

I'll get back in a moment why nobody was working on it, which I didn't realize at the time.

"As nobody's working on it, how about you work on it? "I have a way for you to do it, where I have this group of 10 people that are a little bit lost."

It was this little project called Mosaic.

"You can have that group, it's already staffed and you can have them do whatever the hell you want. And it can be a little startup inside Google and it's perfect.

You could work on this idea. You can learn about this new product. You can be at Google, but still work on a startup. It's everything you want."

And it did. It sounded like everything I wanted. And he had the lead of the currently of that team call me an hour later.

And it's by far the fastest job decision I've made in my life. I was decided by the end of the day.

Grant: To go into an industry and tackle a problem that you'd take only you've been thinking about for 24 hours.

Shishir: Only been thinking about for 24 hours, right? Half of a, what a ridiculous statement. Right?

Grant: Naturally, how could you not go do that? Right?

Shishir: I mean, yeah, in retrospect it was, people ask me a lot about like, I probably get an email a week, which is like, "How do I get into Google?"

And I was like, "I don't know. I did it in a way that I don't think is repeatable."

But, you know, it just felt obvious. Like it was exciting.

I was excited about it. It was, it felt like a startup. And so here's the thing I didn't know.

And you know, history repeats itself a little bit, right? So when I joined Microsoft, similar level of excitement, right?

And you'll probably see this out of, I guess I've done three major job transitions.

Every one of them is done with like immense excitement for the thing I'm running towards and a blind disregard for one I'm leaving behind.

Whatever that might be. Same thing happened with Coda, which we'll get to in a bit.

But the, I go to my boss at Microsoft and I tell him this, I'm leaving.

I'm so excited about this. And it felt very similar to how I felt in 2002.

Like I'm turning down Google, I'm going to Microsoft and I'm working on this Gideon thing.

And I'm so excited about it. I show up at Google.

And the thing that I didn't realize, remember when I went to Gideon, the thing I didn't realize was the Office leadership team hated the project and that's why it wasn't really going anywhere.

So I get to Google and the project is called Mosaic.

And the thing it's extensively supposed to work on is interactive television.

And by the way, the project eventually became Google TV, which then became Chromecast, which is now the Google Home team. Richie Tundra now runs that team.

Now it includes the Nest division, but it's early days, it was called Mosaic and it was interactive television.

And the thing I realized as I get to this project is Larry and Sergei hate this project.

And it's interesting. I should have figured it out because Jonathan tells me, "Hey, you got to do this."

Like, it's like such a good sell. Right? It's like, you get to do the startup thing.

You get to work on this idea. It's a little bit crazy, but we can support it.

And what's the worst that happens. You start this thing inside Google, it's well resourced. It's already funded.

And I said, "Okay." And I agree by the end of the day.

And I wrote him, I said, "Hey, you know, I had such a good chat with Larry and Sergei when I was there. Like, I'd love to hear their thoughts on these ideas. Can I send them the paper? Can I hear their thoughts?"

And Jonathan like, writes me back, says, "Oh yeah, they're traveling this week. Like maybe next week."

And like each week it took me two months to, I didn't want to leave Microsoft hanging.

So it took me two months to leave Microsoft.

And each week he's giving me an excuse of why I can't talk to Larry Sergei about this idea. So I get there and I realize why.

Larry and Sergei hate this project. I mean not like a little bit. Like, they really, really hate it. And it starts from a very visceral part. They hate television. They think television is bad. And so like the idea of making television better, is like starting from a, like, let's go make cigarettes better. In their mind, they're just like, "I don't get it. Why would you bother?" But then Larry and Sergei, to their credit, they are not shy on any of those things. And they engage, right? They don't blindly disregard it.

So Larry and Sergei had this thing at the time where they would do Friday product reviews.

And so you could sign up or they could sign you up.

And every Friday they had their entire afternoon blocked in little half hour chunks and they would just basically call on teams from around the company and say, "Come talk to us."

And you can use that time for whatever you want.

You can talk through a feature design or a launch.

You could get approval for something or something.

Remember like they didn't run the company at this point, Eric ran the company, but they had a lot of impact.

And so not having Larry and Sergei's blessing was a real problem.

And so we go in. Literally my first week, they schedule a Friday product review with Larry and Sergei.

Like, "Oh, good, go get their initial take."Right?

I don't know anything about, I mean, I thought I was going to work in advertising, but this product was in interactive television.

I don't know anything about television either. And this is like, the product we had to build was a hardware product.

Like we were going to build, you know, I had to go figure out how to build a consumer electronic device.

I don't know anything about this. So, I'm walking to this thing totally blind.

And my counterpart, we had an eng lead, named Vincent Duro, who's a gem of a person.

And Vincent is like patiently educating me on everything and he'd been around the industry for forever.

And so he had, he knew a lot about it.

We come into this meeting and Larry and Sergei just let us have it.

And not only do they let us have it in this meeting, which I would normally think, okay, let us have it.

Why don't you just cancel the project? They don't cancel the project. They like, let us have it.

They tell us all these different things and they're kind of constructive about it, kind of not.

And then they book us for the next Friday. They come back the next Friday.

And this happens for like six straight Fridays.

Every freaking week, I get beat up by Larry and Sergei and hear about why some version of television is stupid or your idea is stupid.

So anyways, that was my introduction to Google.

And so about six months in, so I, they also, the reporting structures at Google made no sense, but I reported into Susan Wojcicki.

And Susan ran ads for Google. And because my idea was kind of ads related.

My idea was super ads related, but this project really didn't have much to do with that.

I mean there's like a very long arc to imagine, you know, think about what you have to believe to believe that Google TV, Chromecast, and Home have any impact on the advertising market.

Like we're still, here we are 12 years later.

That's not what changed the advertising market.

But then, you know, Jonathan had properly, I was an eager entrepreneur.

So I was willing to suspend this belief on it.

So Susan comes to me a few months in and says, "Hey, we've got a problem." And it was a problem.

She says, "Well, we bought this company called YouTube and it's not going that well. We paid $1.6 billion for this thing. We're spending hundreds of billions of dollars a year on it in losses and nothing seems to be turning around. And so Eric has asked me to assign someone to go help fix this thing and I think you should go do it."

And so Susan, you know, put forward my name.

So I wanted to go talk to Chad about it. And I said, "What about my current project?"

And she said, "Oh, we'll find someone great to run that. Don't worry about it. And any way, it's like, you're probably sick and tired of getting beaten up by Larry and Sergei every Friday. Why don't you go up to San Bruno and work on YouTube and see what you can do with that?"

And so I went up and talked to Chad. Chad Hurley was the founder of YouTube and he was really excited.

And, you know, I sent him my paper and he was, turns out he had been thinking about something super similar.

And it was like way in retrospect, like way more applicable, right?

I mean, that paper basically became, for people familiar with the ad market, it became a format called TrueView, but, and people just familiar with YouTube.

It's the skip button on YouTube ads, right? That's what that became. And so he was really excited about it.

Like this is like, he's getting all this pressure to figure out a way to turn YouTube from a great product into a great business.

And he's like, "This is perfect. 'Cause it's like really user friendly and you can probably make a bunch of money and so on."

And so I ended up, you know, kind of moving over to work on YouTube. And I ended up spending up six years there.

Grant: And the reality is, you know, for TrueView, it's actually not that far off of the, I would say one of the core innovations of ad-words, which was the quality score, right?

The idea that ads, if you're going to put them on a results page, like you pay a lower price if the quality is better, right? If you get more engagement.

Shishir: It was obvious.

When I wrote Jonathan this paper, I said like, the reason I wrote it to him, and I said, "Look, I like this idea, but I'm not going to do it for two reasons. Number one, I don't know anything about advertising. Number two, this is Google's thing. Like Google should just do this."

This is like so obvious. It's like, just do ad-words again on YouTube.

Now it turned out, so same thing. Okay. So every problem, when you get into it and you have this great idea and you get there, you realize why it's not being done.

So I end up on this Mosaic project that Larry and Sergei hated, but then I get to YouTube, I'm like, "Okay, fine. I got six months of, I'm going to shake that off. And I'm going to go work on this YouTube thing."

And Chad's excited about it. And I think that's enough. Right? Okay. So that next hurdle.

Turns out the sales team hates this idea. They think it's so stupid. I had this like epic meeting with the sales team.

So the sales team at YouTube at the time, YouTube was, now it's tens of billions of dollars in revenue and so on.

At the time we were doing $30 million in revenue a year. Most of these like very bespoke brand deals.

And by the way, we're spending six or $700 million a year.

So there's like, you can imagine what the P&L statement looked like. And so I'm a few weeks in and the head of sales, Susie Writer, she says, "Hey, we're having this sales off site. You should come and speak."

And I tell her, same thing. Like, I don't know what I'm going to say.

Like, I don't have a plan yet. I'm still learning.

So she says, "Don't worry about it. "Just come in, talk about your ideas. It's a very small group. They're very motivated. They work as a team."

And the entire YouTube sales team fit in a small conference room at the time.

It was like 15 people. And so I come in, and I just talked for a bit and talk about my background and a much shorter version of some of the stuff we just talked to.

And I ended up talking a little bit about this idea, with skip buttons.

And I finished, they patiently listened to me. And then one of the salespeople, this woman, Beth Green, who's since become a very good friend of mine, Beth stands up and says, "Shirshir, I have a question for you."

Okay, what is it?"

And she says, "Do you like not want any of us "to make any money? "Is that your plan?"

And I ask her, "Why would you ask that? Like, no, I have been sent to like, I'm sent here to turn this thing into a business. Like everybody knows YouTube is popular, but everybody thinks that it's a failed business model. It'll never work."

And she says, "You put a skip button on ads, and all it's going to do is tank revenue. Like I get the user friendly, blah, blah, blah."

"But you all know that nobody wants to watch ads and you put a skip button on ads, all people are going to do is skip them."

And we're just going to tank on what is our tiny amount of revenue already. This is a terrible, terrible idea. And there's no way you're going to sell advertisers on it."

And so we took this idea and I fought it for a while, but we basically put on the shelf. TrueView didn't launch.

I joined YouTube late 2008. TrueView didn't launch in its sort of proper form until I think late 2010, or early 2011.

And we actually had to turn around most of YouTube profitability without it, because the level of resistance in not just the sales team, because they were representing well, but the entire industry was super high.

Grant: Oh, interesting. That wasn't the key to getting YouTube sales up. That was just a thing later on that became popular.

Shishir: Yeah. Lots of learnings there. But no, it wasn't.

I mean the TrueView revenue line, isn't what drove to profitability.

It's a set of other changes we made and we did launch a new ad products.

And one of the things I ended up doing was we launched a, a version like you got to the right analogy, which is what we were talking about with TrueView was kind of like Google Search, but applied to YouTube.

And so we did launch a product called Promote Your Video, which was on the YouTube search page.

That, everybody thought was a reasonable idea. And it looked just like ad words on your search page.

But most of the changes we made were actually on the supply side.

We changed our dynamics with makers, with creators. And the biggest one was we allowed anybody to become a creator.

At the time, you had to have an arrangement with us in order to make money on YouTube.

And probably the most impactful thing we did to turn YouTube around at the time was we let anybody make money, which in retrospect was like also very heated decision and lots of debate about it today.

But it went from YouTube was this massive property with a tiny, tiny portion of content, which had any monetization to, you know, a lot of the content of monetization.

And what we did was we created a flywheel.

It meant that all of a sudden you could make money on YouTube.

One of the most famous articles that came out in that time period was there was this video called "Charlie Bit My Finger" and just really cute video.

The two little boys. Yeah. Classic, right? Hundreds of millions of views and so on.

Two little boys and really funny and so on. And so we flip on, as we roll out this program, we flip on their ability to monetize.

And these two little kids make a few hundred thousand dollars and the press like totally catches onto it.

And this is like, "Hey, these two kids that just captured a little home video moment, just paid for college and then some. and they paid for college in a small house."

And that flywheel, once it started was unstoppable. Basically, if you look at all the media platforms out there, YouTube is and all the social networks and so on, YouTube is the only one that allows you to make money and it encourages it and aligns incentives to do it.

And so that's what broke through. And then once we had all of that inventory and all that ability to, you know, opportunity for advertisers, then the innovations and the ad formats really mattered.

And TrueView was very important, but that was the main thing we did to turn YouTube around.

Grant: And is that because it, did creators then seek to build content that that would be more monetizable or what was the--?

Shishir: I mean, it turns out that the biggest factor in monetizing content, is time spent. It's audience.

People ask me all the time, "How do I make more money on YouTube?"

I said, "Just get more viewership. "Most everything else will sort itself out. It's just get more viewership. Everything else comes out of that."

And what it did was it heavily encouraged that because you know, it's interesting.

We used to talk about one of our dreams for YouTube at the time was someday in the future, kids are going to write in their school essays, what do I want to be when I grow up?

And they're going to say YouTuber and we used to laugh about it. So, nobody's ever going to say that.

That's crazy. And now, I mean, I have two kids, 14 and 11 years old, and like that's on their list and it's going to be a YouTuber.

Grant: Probably the top thing on their list.

Shishir: Yeah, exactly. I mean, for a lot of people, right?

I mean, to be a TikToker is pretty close too. But that was created by creating this incentive.

And so what happened was we created the flywheel, was you create this content on YouTube, you get viewership, you get this check that is like, unheard of, right?

And a lot of both YouTube creators and viewers were young, right?

So for many people, small checks were a very big deal.

You get this check and you say, "Oh my God, I've never had a job before."

I have this really funny story where I got on a plane.

This was like, I don't know, six or seven months into my YouTube journey.

And I get on a plane and sit down next to this woman.

And, you know, we're just chit chatting as the plane's taking off.

And where are you headed to? New York or from New York or so on?

And I said, "What do you do?" And she says, "Oh, I work on YouTube."

And I was like, "Oh, really interesting. Like YouTube is like a couple hundred people. Right? So I was like, That's weird. Like, I think I know everybody. But maybe I missed someone."

And I said, "Really, you work on YouTube. Like, which office are you in?"

So she's like, "No, no, no, no, no."

And she pulls out her business card and says, "I'm a YouTube creator. And I publish content on YouTube. You guys send me a check."

And so I work at YouTube. And that was how she thought about it.

And basically as we made this change to allow anybody to make money on YouTube, we just built this like army of people whose job it was to promote YouTube.

And they did it out of their own incentive. They didn't really need to be told to do anything different and it worked.

And we still had to do a lot of work after that, but that was the key first step.

Grant: That's really interesting.

I think we talked previously once, maybe once before, about a little bit, the other side of YouTube.

You know, outside of the creator side, but there's the reality is that the buyers of ads are companies.

And so you need to provide functionality and features that allow them to, you know, basically buy ads successfully. And that kind of looks like enterprise software, right?

Shishir: Yeah, I mean, I think that, and by the way, there's a fun story on the naming of TrueView that--

So like I said, I get to YouTube and I have this idea.

This paper I wrote is the whole reason I joined Google. I end up on this product that ends up being mostly irrelevant to that.

I end up at YouTube. Chad's excited about it. I think it's finally my shot.

Sales team shoots it down. And so this is like two years later and I'm like, I'm dejected about this idea.

I've stopped talking about it. The guy who ran the sales team at the time, Nikesh Arora had forbid me from talking about it at sales conferences.

Like, you just can't do it. You keep embarrassing yourself. Just don't talk about it.

And, so, okay, fine. I'll stop. So I have this sales person. This guy Lane Shackleton.

Actually Lane, interestingly, he's now my head of product and design at Coda.

So Lane comes to me and he says, "Hey, I really want to be a product manager."

And at the time Google had this odd rule that you couldn't be a product manager unless you had a computer science degree.

That's maybe back all the way to start at this journey. Like a math degree is not good enough. You need a computer science degree.

And so Lane comes to me and says, "I want to be a product manager, but I can't apply 'cause I don't have a CS degree. Can you help me out?"

So I say to him, "Look, I can try, but it's a pretty hard requirement. So I need a really good case. And I have an idea for you. And here's my idea.

I'm going to let you be a product manager in your 20% time. And I have two requirements.

Number one, you can't let go of your current job. Like you're our best salesperson.

I can't have your boss complaining about it and so on. You have to do this in your extra time.

And two, you have to do whatever project I hand you.

And I've got one in mind and it's not going to be easy, but these are my two arrangements."

And so he agrees and I say, "Okay, here's a project. It's called skippable ads. And here's the history. You know, this is what I wrote this paper about it. So on. And I think it's still pretty exciting, but the sales team thinks it's really dumb.

And I can't really assign you much in terms of engineering. I can assign you one engineer to work on it.

And it's a pretty junior engineer, but you'll have to make do, but that's it. I mean, this is my deal. If you can make it work, then you can be a PM."

And Lane accepts, right? So Lane goes off and studies the problem for a while and he comes back and he says, "Shirshir, I think I know your problem."

And I had handed him a set of instructions.

He said, "Look, I think the problem is, "you just have to make the buying flow really obvious and just have to like, make it feel like ad words. And we need a cost per view billing model."

And like all this kind of geeky detail stuff about what I thought was needed to make this work and basically kind of sneak it into the sales force was my plan.

The, before you know, it, you're going to end up buying this product.

You don't even realize you were buying it. And he comes back, he says, "Look, many of those suggestions are good and we do need to do those things. But I think your problem is different."

So, "Okay. What do you think the problem is?"

And he says, "I think the problem is the brand."

And I said, "Really?"

And he says, "Yeah, think about the name. Skippable ads. "Who is that value proposition for?"

The ability to skip ads is a value proposition to users, but users don't know the names of ad formats.

Like who knows what a 300 by 250 is and what a masthead is and what a sponsor post is and so on.

They don't know any of that stuff. They call it Google ads. They don't know what ad words is.

So there's no need to have a name that's consumer facing. And moreover, it's a terrible name for an advertiser.

Like from an advertiser's perspective, skippable is not a value proposition.

It's an anti value proposition. Like why would I want to make something that people skip?

And so he said, "I think we need a better name. And we need one that aligns with how advertisers think about it. This was our audience."

And they had a bunch of names and one of them was actually TrueView.

And then we ended up spending a few weeks, debating the name and coming up with TrueView.

And the idea was very simple. It was, you only pay for views that are actual views.

And if people skip, they're not really viewing it. And it was like night and day.

All of a sudden this went from, I couldn't talk to Salesforce about it to it was a number one thing on the sales team's request list.

So the like number one thing they wanted us to work on. Get TrueView up.

What a Google-y sale. We'd hear that all the time. What a Google-y sale.

What a great idea. And, you know, we had done some of the math and so on.

So we were better buttoned up on why it was going to make way more money than many of the other formats were.

But the naming actually turned out to be the key difference, which is another good lesson in the little things that make these products work and how important positioning can be.

Grant: That's really interesting. And just the response from your sales team, because they're kind of your proxy for how your customers are going to feel about it.

And so you knew that if they hated it, that there was no chance that it was going to go in. That's really interesting.

Shishir: Yeah, it was a little bit a segue to the second part of your question about the enterprise, and it's sort of a reminder of, you know, YouTube from a surface level feels like a consumer business, but I had four divisions of YouTube.

One focused on viewers, one focused on creators, one focused on advertisers and one focused on infrastructure.

And almost evenly split between the four, and most people, you can almost think about it like an iceberg.

Like for most people, what they think about when they think about YouTube is they think only about the viewer part, but actually the other three parts, creators, advertisers and infrastructure were pretty heavy, pretty classic enterprise businesses.

And you know, it wasn't a SaaS licensing model.

So the payment model was different, but the core motion was very similar.

Like convincing advertisers to buy on the platform was partially about the value proposition to buying there and so on.

But then the tools had to be great and being good at targeting and being good at analytics and so on all really mattered.

The infrastructure side, we had to work with network providers and ISPs, and similarly we had to incent them and create tools for them to be able to provide great quality of service to our users and a very similar set of tools for creators.

'Cause we had to address creators, everything down from the, you know, the single person with three videos up to major studios with, you know, hundreds of thousands of videos.

Grant: Yeah. It is interesting because you don't think about that as a YouTube sort of consumer, you just think about watching videos, but you're right, there's this, you, maybe you've uploaded some, but you probably haven't ever bought anything.

So there's these whole admin sides to these things where you probably you're building in some amount of robust access control and other sort of standard enterprise features into those products, I assume, right?

Shishir: Yeah. I mean, that's right. I mean, for these companies. I mean, these are their core assets, right?

I mean you're a media company or your major advertiser, so on, these are your core assets.

And so you build all the same stuff. You know, how does single sign on work and so on.

The licensing model tends to be different.

But that's true of a lot of-- These days, I think what we call enterprise SaaS, there's a lot of companies where their monetization model.

I mean, I was just talking to someone from Carta, for example, and Carta's a big enterprise SaaS player, but you know, the way they monetize, isn't always license fees as an example.

Grant: Right. Right. But it's just interesting to sort of think about the fact that, you know, the skills and the things we talk about generally for enterprise ready, you know, are maybe more broadly applicable outside of just the enterprise SaaS and enterprise software companies and, you know, the open core companies.

There's a whole world of other applications that have these, you know, administrative or back ends to them where different people are, need these exact same features and tools.

So that's a broader ecosystem than I think I initially ever thought about.

Shishir: Yeah, definitely. And I think it's probably worth mentioning.

My career has been, I've been quite lucky that, you know, we're at a one, two, three, four, five, six, this is project number six in my background.

We've worked up to here and this is, you know, six completely different markets.

And one of the fun parts about that is you get to learn and approach everything again from the sort of new, fresh beginners mind.

But you also get an ability to transfer. Like the ideas from one space end up working in a different space and that's hugely impactful.

I, you know, as we're building Coda, I regularly find myself, you know, telling stories about, you know, here's a pattern that, you know, is deeply built off of this thing I learned at YouTube, this thing we building SQL server or licensing models or so on.

So I think spotting patterns between ideas is often where a lot of innovation comes from.

Grant: Yeah. I love that. I also find that having a breadth of experiences and different inputs helps you draw conclusions and parallels and see similar things in, you know, like if you study something even just totally unrelated to the problem you're trying to solve, sometimes there's lessons in those things that you can apply to, you know, your enterprise software problem or whatever else you're doing.

Shishir: Yeah. For sure.

Grant: Yeah. Okay. Let's dive into Coda.

So, you know, tell us, just about what Coda is, the thesis, how you guys got started.

You know, obviously we spent some time getting some background, which is super helpful and interesting. I think there's a lot of context, but we'd love to hear about, you know, what inspired Coda and how you got off the ground.

Shishir: Yeah. This podcast is super funny. I usually spend all my time on Coda, so it's kind of fun to go back through memory lane for some of these other stories. Let's see.

So Coda is a new type of all in one document. Blends best parts of documents, spreadsheets, applications into one new surface.

The promise is that anyone can build a doc as powerful as an app.

And, you know, we started the company with two primary observations of the world.

One is I think that the world runs on docs, not apps.

And you know, this is, you can probably tell from all this history, this has been a little bit of a theme of my career where back to even just Centrata days, this viewpoint that the prominence of documents in running teams is very high.

YouTube was particularly stacked this way. We basically ran YouTube on Google docs and Google sheets.

I didn't quite like how Google did OKRs and so we did a different planning model that we had to run on our own spreadsheets.

We, you know, I did compensation differently. I did a thing called level independent compensation that was different than how Google did it.

We did it in a network of spreadsheets. One of the most fun examples is if you hit flag on a YouTube video in those early days, it would show up as a row on a spreadsheet, on an Office person's desk. And that's how we ran these major systems. And so observation number one for Coda is, you ask a team how they run themselves and they might name a set of packaged applications.

And we use this for inventory tracking, task management and so on.

But if you watch what they do all day, they probably live in documents, spreadsheets, and presentations, and some communication tool for most of their day.

So that's observation number one. Observation number two is those platforms, those document platforms haven't fundamentally changed in over 40 years.

And you know, a fun analogy we like to use for it is if Austin Powers were to pop out of his freezing chamber, he wouldn't know what clothes to wear.

He wouldn't know what music to listen to, but he would absolutely know how to work a document, a spreadsheet and a presentation because the core metaphors haven't changed since the 1970s.

If you go back it's WordStar, Harvard graphics and VisiCalc.

All the core primitives are exactly the same. I mean, the way pages are laid out, the way slides are laid out, the way formulas work, the way all of those things are exactly the same.

And we've just had 40 years of copy forward. And basically through a set of platform transitions, we took it from Green Screens to Dos, to Windows, to the Mac, to the browser, to mobile.

But all of these things are fundamentally the same.

So if you put these two thoughts together, you know, the world runs on docs, not apps, and those docs haven't changed in 40 years, you know, it spells new opportunity.

So when we started the company, we started with this rallying cry.

What would we build if we started from scratch and built an entirely new doc? So that's where we started with Coda.

Grant: Okay. And you started to the company what? Like six years ago or so?

Shishir: Five and a half years ago, almost six. In the middle of 2014.

Grant: Co-founders?

Shishir: Yeah. My co-founder is a guy named Alex DeNeui.

So Alex and I have worked together for 20 years now. He was part of the initial starting team at Centrata.

And basically we've, interestingly, we've worked almost every other job together.

Grant: Oh, wow.

Shishir: So he worked on OneFS, then he worked on something else.

And then he started a company called Doc First and so on.

And the way Coda started actually was originally, he was starting a company that thankfully wasn't working that well.

And he asked for my advice on where to pivot it.

And I was, at the time I was a Google executive, starting a company was like the last thing on my mind.

And it was, you know, back to job transitions. You know, I was pretty sure I was done working on YouTube.

The problem had run out of its juice for me, but I was pretty sure I was just going to do something else at Google.

I mean there's thousand great things to go do. And he asked me to help him brainstorm ideas for his startup.

And, you know, one point in this brainstorming, one of us write on the wall, the sentence that, you know, what if you could make docs as powerful as apps.

And that just like took a hold of me. And I just couldn't stop thinking about it.

It's kind of like, the way I ended up at Microsoft, the way I ended up at Google kind of same pattern of like, when I see an idea that I just really think is great.

I can't stop thinking about it. Then I have to go do it. And so I ended up quitting Google and starting this company with Alex.

Grant: Okay, cool. And then raised the money right away. Like I think you were kind of in a private beta for a long time, right?

Shishir: Yeah. I mean, with Centrata I took nine months to raise $500,000.

What I thought was $5 million, but was actually traunched and ended up being $500,000. And it's an incredibly complicated process.

You know, Coda, we raised money in a weekend.

You know, we raised $25 million from some of the best investors in the planet.

Reid Hoffman and Hemant Taneja led the series A and we got started.

So vastly different starting a company, you know, 20 years into your career. And that's good in a bunch of different ways.

We made a decision early on to run the company in stealth.

And probably worth its own discussion on whether or not you should run a company in stealth.

I was talking to, I know you're close with Rahul over at Superhuman as well.

And so Rahul and I have talked about this a bunch as well, 'cause he's followed a similar strategy.

And basically my reasoning, like we had this conversation in our very first, sort of get together as a company, and we said, are we going to build this company sort of out in the open?

Or are we going to build it in stealth and launch later? And the reasoning was fairly simple.

You know, we felt that if we would build a company out in the open, then it would be hugely distracting.

I mean, we couldn't talk about the product. We knew it would take time to build. It was not--

Coda is not an easy product to build. And mostly what they people would talk about is, you know, backgrounds of the founders or the investors or so on.

And I just found that to be not only distracting, but like the wrong value system.

I wanted the first time we talked about the company to be about the product.

I didn't really want to be part of the gossip circles on what different executives are doing.

Grant: Sure.

Shishir: The other reasoning was what do you get out of, you know, being more public with the company early on?

I mean, this sort of three things that people are generally trying to get by being more public.

You're trying to get investors, you're trying to get users or you're trying to get recruits.

And we didn't really have a problem with any of those.

We'd already raised plenty of capital because of our background, we didn't have a lot of trouble recruiting and this was a product applied to literally everybody.

So finding users was not hard. And so there was a question like why bother?

And Rahul had basically the same frame for Superhuman was that he had capital and he didn't need anything else.

And, you know, email, I guess, as a disclosure, I'm a Superhuman investor as well, but, you know, emails and other product where it's applicable to everybody.

And so it's sort of relatively easy to go find early people. So that's how we ran.

And we ran in stealth mode for about three and a half years.

And you know, when I say stealth mode, it doesn't mean without customers.

We were actively testing with customers the entire time. And I think it's really, really important.

That was one of the key decisions we had to make was I'm comfortable running in stealth mode, but I am not comfortable building in a vacuum.

And we need constant feedback. And so we just onboarded cohorts of companies and, you know, went out and saw different teams and companies and individuals and asked them to try out the product and we'd get a bunch of feedback.

And, you know, the first, we named them, we call them alpha one, alpha two, alpha three.

And you know, the first couple were major disasters.

And alpha one was, we had one company in that cohort and the company had six people in it.

So our dashboard basically went from zero to six. Every day we could look at it and say, how many people use the product?

It's like six. Okay, great. We had a good day. And then one day this thing goes to zero.

And I call up the CEO of this company and I say, "What happened?"

Like, and Coda is a product where when you use it, you tend to use it every day.

And I called the CEO and said, "What happened? You guys go on, like, you're on an off site. Are you going on a vacation or what's going on?"

And the CEO's name is known Nolan Lavinsky. And so Nolan tells me, he says, "Yeah, I didn't know how to call and tell you this Shirshir, but my team revolted. And they said, if I keep making them use this software, they're going to quit. So I had to stop. And good news for you, is they all really believe in the vision, but they have a list of complaints that until these are addressed, they're not trying again. The good news is I can show you this list. The bad news is like, in the meantime, I can't use the product."

And so, you know, we churned 100% of our customer base in a day.

It's just not fun, but you know, that's what the process was like for three and a half years.

It was like hand apart, people realize that it's not there yet. Go back to the drawing board, try again until it started really sticking.

And then, when it started sticking, then we launched it.

Grant: Cool. And initially kind of targeted at teams or users? Who were you focused on?

Shishir: Yeah, I mean, it's always been targeted at teams.

I mean, I think our positioning on that has strengthened over time, but it's, you know, at its heart, Coda is a collaborative document.

And you know, one way to think about it is, you know, when we went from Office to Google docs, massive transition, right?

Office to Google docs, Google completely surprised the world, right?

Nobody thought that Office was at all vulnerable and Google comes along and removes 80% of the features out of Office and adds one.

They add collaboration. And everything else about it is worse than Office.

But that one thing turns out to be massive because it turned Office from a single player tool into a multiplayer tool.

And I mean, I was at Microsoft at the time when Google came out and we all laughed about it.

And I was like, you know, they think they're going to catch up with literally dozens of years of development and the Office stack.

Like they can't possibly do that. And if this collaboration thing actually matters, then we'll just do it.

And nobody understood it because everybody's perception was why would I want other people to muck with my spreadsheet?

Why would I want other people changing around my slides?

That sounds terrible. It was like, that was our initial reaction to collaboration.

Was this sounds unsafe. It sounds bad. We were talking a lot about revision control and how do you prevent changes?

And what happened was Google, with Google docs, rethought the surface and all of a sudden documents, presentations, spreadsheets became a team product.

They really weren't a team product till then. They were a documentation product.

They were a one person build something and emails it to everyone else.

And you get this attachment. And you know, when you want to make a change, you email them back and they make a change.

And that was the process. And so that in my mind was the half step that enabled Coda.

And, you know, we've now seen a wave of other productivity tools.

I think we've kind of a renaissance of productivity tools right now.

And I think it all started from that observation that by unshackling this productivity surface from being single-player to being multiplayer, now you can go look at it.

But on the flip side, Google changed nothing else. They intentionally were, you know, very backwards compatible.

I was talking to one of my friends on the Google docs teams and just were talking about one of the Coda features.

And he's like, "Oh yeah, we thought about that feature "on Google docs."

And I said, "Why didn't you do it? "It like seems like a really obvious feature."

And he said, "Yeah, you know, we couldn't figure out how to export to Word and print wouldn't work. And so we just didn't do it."

And the level of backward compatibility requirement in the industry was super, super high. So Google's had this half step.

I think products like ours are taking the rest of the step and saying, "Hey, if you really rebuild this product for teams, what do you do differently?"

And you start again from scratch. Because an easy example, tables in Coda, they kind of look and feel a little bit like spreadsheets, but they operate more like databases.

In particular, it allows people to have multiple views of the same data.

And I'm sure you've had this experience.

You have a spreadsheet, list of people you're inviting to event, and you want two views of it.

One for the caterer and one for the person setting the tables and different one for the host and so on.

But you can't do that. Like it's in the spreadsheet. So everybody has to agree.

These are the columns. These are the sorts. Everybody, you have to just live with it this way.

And it's like a really dumb, simple thing is, wouldn't it be nice if we could all have our own views of the same data and look at it our own different way?

When you think about building a product for teams and you're going to build a collaborative surface, that seems kind of obvious.

Not only like, let us all edit it at the same time, but also let us view it through our own vantage point.

And so things like that are sort of, I think, finishing the step and really turning a collaborative surface into a team product.

Grant: I love this idea of like, well, if we remove the sort of requirement that it has to be exportable into Word and like printable, then what's the next evolution, right?

Shishir: That's right. You have to start with, an innovators dilemma term, you have to give up something, right?

And to be clear, Google did too. Right? Google gave up 80% of Office's features to add collaboration.

Huge credit to that team for shaking something that people thought was unshakeable.

I mean, Google docs did to Office what Amazon did to the cloud market.

Like took it completely by surprise. The search company owns the productivity space. It seems crazy.

Grant: Well, and personally, I can't remember the last time that I either printed or downloaded a Google doc, as well as a word doc.

So that's why I'm like, well, that makes sense. 'Cause like I literally don't know that I've ever done that in the last like six years.

So if I've taken other people's Word docs and put them into Google docs, because I was like, okay, 'cause now we can actually edit it together.

I'm like, I don't know why you sent me a word doc. I'm like, that was weird.

So that makes a lot of sense. And now, and so you're you roll this out?

You hit a bunch of problems in the beginning. You eventually kind of figure it out.

And like, now it's a product. Now, like, you know, you have lots of teams on it.

You have lots of folks that are paying for it and using it in different ways, but probably still more like mid market, I'm guessing.

Not like super enterprisey yet.

Shishir: It's a wide spread. So we came out of stealth three and a half years ago, sorry, three and a half years in.

We didn't fully launch the product until last year. So last February we launched Coda 1.0.

So we're about 15 months in market now. We launched Coda 2.0 last October.

And that was our, we call it Coda for teens, but it was also our first icing launch.

So up til then the product had been free.

So I like to say 2019 was a big year for Coda because we went from an R&D project to a fully, generally available product to a business in the course of 12 short months.

And so it was a massive change in that, from that perspective.

And in the meantime, the product spread like wildfire.

I mean, it is a product that has, this spread is naturally built into the product.

If you build a product for teams, you build a product for collaboration, it's better when you use it with others.

Like you just said with your, you know, what do you do with the word doc?

You put it in a Google doc and you immediately share it, right? That's one of the main reasons to do it.

And so, you know, now it's tens of thousands of teams using Coda already. Just, you know, sort of only a year in.

It's been interesting watching the spectrums of types of people using it. There's about 80% of our users in small businesses and businesses with less than a hundred people, so there's definitely a big base and there's a clear reason for that. I mean, Coda lets them build tools that are actually fit for them.

And you know, you can build a doc as powerful as an app.

So you can not only use Coda for simple things like taking meeting notes and you know, tracking tasks and so on, you can go build your CRM system in Coda, you can go build up a recruiting system.

You can build inventory systems. We have whole businesses, many of them that are running entirely on Coda, that is their primary stack.

They've replaced 10 different applications with Coda and that's what they use.

At the end of the spectrum, you know, we have a bunch of very large organizations using Coda as well.

You know, Uber, Spotify, New York Times, Intercom, CVS are all big customers.

And I think the, you know, certainly our value proposition, but generally at a team level first, and those teams are almost like little individual startups and they build up tools to run their teams in all sorts of different ways.

The department that usually picks up Coda first is product management.

It tends to be tends to be a department where this promise of docs, as powerful as apps is really resonant.

That they're constantly stretching documents, spreadsheets, presentations, much further than it should be.

And it also happens to be a point of a lot of spread. I mean, those people tend to drive, they're the connectors between the engineers and the marketers and the support team and the sales team and so on.

But we see lots of uses across departments. It's a very long tail of ways that people use Coda.

Grant: Yeah, and I'm guessing that that PM sort of like ideal customer profile, like they're also, I don't know, generally dissatisfied with the alternatives because they find that they don't really meet all the requirements and they think this could be better and that everybody looks at, what can I do that makes this better?

And ultimately if you've built that thing and then you give them this power, they're going to be an evangelical user group.

Shishir: Yeah, I mean, it's of all the departments, it's the department that the least, enter up into back to our Peter Roland definition that it's the least good enterprise apps have been built for that segment.

And I think the reason is fairly simple.

If you go back to that early enterprise apps definition, enterprise apps are about taking a team, finding a process, figuring out what part of it is repeatable and making software that makes it so people can only do that one thing over and over and over again.

And it's kind of the antithesis of product management.

Like product management is all about new, different ways of doing things. Like there's no formula for how do you build great products.

And so the idea of telling a PM like here's a methodology and this is it, just do this.

And I'm going to treat you like an automaton in the middle of this big enterprise app.

And you're going to do it the same as every other company is just not how it works.

And so that's why PM's turned to these horizontal tools.

And they're in, you know, they're making pitches, they're making, writing product briefs and documents, and they're trying to structure teams and slides.

And they've got all their tracking happening in a spreadsheet because you know, nothing in the bug tracker actually makes sense for them.

And they've got to somehow map it to something the sales team can understand or the marketing team can understand and so on.

And so they tend to be the most extreme of their world runs on docs, not apps.

The easiest pitch for Coda is how common I'll meet a PM. And I'll say, "Just show me your browser and show me how many tabs you have open."

And, you know, inevitably the PM has 30 tabs open and it's like documents, spreadsheets, presentations, so on.

And so to imagine you could replace, you know, 20 of those with one document.

That actually not only put them in one place, which is a small but important value proposition, discovery and so on, but those things also probably contain complete copies and pastes of the same information over and over and over again.

So what if we could put it in one connected system that is still designed by you and meets how you want your team to operate, but is in one place connected without having to constantly copy and paste.

And that that's the easy pitch for a PM.

Grant: It's cool. And you're saying they're connectors as well. So they're going to bring it to engineering.

They're going to bring it to design. They're going to bring it to all of these different folks who they work with because they are very cross functional as well.

Shishir: Yeah, that's right. And they're innovative in this interesting way.

There was a, actually, maybe we may talk this a little bit later, but we shipped a feature recently, which allows you to publish a Coda doc as a webpage.

And so you can, you know, not only share it with the world and share it with your teams and so on, you hit a button and it publishes, and it looks like a webpage.

Like it's reformatted to look like a webpage and what we call pages become your top nav.

And it looks quite elegant. And a lot of it driven off of much of my learnings from YouTube and how incenting makers to publish their work outside of their immediate universe will drive a whole ecosystem.

Worked on YouTube. Same formula here.

One of the ones that got shipped a couple of weeks ago that I really liked was, Yuki Yamashita is the chief product officer at Figma.

Figma is a collaborative design tool. Were big users of Coda. Actually turns out we were their first customer, which is a fun story.

So Yuki publishes this doc on how Figma runs product and you know, they run their product system on Coda.

And this doc is awesome, right?

It's a methodology for how he does it. And it's written like a blog post, right? It's written like full of insight.

You could just read it and be inspired.

And then it's got a set of sections that are the sort of implementation that if you want to copy and use it, you can use it.

And actually it turns out that, that doc is super popular and we've had dozens of teams copy it and use it.

But he's got all these little hacks and techniques in there.

So like, he has one for their launch review meeting.

So they have this meeting they do, where they go through the status of all the different upcoming launches.

And he has two columns on there. One is a with buttons. One button is ask a question.

And so you hit this button and you can ask a question about that launch.

And he has another one that is a heart, which is just, I love this launch.

And the question one, you can hit once, the heart one, you can hit an infinite number of times.

And it's just like a fun, little trick for running his team the way he wants to run his team.

And it's awesome. Like it takes out what is a painful meeting, right?

Like launch reviews sucks. Like is that thing on time? Is it not on time?

And it turns it into a celebration.

It's like, hey, here's a way for you to give a little high fives to your colleagues and be really excited about things together.

And so the interesting thing about PMs as an audience is, you know, they're natural horizontal tool seekers.

They are natural connectors, but they are also natural creators. I mean, they build products for a living.

And so if you give them an ability to craft a process, they know one of the lines I use a lot is, the great Coda users.

Like, let's take meetings as an example, I have a whole writeup on how to think about meetings in Coda.

I say, You should spend the energy to craft your meetings like you craft your apps.

Think about the incentives, think about the value propositions.

Like you would, you know, you would never build an app and not think about onboarding, not think about retention, not think of like, you have to think about all those things when you're build an app.

So think about it for your meeting.

Like what incentive do you want? Do you want people to be happy or sad?

Do you want them to be engaged? Do you want them to be retentive?

Do you want them to come back? What do you want?

And I think like Yuki's example is a really good one where he constructed it like an app.

And so now, he's published it to the world and it's gone from, if you follow that journey, it started as a document, which is like just an interesting set of ideas into an implementation for his team into a published application, that is really like a piece of software.

And we get people that write in and say, "Hey, I deployed Yuki's system."

Like this is now an app that like, he's become a software developer.

And I mean, I think that's really interesting and inspiring, but it's sort of a shift in how you think about software.

Grant: Yeah. With, Replicated, we often talked about sort of like self-documenting products, but like, this is kind of the opposite thing, where you're kind of like the documentation is almost like the foundation and then the, like the product of the application is kind of built into the documentation.

Is that, does that make sense?

Shishir: That's right. I mean, I think it's basically-- Let me back up for a moment.

I get asked a lot about the transition from YouTube to Coda.

And the, "How did you go from media business "to enterprise software business and so on?"

And I often tell people like, in my mind, this is totally linear.

Like this is, I find myself applying YouTube lessons all the time.

And in my mind, the reason is because the thesis is so similar.

Like if you go back, YouTube, the thesis was online video is going to do a cable, what cable did to broadcast.

And we're going to see a, I gave this talk about this.

I joined, when I joined YouTube, I gave a talk a few months in, in New York and I made this bold claim.

You know, online video is going to do to cable what cable to did to broadcast.

And we're going to go, you know, we had three broadcast networks that became 300 cable networks that then became 3 million online video channels.

So that idea, you know, I gave this talk about it. And many people kind of laughed at it. Like that seems crazy.

You know, you're going to compare YouTube. YouTube at the time was like dogs on skateboards and so on.

You're going to compare that with ESPN and Disney. That's kind of nuts.

And the thing that most people missed about YouTube if I make that statement now, right, that online video will do to cable, what cable did to broadcast, it's just kind of obvious.

Like that, it's done. It happened. But at the time it was not obvious, right?

And the reason was people dramatically underestimated makers.

Their viewpoint was, there's just no way that a random person can build something that compares with the ESPNs and Disneys.

And the thing that they underestimated was people's ingenuity.

They underestimated that a creative person with a great idea, doesn't need to live in LA, doesn't need a film degree from USC, doesn't need that the most expensive camera, they can probably build something amazing.

And podcasting being a great example of that too, right?

Is the advent of what we're doing right now, you know, and the fact that anybody can do it now changes the dynamics and says, it's no longer about the technical expertise.

It's now about the ideas and the thoughts, and that's actually what drives it.

So in my mind, what we're doing with Coda is we intend to do to software, what YouTube did to video.

And we're going to dramatically democratize the types of makers who can make software.

And I think, you know, sitting today and saying that, that sounds nuts, just like, you know, saying that with YouTube in 2008, it sounded crazy as well.

But if you fast forward 10 years, I think the hard part about building software will no longer be the technical parts, it'll be the idea.

And the idea that, you know, these like the, the doc I was describing with Yuki is like, it was, feels like a blog post.

Sometimes I describe it as a productized blog post.

That's actually what he shipped, is a productized blog post is, that'll become quite commonplace.

Like the hard part in building software will be the idea.

It'll be the incentives. It'll be the structure. It will be the insight. The rest of it is easy.

That's not the part that your audience really values. Actually, I'll give one analogy for this.

I forgot if we've talked about this before, about Brett Victor, and I really loved the story.

So Brett, for listeners that don't know Brett, go search him up. He's one of the most prolific writers of our time.

Brett is an ex-designer from Apple, and he writes about all sorts of things. He writes about design.

He writes about computing. He writes about education.

And he's got this piece that has really stuck with me, where he talks about Roman numerals.

In the middle of a piece about computing and what's changing with software.

And so the analogy he gives is, have you ever tried to multiply Roman numerals?

And you know, it's funny whenever I give a talk about this, I'll ask an audience, "You know, have you ever tried to multiply Roman numeral?"

And you know, inevitably some smart ass in the room says, "Yeah, I can multiply Roman numerals."

But the truth is most people have no idea how to how to multiply Roman numerals.

It's really, really hard. And Brett's analogy is, well, think about it.

For generations, for centuries, that's how people did multiplication.

If you had to figure out how much taxes you owed, you walked up a hill to this person who is specially trained, probably had a long white beard and they multiplied your, you know, went up with your tablets, they multiplied your numbers for you.

You walk down the hill and you paid your taxes. And multiplication was a very specialized skill.

And then Arabic numerals came out and all of a sudden we teach kindergartners and first graders how to multiply.

And his punchline, his point is that the problem wasn't that multiplication is hard.

The problem is that we had the wrong abstractions. And the wrong abstractions had held back mathematics for centuries.

Now think about that applied to software. Like that could almost entirely be replicated in software.

What does it mean to actually build a software today? Software is full of its own form of Roman numerals, right?

It's like, you have to know how to deploy software. What are all these different packaging tools?

You have to know where the semi-colon goes in every line. Like, why would you use semi-colons?

That's easily dumb. All these archaic inside language of what you need to know to build software.

And if you could just change the abstractions, then people are going to take a thing that, you know, you have to be specially trained to do, and you have to like live on top of this mountain and so on, and we're going to enable anybody to do it.

So, you know, sort of back all the way up, you know, the view if everyone were successful with Coda, we're going to do to software what YouTube did to video.

And the key reason for it is that the maker ingenuity already exists.

The thing that's missing is the right abstractions and it's our job to provide those building blocks and those abstractions, so people can actually express themselves.

Grant: It's interesting, the approach you've taken, which is that, okay, the right approach is not--

Because I guess in my mind, there's another angle to this, which is people could probably use applications throughout all of their, you know, things they do in their lives, not just their work lives.

And yet Coda seems to be a bit more, you know, so let's solve this in the work world first, is that right?

Shishir: I mean, we have a lot of people use it in their personal lives too. I mean, I certainly do.

And actually, if you go to the gallery and search my name, you'll find a whole bunch of examples.

I tend to publish a lot of my personal examples. How I run my to do list and, and so on.

Or even things inside the family, is how we do our habit trackers.

And, you know, it's like, it's one of the interesting challenges of building a horizontal anything.

I mean, it was challenging at YouTube too, right? I used to get asked a lot, "Like what's the target audience for YouTube."

And say, "I don't know, everybody." And he said, "No, really what is it?"

And we would always have a focus.

And there was always a focus point, but a horizontal platform naturally leads to a very wide set of use cases.

And, you know, I think, over the years I've developed a level of pattern matching of entrepreneurs.

I sometimes put them in the buckets of platform thinkers versus product thinkers. And there's nothing wrong with being either, but product thinkers tend to think all the way to the end for the customer. Steve Jobs was the classic best product thinker. Like in his head, he was going to design every element of how the product worked and leave nothing to chance for the user, down to putting screws in the Mac that nobody can actually unscrew.

He's going to, you know, down to shipping the iPhone without an app store.

Like he was going to build everything. And on the other hand, there's people who are platform thinkers.

And for better or worse, that's what I've become. Almost every business I've worked on is a platform.

And what you get used to in a platform is your market's going to lead you.

You have no idea. Like I would walk into work at YouTube some days and people would say, "Would you believe what this person did on YouTube?"

And I would say like, "Good or bad?" And I could go, "No idea."

I could be like anything. And some of them were insane.

Like you would never imagine that people would do these things. And same thing with Coda.

I mean, I'm just always surprised.

So we have a focus and we have a, you know, I always struggle to answer the question because, you know, we always pick us out of hero scenarios and we use it to, cause you can't make progress without defining scenarios and target personas and so on.

But at the same time, I just love the fact that Coda is used for everything.

And we have people, you know, doing everything from running workouts to do lists on Coda, but the target use case tends to be product teams.

Grant: And then do you think of it at all as a marketplace?

I mean, I know you have sort of this gallery concept and creators and can sort of, I don't know what to call the other person who's not a creator.

Shishir: We call them makers and contributors.

Grant: Okay. I mean, but like the gallery stuff that you do, right?

Like you think about, you put this much more at the heart of the concept than, you know, Google docs and templates or all these other things that sort of semi exist out there.

And this idea that you can, you know, create and copy and sort of like remix these a bit more, is that at a foundation, like super, super, super important?

Or is that like just a side part of, okay, when you're building these apps, other people can copy your work?

Shishir: No, it's closer to the foundation for sure.

I mean, certainly compared to, it gets compared a lot with template strategies.

And I always have to clarify like, "Yes, I know Office has had templates for a long time and, you know, Google docs has a set of templates. That's not really what I mean."

'Cause you know, templates are generally written by the team. They tend to be pretty simplistic.

They tend to be lacking in opinion. You know, one way to think about it is Coda has a sort of core product, as a horizontal product, is a mostly opinion free product.

I mean we have building block opinions, but the whole idea is we hand you building blocks.

You can do whatever you want with it. On the other hand, when you go to coda.io/gallery and you get to people's docks, they are the exact opposite.

They're incredibly opinionated. Like down to almost extreme levels. Like if you go read my to do list example, you read Yuki's example for how he runs his product team, you know, it's very specific.

Like this is how I think you should do it. And in my mind, that's the right mix.

Like I think most templating systems that get built by horizontal products are solving a different need.

They're really saving time. They're saving steps. They're not about insight.

And so that's the pair in my mind. And they do go together.

Like I think the hardest part about building a horizontal product, like you open up Coda from scratch, it is a blinking cursor on a blank screen.

It's about the most like terrifying, you know, for many people the most terrifying spots to be. It's like, what do I do?

Like, I don't know where to start. And you have to simultaneously learn this product and figure out your insight.

Like what am I trying to do?

And so what most of our users do, they head over to the gallery and they get inspired and then they come back and sometimes they use those creations directly and some of them are built to be templates, but many times they just get inspired and they come back and they build something off of it.

So it's a core part of our strategy.

Not because I think everybody's doc should start by copying someone else's.

It's not because remixing is the only way to build Coda docs. It's because I think when you're building a new platform, these opinions really matter.

And I think the best way to get these opinions out are in this form.

And then as I think about my broader sort of viewpoint of what I want this platform to achieve.

You know, if I think that with Coda, we're going to do to software, what YouTube did to video, we need to enable people to express those opinions and get got to kind of frictionless loop through it.

And I would say that part of the journey is just starting.

And we shipped the gallery just a few weeks ago and I mean, it took off like wildfire and tons of docs published and lots of viewers and lots of positive feedback and so on, but it's very early.

And I think that part of our journey, I think much more of that's story's still to be written.

Grant: Got it. It's funny 'cause there's just so many angles, right?

There's so many like different sort of, you have these different user personas that you have in terms of creators, collaborators, like administrators, like there's all these different folks.

And you know, if you think about all the different entry points to which someone can use this, how do you think about that from like a product management perspective?

Do you have different product leads that sort of focus on different personas? How do you manage that?

Shishir: Yeah, I bet. So in terms of product development and personas.

Yeah, we tend to work with a sort of hero use case at a time and we sort of pick one and say, "Let's just make this one better."

And one of the values in the Coda values list is we build building blocks.

And what we mean by that is even when we're targeting a very specific, solving, a very specific problem, we try as hard as we can to build as a composable set of building blocks.

You know, back to the Brett Victor analogy, this is Arabic numerals, not Roman numerals.

And so we, we'll have a target and you know, usually very specific.

Like this is the set of users. These are the types of use cases.

You know, jobs to be done and problems to be solved.

Here's what their today world looks like. Let's make this better.

But as we do it, let's build building blocks that are going to work for every other scenario too.

And then let ourselves be surprised. What do people do with it?

And that's our product development philosophy. And I think it generally shows through positively in the product.

Grant: Yeah. Okay. That makes sense. I mean, look, this is super interesting Shirshir.

I'm, you know, really blown away by, you know, what you've done in your career.

So many different projects, different things.

And I think the lessons, it's interesting to learn from and how you've applied and reapplied and taken, you know, these things from different places and brought it into seemingly unconnected industries or unconnected problems.

But, you know, I wonder if there's any last advice for founders or folks who are listening. I'd love to hear it.

Shishir: I think most of the insights and trends were probably well covered.

I mean, if I had to give some parting thoughts, I mean, in terms of, there was a lot of questions and discussion about career and it's probably obvious to see how important I think it is to follow your ideas, follow your passions.

Follow, you know, when you spot those things, you know, ideas that might seem obvious to you are not necessarily obvious to the rest of the world.

When those things happen, it doesn't happen often.

And in my career, it's happened a couple different times over the course of a couple of decades.

When it happens, you have to follow through. That's when magic really happens.

And you might join a company, you might start a company.

You can tell from my background, that didn't necessarily mean starting companies, but some of the most fun moments in my career were allowing a crazy idea to flourish, just a bit.

Besides that, I think hopefully lots of practical tips and lessons on how you build products and think about ecosystems and so on.

And you know, and on the Coda front, I hope your listeners are as excited about Coda as I am.

I think, for me, a lot of my career's kind of building up to this. It's a thing that back in Centrata days I wish I had.

And when I got to Microsoft is what I was trying to build.

And you know, got to YouTube and got inspired by the types of things that might be possible and how a maker ecosystem could work.

And I'm just having an enormous amount of fun. I mean, I get to spend my days building blocks for the future of documents and applications.

And my evenings writing docs that feel like apps. So just an enormous amount of fun.