Introduction

Patrick: [00:00:49] My guest this week is a good friend and business mentor of mine. Chetan Puttagunta is a general partner at Benchmark Capital and has a remarkable track record of investing in early-stage software businesses including several like Mulesoft, MongoDB, and Elastic that went on to be public companies. Chetan has been my key guide for understanding the world of enterprise software as we at O'Shaughnessy Asset Management have built an investment platform called Canvas. His advice has been critical to our early success in software. In this episode, we explore the history of software and software investing and go into the details on how to build and grow new software businesses. We discuss product, sales and marketing, recruiting, scaling, and everything in between. Please enjoy this great conversation with one of my favorite business and investing thinkers.

Non-consensus and Right

Patrick: [00:01:33] Chetan, let's start with a very specific story, one of Benchmark's founders Andy Rachleff is famous for this non-consensus and right idea to make any money, and everyone nods their head at that. I think it's hard to realize what non-consensus feels like in the moment, so I'd love to start with the story of how you found the company MongoDB, which if you look it up today is probably like an $8-billion-dollar market cap stock. Let's start with that story. We're going to talk using that as a springboard about the history of compute and database, some wonky stuff. So, start with the story of MongoDB and how you found it.

Chetan: [00:02:04] Yeah, look, I invested in MongoDB in 2012 and when I first met Eliot, who's the founder of MongoDB, I was funny enough, 25 years old, and I had had a lot of experience building consumer apps. The App Store launched in '08, the iPhone, of course, famously came out in '07, and it was really hard to build applications at that time because the technologies that were freely available or openly available to developers were frankly limited. And if you take a step back and looked at what the leading technology companies had at that time, they had built all these incredible proprietary libraries and proprietary technologies, and if you asked your friends that were developers at Google, they had access to all these fancy databases, all these fancy tools, and new libraries. Talk to your friends at name your big tech company at the time, it felt like there was a distinct advantage between those that were trying to do something, start a B and trying to do something on their own versus working in a large company, and at the same time, there was a vast and rapid growth rate in the number of developers coming online.

Those are things that are always on my mind, always felt like, hey agility and productivity was really, really important to developers and so when I met Eliot, he had this huge vision because he, himself, came out of DoubleClick and experiences himself of not being able to move fast enough to address customer needs, and the customer in his mind was his internal company. And so he had this vision of building a database that was a general-purpose database that was super easy to get started, and that was the primary wedge into the market, which was that if you wanted to prototype something, if you wanted to get started really fast, if you wanted to see the initial version of something really quickly, let's get it out there, and once it gets traction, we're going to figure out how to do replication and scalability and all that stuff. We're not going to start with these call it traction problems, we're going to start with let's get you to iterate faster. And this is really well before agile became something that was pretty instrumented across tech teams.

So, that resonated with me immensely. But if you had asked, and I did ask, the best developers that you knew at the time, ask them to play with Mongo, they would tell you, "This isn't something I need. Have you tried MySQL? Have you tried the established databases that are out there? Here are all the features that it has, why would you ever have MongoDB. I'm a database expert, I know how to make MySQL work for everything, there's no reason why you need this." But you missed the entire need of the entire class of developers that wanted something where they didn't have to think about schema, where they didn't want to have to plan how the database would look at scale because they had no idea whether the application they were working on was going to work or not.

So, I'll give you this example where I went this rabbit hole of trying to create a consumer app and spent so much time on the schema itself for a relational database, put the app out there and it was an absolute failure, no one cared, but I wasted all this time on schema planning.

Patrick: [00:05:36] You could have learned less and far cheaper.

Chetan: [00:05:38] Yeah, exactly, and so-

Patrick: [00:05:39] And faster.

Chetan: [00:05:40] And so when you have a fundamental piece of technology that every application needs a database, that allowed you to have very cheap mistakes and learn really cheap lessons, it just really, really resonated with me as something could be fundamental in terms of where compute and application development was going to go. And what you saw because it was an open-source company, very quickly you saw this huge groundswell momentum of MongoDB where a lot of developers started using it to get started fast.

Now, what had ended up happening, actually, that is it got too popular and the population of developers started to use it in production and started pushing the limits of the database itself, and so there was this interesting blow-back that happened, where there was a period that was actually quite rough, where folks were really upset about what would happen with MongoDB at scale. And classically, everybody says that it takes about 10 years to develop a really mature database, and the company's first code commit was in 2007, and so it took a bit of time to bake, and by the time you got to 2015, 2016, the database was very mature and could handle scale, and you could push it into production with millions of users, with transactional data. And so there was a rough period that the company had to work through, but when it got to the other side, it ended up being right place, right time, and sort of the first real database challenger since frankly, Oracle, which was started in the '70s.

And if you go back and look at that, it's all with this idea that development was going to get faster, which in 2019, sounds like a very obvious idea, it's like, "Yeah, of course, that was a thing." And so, going back to that non-consensus and right, to bet on development going faster today, is very consensus. But to say in 2012 that that was going to be a primary driving factor of a developer-focused database, that was very non-consensus.

Patrick: [00:08:00] You mentioned a lot of terms that maybe some people are like, "I don't know what these guys are talking about." Even the basic idea of a database, so it might be interesting even though at risk of getting a little wonky, I'm just fascinated right now by the history of computing, and the sort of what I would call the primitive pieces of that technology stack where database is a key part of that. So, maybe starting with database, we might even go into a few other aspects of the history of technology and computing, but starting with databases, what are the relevant chapters of that history? I would conveniently say like a database you could think about a big Excel spreadsheet or something, might be a super simple database, but what the hell does that mean beyond columns and rows? What other features matter of a database and who have been the big players in that historically?

Chetan: [00:08:41] I think if you looked at simply the history of Oracle it would give you a very good sense of database business because they, frankly, built a much bigger business around a database and what that allowed them to do over time, which is really interesting. So, one of the things that Oracle did was built a great database business and then moved into the application tier with applications that were built on the Oracle database, and so they served the CRM application, which became a huge business, they served an HR business, ACM business, which, is of course, PeopleSoft, which was a huge business, so they had all these applications on top of the database that were using the database technology to serve those applications.

So, Oracle was founded in 1977, and Oracle itself became a true database leader in the '80s. And the way Oracle was structured is it's a relational database with columns and row. You know, a way to think about it is like big sets of table and row and it can be huge. And one of the powerful things about an Oracle database is that you can join really large datasets and then query against it using SQL. And one of the benefits of SQL is that it's actually a very widely known language for both technical and non-technical users. So, not only do developers know SQL-

Patrick: [00:10:13] I spend my of my queries in it.

Chetan: [00:10:15] Exactly, so analysts know SQL. It's become super pervasive as a query language to access the underlying data. That really propelled Oracle for a really long time. We're talking about a company that was founded in 1977, and we're talking about Mongo in 2012, I mean, think about that run. That's fairly unprecedented in technology that you had one company behind one technology concept that had that long of a run of dominance. And I think that's because databases themselves are really tough technologies.

Patrick: [00:10:54] Why?

Chetan: [00:10:55] Well, because a developer can do whatever they want with a database, and the database is one of those things that's a truly general purpose technology, and you have to make a database accessible regardless of what you want to do with the application layer. And so, making a database useful in such a general purpose form, there's a lot of things that happen once you start putting data into a database, around security, and auditing, and all of the things that make it hyper-sensitive, and hyper-critical, all the technology that needs to wrap around a database is really hard to build, and making it scalable, making it useful, and there are a lot of attempts to build very functional specific databases over time. So, you saw analytics databases, or you saw a very high-performance databases, there were databases that were geared very specifically to high-end financial services, for example. But building this general used-case, applicable to anything you want to build is a really, really hard problem. You have to have a new approach, the timing really matters, you have to have something that really is propelling it to how people shift.

I think what helped Mongo was really two things. One, people wanted to move faster, and two, this is where relational databases, unless you were a relational database expert, you started hitting the constraints was because these databases were designed in the '70s and '80s when there wasn't a lot of data, the idea of throwing sort of an infinite amount of data into a database was not something that people thought was going to happen or was reasonable because if you just think about the petabytes of data that's generated second by second basis today, especially if we looked at the amount of data that's been generated out of social, for example, it's unstructured data, a lot of data that you didn't know when you started the application that you wanted to actually store because the user wanted it stored. This trend of not knowing what the data is going to look like, either the shape, or the volume, or the size, is a fairly modern concept. And so, the idea of web plus mobile, changing how user and applications were pushed created this very specific moment in time that really allowed Mongo to run.

So, market timing has a lot to do with it. You could've been right and predicted that this was going to happen, and if you invested in something that was started in 1992, it wouldn't have worked.

Patrick: [00:13:41] It seems like since then, there was CockroachDB, there's TimescaleDB, there's all these other database technologies that have come since this incredible run of dominance, what is that about? Is that just something that was cracked open by Mongo and a realization like oh, we can build more modern technology for more specific used cases?

Chetan: [00:13:58] That's right. I think what has happened now is because of the cloud and developers being so open to understanding new database technologies, it's now become very much about, okay, I'm building this specific used case, and I know what I'm going to build when I start, and I need, for example, if you needed a globally scalable database that's relational, Cockroach is the best thing you can use. And let's say you're building and IoT application for time-series data, Timescale is fantastic and highly performant for that used case.

And so, what's become clear now for both entrepreneurs and application developers is that if you're going in and have a very specific used case, there are now more specifically tailored open-source databases for you to use. And I think the other thing that's happened is that as software becomes more predominant across industries, and sectors, and use cases, these markets have actually turned out to be a lot bigger than what most people anticipated. It's really funny to read the initiating coverage of Salesforce when it went public in the early-2000s and to see what the estimates of Salesforce's potential addressable market are, and then today, Salesforce itself has $13 billion of revenue, and Salesforce would argue that they're less than 20% penetrated into their core markets. And so, these markets, these software markets actually ended up being orders of magnitude larger than what people thought they were. I think the people dreamed very aggressively about what software could do and how pervasive software would be used, but that dream was actually not big enough, which is surprising because that doesn't usually happen.

And so, as software just pervades use cases, and you've had a lot of experience with this in terms of bringing software into asset management, you're moving basically manual workflows or things that were done on paper, or in Excel, or whatever, into specific software, and that requires a whole bunch of new thinking around the infrastructure and the application layers. And so these markets are actually, orders of magnitude bigger than we assumed they were.

How Deeply Proliferated is Software

Patrick: [00:16:18] Let's talk about this from an investor's viewpoint, so this has been mostly from like a user's standpoint or something, or a technology standpoint, your job is to be an investor-

Chetan: [00:16:27] That's right.

Patrick: [00:16:27] ... and invest in mispriced securities, maybe when they're not as appreciated as they one day will be. We just turned a decade, it's a fun time to talk about sort of the future of all this. How penetrative do you think we are? Maybe talk a little bit about, you and I have discussed the number of developers and how that's growing, the penetration of software, generally speaking, a lot of times I think bets on companies like this has bets on the proliferation of software through other industries, what inning are we in, whatever stupid sports analogy you want to use, what yard line are we on? How do you think about this as an investor? What is the opportunities that look like in the 2020s?

Chetan: [00:17:00] I think I go back to what our partner Matt Cohler often says, which is that our job as early-stage investors is to see the present very, very clearly and not predict the future, which is an odd thing to say as an early-stage investor specifically because you would think, well, as a public investor that's obviously the case, but as an early-stage investor, I think that's a really interesting way to look at the world. You just have to actually watch what's going on in the world to understand what's going to work and what's not going to work. It's not about predicting 10, 15 years on the road because I think if you try to predict the future, you're going to mess up timing, and you have to see actually like ground truth of what's happening today.

And what's happening today in enterprise software is that every single large enterprise, no matter what industry you sell into or what vertical you sell into, realizes their future of their business is going to be powered by software in some way. Companies that you may not have thought of as being big consumers of IT are now big consumers of IT. For example, Caterpillar buys a lot of software. The pharma companies buy a lot of software. Financial services companies buy a ton of software. Shipping companies now buy a ton of software. So, the buyers of software are just increasing every single day. That's an interesting trend to pay attention to.

Number two which you alluded to which is just the number of developers in the world is still a tiny fraction of the number of knowledge workers in the world, and so, it feels like very under-penetrated in terms of the number of developers that are going to be in the future. And then third, which I think is particularly interesting is if you look at the global IT spend, which is on the order of a trillion dollars a year, a lot of it is still contained in the on-primed world. So, the move to the cloud, we're still on the very, very early innings of that cloud, and if you look at the number, the amount of capital or dollars deployed against services against IT, it's-

Patrick: [00:19:13] A pimple.

Chetan: [00:19:14] ... it's huge. And so, what that shows is that there's still a lot of energy expended against custom, manual point-to-point solutions that's not the right way to build scalable systems. And to date, a lot of software has been solved by throwing either professional services against it or manual solutions that aren't particularly scalable. And so, when there is a start-up or a software company that builds a general software application for that particular use case, it actually increases the efficiency of every single customer that uses that system. So, I think it's pretty clear to see today, but it wasn't that clear 20 years ago, that Salesforce building a cloud-based CRM system was way better than every single company building a CRM system on their own that was tailored to their specific need. Actually, it's great to have a general purpose CRM system, and what that then led to is Veeva built a CRM system for the healthcare vertical and created a multi-billion-dollar public company out of it, on top of Salesforce.

And so it's like you can create a vertical application on a generalized application, and create a multi-billion-dollar company on it. And so those are really fascinating things that are happening today. And it's not like the growth rates of the large cloud companies, if you look at the application level, like Salesforce, Workday, ServiceNow, Atlassian, those growth rates are still really high on very, very large numbers, and then you move one level lower in the infrastructure tier and if you look at the growth rates of AWS and Azure and Google Cloud, we just saw the Azure earnings release from the last quarter and it was 59% year-over-year growth.

Patrick: [00:21:10] Off a huge base.

Chetan: [00:21:11] Off a huge base. Which is just astounding to think about, and what that means for the overall addressable market if one of the top players can still grow nearly 60% year-over-year on large numbers. So, I think we're still all very, very early in this, and that's not to say that every enterprise software start-up is going to work. I think that's far from what's going to happen, but there are still lots of opportunities to build really large, meaningful enterprise software companies.

Patrick: [00:21:45] So, I'm going to ask a series of selfless questions that will also allow us to sort of recap our interesting relationship which is around building software. So, it hasn't come out yet, maybe it will come out by the time this is released. In my annual letter to investors that everyone's obligated to write in my industry, I talked about how, I just felt like every company would benefit from building client-facing software, mostly because of how intimately it allows you to know your customer in a way that you just can't do if you just ask them questions. If you show them a system that's helpful, I find they start to project their real problems that they wouldn't just reveal to you otherwise onto the software. So, I'd love some general advice for you about two business owners, let's say, about how to think about building a piece of software from the product side, I want to talk about go to market. You've seen a lot of examples of people trying to do this. For all the reasons you just laid out, I think this is a white space for a lot of businesses to introduce software into their business model, so let's start with the do's, we'll also do the don'ts. What will be some general product advice that you'd give for a firm that's got some edge in some way and wants to build some software?

Chetan: [00:22:50] Well, we talk about this often, which is that if you think about the customers that you could potentially serve, they have a job to do every single day. They come to work every single day to do a task, whatever it is. And so, their job is to accomplish that, not to become an expert in your system. And I think that's often forgotten, which is that I'm going to build this amazing solution, and a user's going to be able to figure this all out. No. They don't have the time for that. And it's often, I think really interesting to examine ourselves and how each of us individually interact with software, we each get into sort of our own workflows to accomplish our day-to-day activities, and when a new tool is introduced into that workflow, there are only so many walls you're willing to put up with before you just say-

Patrick: [00:23:40] Argh.

Chetan: [00:23:41] Yeah, this isn't making me faster. I don't have two hours to learn this. I'm out. And so, if you have that context in mind, which is that whoever you want to put software in front of has a job to do, and their job is not to become an expert in your solution. I think it creates another level of empathy around user design, and how to build products that are good at accomplishing something, and if you listen to the Kevin Systrom and Mike Krieger podcast that you did, they often talk about, we were building something inside of Instagram for consumers to do a job. And I think that's very applicable to enterprise software as well, which is that if you're building a platform, or an application, or a tool, or infrastructure software, it's being built to do a job for the customer, and it's being built to let the customer accomplish what they're doing day-to-day faster, or easier, or with less effort, but it offers some clear value proposition and clear benefit for the consumer that's buying the software itself.

So, I think it all comes back to you're building a solution that's solving a problem and not the other way around. You're not building a solution that a customer then wants to be an expert at. So, if you have that sort of macro-empathy point of view, it solves a lot of decision-making along the way.

Empathy-Led Product Building

Patrick: [00:25:07] It's clarifying instantly. You just know certain things you won't do. How have you seen companies that have done this, we'll call it empathy-led product building, or something? What are the tactics? What are the specific ways that this can be effectively done versus just saying "I'm going to make sure it's easy to use?" It's easier to say but probably harder to actually flesh out. So, how long does that often take the companies working with real customers? Some of the things I've been surprised by talking to you is just the sheer length of some of these timelines. What have been the actual effective methods of doing this?

Chetan: [00:25:37] Yeah, there's two methods that we've often talked about which can be encompassed by a simple phrase which is go slow to go fast. And this form takes two very specific approaches. One, at the very beginning, if you're building a software solution, really focus on a very small number of relevant users and build product against those relevant users and their needs. And so, if you're working in a vertical industry, for example, you can call them lighthouse accounts, or major accounts, or focus customers or whatever you want, and that could be as few as five, or as many as 10, and you're addressing the specific needs of those customers, except you're addressing them to the point that are generally applicable to everybody else in that focus market, and not custom to the very single customer. So, there's a point at which software development goes from software development for the platform to custom services to the customer. And if you're building custom services for the customer that's not extensible. That's sort of like a very clear demarcation line of where you can build functionality up to and then that's professional services on the other side of that.

And so, this idea of user-led software development is super powerful in enterprise software because ultimately in enterprise software you have customers that are buying your product to do a job, and more than not, they're willing to tell you exactly what job they want to hire you for and hire your software for. So, that's a great place to start, the idea of focus customers/lighthouse accounts and building to the line of generalizable application.

The next approach that I think has surprisingly gone out of favor in the world of enterprise software is delivering professional services early on to your customers. So, if your customers are running software on prem or have manual workflows, they're going to need help migrating all of that onto a software system, and professional services is a great way to hold your customer's hand as they transition from whatever their workflow is to your system. And often times, more than often, customers want to engage with an early-stage company with a services contract initially versus a software contract, and I think it's become the norm to turn down those services engagement because services revenue is seen as bad revenue or low-quality revenue.

But what I often encourage entrepreneurs to think about is that a services contract is actually a commercial engagement with that customer that then allows you to build a trusted vendor relationship with that customer, and then over time, you can transition that services revenue into subscription revenue. Again, if you use this construct that you're only going to deliver services that then benefit your platform, you're not becoming an outsource software development shop for your customer because that's not the end goal hopefully for your customer. If you want to be a services shop, great, or if you want to be an outsource development shop, great, but if you're trying to build a generalized software platform whether it's an application or infrastructure you can deliver services to serve as the initial customer engagement point for your customer to build a trusted relationship with you and get them trained and exposed to your system so then that then becomes software revenue.

And two examples that I think are really instructive are one Workday and Veeva, which in the early days of both companies, nearly 50% of their revenue was from services, and it was because they were going into enterprises that had very entrenched systems. For example in a Workday's case they were running large installations of on-prem software called PeopleSoft, and in Veeva's case, they were either running custom home-grown systems or using some other on-prem technology to do CRM. And so, to migrate from that into a cloud application required a lot of handholding, required a lot of training, required a lot of data migration. And these professional services contracts actually allow you to build these customer training tools and customer migration tools that then can be used against the next customer to help with that migration and training process go much faster. So, going back to it, I think that services done right for start-ups is a huge advantage that simply should not be ignored.

Patrick: [00:30:29] Got a couple of questions on both those kind of general strategies. So, first on the user-led innovation. I get the idea of not building below a line of extensibility, meaning just the acid test of would this also be useful for the other nine customers in my initial cohort? And if the answer's no, don't build it. But how do you know, or how have you seen companies manage the problem of the old Steve Jobs thing, no one's going to tell you what to build, you kind of have to figure it out, any thoughts there on literally just asking what to build versus sort of trying to build a Venn diagram of your expertise and their questions and sorting it out that way?

Chetan: [00:31:01] Yeah, this is the really interesting part that we see every day in funding early-stage businesses is that these entrepreneurs that come up with a very unique insight about a market, and that unique insight either comes from having fresh eyes in a market and saying why is this being done this way, or it's someone that has a lot of experience building solutions in that market that says, "Okay, this is totally upside-down and this doesn't make any sense, and I have come up with a very unique insight as to how to address this problem." So there's two approaches that I've often seen is entrepreneurs that come up with really novel ideas to address a problem, and so in the first case, where it's a pair of fresh eyes that look at a problem and say why is this being done this way, what is pretty clear is that as soon as you figure out that new approach there are going to be a set of early adopters that completely agree with you. It's almost like you ask the question, "Why is this being done this way, shouldn't it be done this other way?" And you'll find this early set of adopters would say, "Yeah, you're right, that's exactly right, we should be doing it that way and we haven't been doing it that way."

A very specific example of a company that we're involved with called Duffel is exactly this, which is there's industry called GDS, it's a global distribution system for airlines to sell their inventory eventually to consumers. But the current system of how an airline sells a ticket or a seat to an end customer is extraordinarily convoluted and the number of players that touch the system and the number of flows that go through it is just simply astounding. And so, you had these entrepreneurs who came from the payment industry, which has a lot of analogies to the travel industry in terms of how convoluted those systems were, and we've seen a lot of innovation around payments, but simplifying those systems with APIs and micro-services and they looked at the travel problem and said, "Why is it being done this way? Couldn't we solve this?" And then they came with a unique insight and went to a set of early adopters that were airline themselves and said, "Shouldn't this system work this other way?" And immediately, you had a couple of airlines that said, "Yes, it should work that way. We absolutely agree." And those were your early adopters that then propel you to create a new industry standard.

There's a lot of approaches but one of the things that you can always fall back on is when you accomplish something for a customer or you're allowing them to make their business ultimately better, you will always find opportunity in enterprise software. Ultimately, every business wants to become bigger and more profitable, that's why they're in business, and if you have that understanding and you go and have a solution that will either increase revenue or increase cash flow, whatever it is, you will find adopters that are open to new ideas and then as you start getting customer proof points, as you start getting real case studies the momentum then builds and allows you to really redefine it in an industry which is super unique.

Patrick: [00:34:25] One of the things that we've talked about also is how this can require patient capital behind it because go slow to go fast, part one of that is go slow, and that's not exactly the I guess the revenue growth curves that typically later-stage venture investors or investors in general, would want to see. So, talk about that the importance of combining the right capital, hopefully, you're providing that and that's an edge. We've talked a little about investing edge but I think this is one source of it. Talk about how important that is.

Chetan: [00:34:52] I think that there has been a shift towards this very formulaic driven growth in enterprise software which is very unhealthy. There is a calculation of well here's my CAC, here's my LTV, here's my payback period, I'm ready to sell, let me hire 50 sales reps and let's push this into the market, and three years down the line all the assumptions that went into that formula of growth just start falling apart, your burden gets really high, and then, and then, and then, and you get into a situation where it's really hard to re-engineer yourself out of it. And one of the things that often happens in this evolution is that I find that folks forget that the reason they got into the business was they wanted to develop new technology. And they go from a what I call technology-driven business to a spreadsheet-driven business. And it's like when did you decide to become a spreadsheet-driven business? You got into this because you wanted to develop software. And so, that's the part that is the go slow to go fast, which is once you sort of cross that curve and are able to have a super-efficient business, you can do really incredible things.

And Greg Schott, the CEO of MuleSoft, who I know you know, if you look at what they did at scale in terms of capital efficiency, it's remarkable. They've earned something like $8 million to go from $100 million to a little over $200 million of revenue, and then burn $4 million to go from $200 million of revenue to $300 million of revenue. And ultimately, Salesforce acquired them for $6.5 billion and if you look at the Salesforce public filings, inside of Salesforce the company's actually accelerated top-line growth because they had built such a capital-efficient go-to-market system that was product-led.

So, if you take these lessons of mature companies and how they got to where they got to which and if you roll back history and you just look at where they started, and we talked about Mongo earlier, it's 2019, Mongo's first committed code in 2007 and they didn't really have real revenue until like 2011 and 2012. That's quite a bit of time from the initial sort of product development code commit. So, it's developing that product maturity that then allows you to minimize your cost of customer acquisition and ultimately, if you're building great software, LTVs should be infinite. And so software businesses end up working really well when you build mature products that a customer is then continuing to renew and cost of customer acquisition or CAC approaches zero, and that's a really challenging mental exercise, which is how can you build technology products that have a CAC of zero and that takes a lot of time to figure out.

Patrick: [00:37:54] The most impactful thing you said to me when we first talked about this was, basically the answer to that question which is it has to be product, and customer experience using that product. The only way for something to spread organically enough that CAC is close to zero is just an absolutely outstanding thing itself. There's no tricks to get you there. It just has to be authentic, kind of user-led, perfect, not perfect, as close to perfect product for the used cases possible. And then when you think about it that way, it's just incredibly clarifying, it just becomes very clear what you need to do. And then the race at least in my case is not getting worried about what looks like competition or what look like faster-growing revenue curves or things like that, and that seems like a huge scaling challenge. Would you agree that that's the case?

Chetan: [00:38:37] Absolutely. And oftentimes there's a conflation of competition because if you're building a brand-new software system, it's unlikely that someone else is building what you're building. And I think the great example is, in 2004, when Salesforce was selling CRM, their main competitor was Siebel. Salesforce's average customer contract was $12,000 per year and they were on average selling 15 licenses at the time. Siebel at the same time had an average contract value of $400,000 and was typically selling 1,000 licenses at the time. So, yes, they were competing in the broader CRM market, but I guarantee you that they rarely saw each other.

And so I think when you look at competition that way, which is sell where your competitors aren't and go deal with Siebel and large enterprises when you have a super mature product and have thousands of customers that are successful on your customer platform, and then you can actually have a really compelling story of why you're better than the biggest competitor in your market, versus assuming that that competition is there from day one and using manual selling techniques against that to convince customers that you're better than a competition that actually doesn't frankly exist. So, why not go build a solution or go build a platform that is selling to customers that aren't looking at the incumbent, for example.

And this goes back to the original point which was that these software markets are actually much larger than anybody assumed, and so the idea that you're going to run into competitors from day one is probably not accurate. What you're probably going to run into is objections to your own system because the system itself is incomplete and doesn't address the needs for the customer to do a specific job. And until later stages when you're going into bake-off for a $1-million contract or a $10-million contract, it's very rare that a customer is baking-off two solutions. Very, very rare. In the early stages, if you're selling a $10,000 contract or a $20,000 contract, they're frankly evaluating you against whatever custom solution they're using today, and so they're trying to accomplish a job with that. And so, it goes back to the point that just being hyper-focused in solving a problem and then being very patient.

Patrick: [00:41:08] Take your time to refine the solution.

Chetan: [00:41:10] Exactly. Creating product maturity. And prematurely scaling and then restarting is hyper-painful, and cash is ultimately, there's this obvious saying that the number one reason start-ups die is that they run out of money, which is a very obvious thing to say. But if you just examine that statement, it's like, right, cash efficiency is ultimately what matters as you scale a software business because that then gives you a logical equation on return on invested capital and return on invested capital against both R&D and sales and marketing, and those are the assets that end up returning over time, over a really long period of time. And you're seeing the compounding effects of software businesses with this recurring revenue model which is that as you create customer loyalty, you create natural expansion in the customer base.

So, if you look at the average contract value of Salesforce over a 15-year period, the average revenue per customer has compounded at a 15% annual rate, which is just if you think about it, is amazing over that period of time, but if you're building software today and somebody is paying you $1,000 a year for your solution, and if you deliver great value and you add modules and add functionality in a given year and you asked yourself, "Would my customer pay 15% more for what I'm giving them?" You'd get to a yes pretty quickly. You just say, "Yeah, of course they'll pay 15% more. In fact, they're thinking about paying 50% more or 100% more."

But the idea that you can just have this sort of 15% compounding rate over a really long period of time, because remember, as that contract value is compounding within your install base, you're also getting new customers onto your system, and so what ends up happening is what you see with Salesforce over that time period it went from $100 million of revenue to $13 billion of revenue, and they've done, of course, really strategic acquisitions during that period of time to make that compounding effect go even faster. But again, they've also generated incredible amounts of operating cash flow at the same time to give themselves the opportunity to go do acquisitions that has been increased revenue for customer over time.

So, the idea of growing your revenue within each customer 15% year over year doesn't seem like a lot, but then the challenge is well can you keep it at that rate for 10 years? Then all of a sudden the scope of the problems that you're solving become clear, it's like, "Oh, if I have to compound it 15% for 10 years then I have to solve real problems for my customer that will make me a trusted vendor in terms of how they do business for a really long time." So, I'm not solving point solutions for them, I'm solving fundamental business problems so that I'm actually their business partner for the next 10 years. So, that kind of long-term thinking and patient capital that goes along with it is something that we spend a lot of time talking about at Benchmark, and it's what I spend a lot of time talking to founders about as we go about the very difficult exercise of company building.

Patrick: [00:44:36] What are the most common reasons that you don't invest in may be what looks like a promising story founding team, business? And I'll go from there to sort of the don't. We've talked a lot about the do's, we haven't really talked much about things that cause people to fail other than this premature scaling idea. So, what would be the most common reasons that you knock somebody out from consideration when looking at investing?

Chetan: [00:44:58] Well, if you're not missing, you're probably not taking enough shots as an investor. And so, there are times that I've turned down investment opportunities that end up being terrible mistakes, and in early-stage investing if you make a mistake you lose one times your capital in terms of if you invest in a company or an opportunity that doesn't work out, but if you pass on an opportunity that ends up working out you miss out on 10 X, 100 X, even 1000 X in the rare cases, and that is, that's really painful as an early-stage investor. And especially where we're very, very focused on the earlier stages of company formation in terms of where we're investing where you don't have multiple bites or multiple chances at the same opportunity.

And I think one of the things that is pretty unique to early-stage investing is that it's a double opt-in relationship, when you are embarking on this really long journey of company building. There has to be resonance between the company and the partner in the firm about what's ahead, and when there's alignment for the journey ahead, you have a great working relationship to go solve the problems that come in every day. And often interacting with entrepreneurs that I work with in whatever mode of communication they prefer, whether it's text, or Slack, or email, or FaceTime sometimes, whatever they prefer, and it's a very low touch push-pull model where you become a true trusted business partner with the entrepreneur. And so embarking on that journey is a double opt-in decision where it's very different than public markets where you could go buy a public stock and build a really big position pretty quickly.

Patrick: [00:46:52] Never having met anyone.

Chetan: [00:46:53] Exactly, whereas, in the private markets it's quite the opposite. And so, there's sometimes where there isn't that alignment. And it doesn't mean we're wrong, we hope to be right more than wrong, but we're wrong, and we miss, and you feel really, really terrible about it, and you'll often refine your thinking, and you often refine. It's really good to also go back and reflect on the notes of why you decided this wasn't a fit, on why you weren't interested in the investment opportunity.

And one of the things that has become very clear to me being in early-stage investing for nearly 9 years now is that being open minded is super, super important. And this goes back to really a different way of thinking in terms of not being thematically driven in terms of what I want to invest in. So, I absolutely think that there are amazing macro trends in enterprise software, but if you tell me what are the 10 start-ups that you want to invest in this year, or next year, or the next 10 years, we as a firm invest in five to 10 companies, new investments a year, and each partner is doing one to two investments a year, and every time we invest we take a board seat because we believe it's a long journey. And if you were to say what are the 10 requests for start-ups that you have? It's zero because you have to be completely open minded to that insight that the entrepreneur has discovered and that insight is really spectacular when you hear it with a completely open mind. You also have a prepared mind about opportunities, of course, and who's looking for stuff, and that comes from just learning publicly or learning across your network, but I think just having a very, very open mind about what could potentially work is key.

Going Slow to Go Fast

Patrick: [00:48:48] We talked a lot about product and sort of R&D around product and the process for developing that to solve a very specific end-customer need, we haven't talked so much about beyond that initial product maturity. So, at some point you do want to scale fast, go slow to go fast, so when going fast, things like sales and marketing, and financing strategy, capital efficiency become more front and center. Tell me what you've learned about scaling, maybe starting with sales and marketing, enterprise software or soft more generally, so we'll keep marching this playbook here.

Chetan: [00:49:19] I think that you can often forget that at scale the business really comes down to a people business. Ultimately, every great enterprise software CEO will tell you if you asked them what went right, they'll tell you, well we got really lucky and hired these people that ended up just hitting home runs over and over again, and we knew they were super-capable, but they actually ended up being way more capable than we assumed. And so, Peter and I are on the board of Elastic, and if you look at the management team that the founders hired to complement themselves across multiple functions, whether it's product or engineering, or sales, et cetera, et cetera, those executives scaled incredibly well. They scaled from single-digits revenue to hundreds of millions of dollars in revenue and have a great runway ahead of them because they just continue to be these infinite learners that just keep going and you give them the necessary resources, you give them the necessary freedom, you trust them to make the right decisions, and when people deliver, it's just an amazing thing that creates this natural flywheel inside your company where you bring on really talented people, there's trust in the organization, they then bring on even more talented people, and then, and then, and then, and it creates this really positive effect.

I think that's the part that again, you go back to this theme of go slow to go fast is well how do you get it right, and the amount of time that you as a CEO spend time recruiting and how careful you are at figuring out what you need in running a very structured recruiting process is super-important. If you think about how to hire really successfully, again, it's often a double-opt-in process. You have to go find great candidates who then are interested in the company and then the company has to hire them, and then they have to join. So, it's not a one-way-

Patrick: [00:51:21] Not a sales team made, yeah.

Chetan: [00:51:22] Exactly, and so there's a lot of parallels between recruiting and sales, frankly, you have to build a really big funnel-

Patrick: [00:51:28] Pipeline, yeah.

Chetan: [00:51:29] ... and you have to have a really great process where the candidates that you're interviewing feel really good as they're going through the process, so very structured, it's very predictable.

Patrick: [00:51:40] Sounds like software.

Chetan: [00:51:41] Exactly, like the interactions are predictable and understandable, and it's a process that moving along, and you get to the finish line and you making this double opt-in decision. And the other part of it that's super-important in recruiting is, of course, references, which you have to do references on people and understand how they performed in their previous positions. And having that idea that ultimately, every software business, the only way to scale every software business is by having really great people in the business is something that we often just forget. It's like, "Oh, we're building software, so it'll just go." No, no, no, no, no. It's actually a people-driven business ultimately. And the people that come inside your company and join your company, often ultimately are the ones that scale. And every time you have to go back out to market, to get somebody or to replace somebody is actually a failure of that process. If the company miss hires or makes a bad hire, it's actually a fault of the company, and it's fault of that process that was run that led to not a great decision.

Patrick: [00:52:46] What stands out in memory of the most interesting or compelling recruiting pipeline strategies that you've seen companies employ?

Chetan: [00:52:53] Yeah, and so we'll go back to Mulesoft which was solving integration problems, enterprise software integration problems.

Patrick: [00:53:03] You're very specific.

Chetan: [00:53:06] In San Francisco, not a great way to stand out. How do you stand out as an enterprise software integration platform when you're competing with the likes of Google, or Facebook, or Apple, or whoever because if you assume that the labor market is limited, which it is, and if you assume that you have to be able to recruit really great talent, which is necessary for a company to scale, how do you then differentiate yourself? So, there's two things that are available to start-ups that aren't available to really, really large companies. One, is I think it's really exciting that you're seeing more and more start-ups embrace remote. So, talent is universal, embracing that the idea that great talent is actually global, number one, and two, also great talent is actually spread out across the United States and you have great developers really spread out through the country. And that you then from day one institute a culture that's very remote-friendly, and so you institute all the culture and understanding of how to operate a remote company. And actually, running a remote company at scale has very little to do with the software tools because remote companies were built well before they were remote work tools, and it goes down to the culture of how do you create work cultures that are remote-friendly.

For example, we only do meetings where everybody is on their computer. Everybody meets virtually, even if two people are in the same location. Having such remote-friendly policies so that the one person that is not in that room doesn't feel like they're interrupting, or trying to get into a conversation that doesn't feel natural, a lot of these practices. And then, also, too, writing down a lot. I find that companies-

Patrick: [00:54:55] Just written communication.

Chetan: [00:54:56] Yeah, right, that develop, for example, really deep Wikis, company Wikis-

Patrick: [00:55:00] Stripe's famous for this, yeah.

Chetan: [00:55:02] Exactly. That you write a lot of content about your thought process around how you arrived at a decision and you're very transparent about the thinking around arriving at that decision, then becomes very remote-friendly because asynchronously someone can catch up and add to that thinking, which is really great.

The other thing is we ran this campaign at Mulesoft at the local train stations all over the city where we had Mulesoft employees with the huge Mulesoft logo and a banner that said, "Be an integration superhero." We just plastered these ads all over San Francisco for a short amount of time, which was just being really creative, and really fun.

Patrick: [00:55:47] A new goal of mine is to do this at the Greenwich train station.

Chetan: [00:55:49] There you go. Yeah, you should. I mean, one of the things that is really surprising is offline ad inventory is actually really efficient.

Patrick: [00:55:59] Yeah.

Chetan: [00:55:59] And we can get into this about how like account-based marketing works really well if you advertise at airports, and so enterprise software companies have figured this out and this is why you see enterprise software ads in airports everywhere because is you're targeting customers that live in this particular city, when they're going in and out of an airport, there's a lot of free time to kill, and people are looking around, and they're looking at the offline inventory. And so offline inventory is super-efficient. And so what it allows you to do is be really creative in terms of how you want to target that top of the funnel. Again, this goes back to the parallels between recruiting and sales which is that if you assume that creating demand gen or candidate pool at the top of the funnel is a lot like the demand generation of sales leads, you start to think about that very differently. And you start thinking about, "Well, how do we get what we do out there really, really effectively?" And so, I hope to see an ad of yours at the Greenwich train station.

Patrick: [00:57:01] I mean, the possibilities are just abound, right?

Chetan: [00:57:04] Yeah.

Patrick: [00:57:05] Imagine if you could show up at a workplace and have a book basically that was the history of that place, you'd be caught up. I mean there's, I don't know anybody especially in smaller businesses that does anything like that and seems like a great use of simple time, but not any other cost to build a really interesting culture.

Chetan: [00:57:21] And it's all about, there's a movement around this idea that a company culture is just a set of shared stories that then get transmitted on because in really fast-growing software companies if headcount grows 100% year over year, then half the people that are in your company have been there for less than a year. And necessarily, another quarter have been there less than two years, and then on and on the math goes. And so, how do you transmit culture that was created around a group of very high-efficient 10-person company, then transmits to 1,000, and then transmits, on and on and on. And if you look at the technology companies, for example, like Apple, which is now a very large company that has a huge retail team also in addition to having a huge engineering team and how they've continued to maintain that innovation culture at massive scale is super-impressive.

And so the idea that if you start focusing on that from the very early days of company development of propagating a certain mission and a value system, and core of how that company's going to work, you can trust that system to propagate itself and compound.

Patrick: [00:58:43] Yeah. The systematic thinking around a product pipeline, a customer pipeline, and a recruiting pipeline, it's not that complicated, but it does take time. Like, if you're a reactive organization, it's just hard to step back and say, "Wait a minute, let's design a thoughtful process around all of this."

Chetan: [00:58:58] Well, the other thing is sticking with those thoughtful processes takes a lot of discipline and a lot of willpower because the shortcuts are abound. You will find shortcuts all the time. You'll be engaging with a customer who will say, "Yeah, this is all great, but I'll give you $200,000 to build this custom widget for me." Saying no is incredibly hard in the early stages of company building, and there's this saying that the power of great companies is those that say no to good ideas and say only yes to great ideas, and there's lots of great leaders that have talked about how constraints lead to really creative thinking, and so the idea that you're going to say no a lot in the early days. And part of that is not being so revenue-driven. It's much easier to say no to $200,000 to build a custom widget if you haven't set an artificial revenue goal for 2020.

Patrick: [00:59:55] So, you work with some incredibly talented investors that don't just do enterprise software, and I know that's not the only thing you would look at either, but certainly a deep area of specialty for you. Talking about this concept of extensibility again, which of these concepts do you think are or are not most portable to other segments of early-stage investing?

Chetan: [01:00:14] Well Bill's written a lot about the traps of LTV and CAC, especially as it relates to consumer companies. He has incredible blog posts on this, and so if whoever's listening to this hasn't read them-

Patrick: [01:00:27] Definitely, yeah.

Chetan: [01:00:27] ... hit pause, go read them and come back. The concepts of going down unit economic traps are actually widely applicable to all technology businesses, not only enterprise software but also consumer. And every type of consumer companies have this trap where you justify CAC or inorganic growth based on some formulaic LTV and you drive the business on a spreadsheet versus understanding actual consumer needs. So, that's super-extensible to all areas. LTV, CAC, and the traps of LTV:CAC ratio and formulaic business growth widely applicable.

The other part is actually product engagement, and how customers engage with your product is also really widely applicable across both consumer and enterprise software. And so Sarah's, who's a partner of mine who came from Pinterest where she was one of the early employees there, she's written this great blog post on consumer software engagement, and if you read that blog post from an enterprise software angle, you actually find that everything she's talking about is very applicable to enterprise software. And it goes back to these focus of lighthouse accounts, and if you apply that engagement framework to this idea of lighthouse accounts, it's incredibly clarifying. Deep engagement matters, and what kind of engagement your customers are exhibiting really matters. So, the ideas are actually of going slow to go fast, and being really cash efficient, and building deeply engaging products that grow organically, that appeal to customers, are actually widely applicable not only in the enterprise software, but marketplaces, social applications, gaming, et cetera, et cetera.

Patrick: [01:02:17] So, I know you guys spend I think every Monday in kind of intensive conversation between all the partners. What has changed most about your beliefs on investing after a couple of years of working with this specific group which obviously the historical success is well-known? Another thing I've appreciated about getting to know several of your partners which has been so fascinating for me is the fact that you're kind of only as good as what you're doing right now. Yeah, the brand is helpful, but it really is a constant battle to get better. So, in what ways have you gotten better as a result of kind of this iron sharpens iron idea of working with this group?

Chetan: [01:02:53] I think that what's really interesting, so there's five active general partners right now at Benchmark. It's me, Eric, Sarah, Bill and Peter, and we all spend a lot of time thinking about different things, and when you come together, what's really interesting is we each bring a different perspective to every potential new investment and we're able to look at angles that others are not may be thinking about, and if you have this approach of we all get together and we have this open-ended discussion, you actually are then able to finish these discussions. Frankly, that's like again this whole idea of going slow to go fast actually applies all the way down the entire decision tree.

Patrick: [01:03:38] Turtles all the way down.

Chetan: [01:03:38] Exactly. Which is if you able to have these open-ended discussions that naturally progress and I think that's the benefit of how we're structured which is five equal partners. We don't have anybody else. We don't have junior partners and associates, and et cetera, et cetera. And so, what ends up happening on that Monday is we don't have the next topic that we have to move onto. It's not like, "Okay, well we've discussed this for 10 minutes, I've got 10 more items to go down, can we wrap this up? And let's go." And because you can have that open-ended discussion you're able to go really deep. And what's amazing is that each of us has our own really deep and wide networks, and there are a lot of interesting points that come up in those discussions which then somebody might say, "Actually, I know somebody that could be very relevant for this. Let's call them up and let's talk to them."

I think one of the two things that I have found over time in terms of just being really efficient at learning is that one, being able to talk to other people that are subject-matter experts and be able to asked them the right questions to learn from them very quickly. And then two, synthesizing very complex information into digestible ideas that then can be translated and communicated into the group are two really powerful abilities that everybody around the table really has. And so, what ends up happening is you're talking about any particular investment opportunity is that you get the leverage of that collective network of the five of us, which necessarily means that there's probably not a question that we can't answer, and if we can't answer it, we know how to find the traps, what the maze is to get eventually to that answer.

And so the idea of having this open-ended discussion and being very deliberate about that I think is incredible and it's been unbelievably eye-opening, to me, personally, since the time I've been part of this group. And it comes up every time we've made an investment, somebody has had a question, and you're like, "Well, I think it works that way, but let me call the three most relevant people I know about this, and let's get an answer right now." And here we go and you're off doing that research.

Patrick: [01:06:08] I'd love to bookend our conversation. So, we started talking about a sort of very non-consensus, primitive new database technology, I'd love to close by talking about by definition the most mature business because it's the biggest in the world, or one of the biggest, which is Amazon and sort of what happens in very late stages of a business, and we'll talk specifically about the cloud wars just because I think this is such an interesting sub-topic and it's been a huge reason Amazon has grown so much has been AWS and the cloud. So, very different aspect of the business lifecycle. Arguably, this is a great example of something that's way, way more mature, but I think you've been studying Amazon a lot and cloud more generally speaking, we talked a bit about it before. I would love your take and your riff on business considerations at the very highest level of the game.

Chetan: [01:06:52] Yeah, sure. So, if you look at what Amazon did with AWS, it's truly remarkable, and as somebody that was developing 10 years ago, AWS really started becoming public around 2006 and become more mature in '07, '08, '09, and it was a completely different way for a developer to work. I remember if you wanted to host a mobile app, you had to go either rent service space, there was a data center in downtown San Francisco that you could go rent a little sliver of a cage and then you'd go put a server in there, and then somebody would maintain it. Like, you could do that, or some people were buying servers and putting it in their apartments and buying a dedicated business line, so there was all this stuff. And if you had a full-time job and you were developing on the side, if your server, I don't know-

Patrick: [01:07:44] Went down.

Chetan: [01:07:44] ... turned off, or somebody just hit the plug your app was down for the day. And so, what Amazon enabled with AWS at the earliest stages of application development was truly remarkable, and I think that it completely accelerated innovation in the technology economy, in terms of just the massive effect that it's had on the innovation economy has been massive, and as a result, you see the AWS numbers that are publicly disclosed, it is a incredible business. Now, what's interesting is as Amazon has gained more and more share of the infrastructure layer it started becoming super-dominant, and what we've seen is two companies primarily, that have decided that that infrastructure layer is also important to them in Microsoft and Google. And the motivations are different, but the end goal is the same. I think a lot has been written about how Google's motivated by the fact that they would not want to see compute and storage as a layer owned by somebody else for all of the technology economy, and for Microsoft who has made really amazing in-roads in building a very sophisticated enterprise business, not owning the infrastructure layer in enterprise is very costly for them, especially if you think about their apps business.

And so, both companies have come on very, very strong in cloud. And what I think that's been fascinating is if you look at the approach that Microsoft and Google have taken recently, which is because they're number two and number three, they have really embraced this idea of an open ecosystem and the idea that the way that they're going to really accelerate their market momentum is partnered heavily with start-ups and go to market with this, "Hey we have a catalog of best in class. So enterprise customer what do you need? You need a database, well we've got 10 open-sourced database companies that we've partnered with that will deliver a really great solution with the Microsoft backing and the Microsoft seal et cetera et cetera." So, they've taken a really unique strategic approach to the market that I think is really smart, and the results are playing out. And I think if you just look at where Microsoft has gotten in a very short amount of time, they've gone from kind of being a player to the latest Wall Street Journal article on this has said that they're at 17% market share. We talked about this earlier on the podcast, the last quarter's revenue, 59% year-over-year growth. And so they're a hugely serious competitor.

I think if you look at what Google Cloud has done especially around machine learning, workloads and around analytics workloads, it's become hugely popular at taking those workloads on. I think part of that has been driven by them open-sourcing TensorFlow and the enormous benefits that have been delivered out of that for Google Cloud as a business. And the unbelievably attractive rates they're charging for things like BigQuery, and Bigtable, and all of that stuff, which I know you know about. And so, if you look at these three really strong cloud providers now that have decided that owning cloud infrastructure or owning a meaningful share of cloud infrastructure is a really important business, I think that's long term really great for the innovation economy. I think having three really strong infrastructure providers is amazing. I think Kubernetes is a enabling technology.

Kubernetes

Patrick: [01:11:25] What's Kubernetes?

Chetan: [01:11:26] It's the technology that simply your listeners are, or some of your listeners are going to be very sophisticated and be very annoyed at this description but largely it's about containerization of application workloads, and so we had this evolution of firsts, you had to have a server and a workload was running under dedicated servers, then with VMware and XenSource we virtualized servers, and we could virtualize the underlying infrastructure and make applications more portable. Containerization is another evolution in this which is that you containerize and virtualize even more at the very specific workload and application level as opposed to the server level, and if you have containers that contain a data or an application, or part of an application, moving those around across servers and across clouds actually becomes really easy. And so you're creating this inner operability where if I built my application on containers, moving from Google to Azure to Amazon to Google to Azure, to maybe I want to host it to Equinix because I'm serving customers in a certain region that they want a dedicated enterprise server for it becomes really simply programmatically to manage, and so that has been a huge enabling technology and Google gets a lot of credit for pushing that movement along.

And so, technology and infrastructure is moving so fast right now, and the enabling technologies are moving so fast that it's a really great time as an entrepreneur to start something, because I think as we talked about it at the very beginning of this show, I'm super-optimistic that more and more businesses are starting to think about software as a core part of what they do, and as a result, they're looking for business partners and software vendors that will then enable them to do a job, and do their ultimate business better and faster, et cetera.

Patrick: [01:13:28] It reminds me to ask you about open source. So, open source is a concept is, it's got some age to it now, but from a business model standpoint seems to have matured a lot, so two questions, how important is this for people out there to think about, and even for people not running pure software businesses, what are some concepts from open source businesses that you think are portable outside of just those businesses?

Chetan: [01:13:48] I think what open source has really taught, generalized lessons from open source businesses is one, the developer ecosystem is a lot bigger than what I think most people assume. And number two, developers are constantly looking for the best solution for their problem, and so there is a natural tendency for exploration and understanding of what's new. And so, I often encourage entrepreneurs whether you're working on an open source project yourself, or an application that is not open source to just plug into the relevant developer communities, attend the developer events, attend the talks, participate in the talks yourself, share what you're working on, share the approaches that you've gone about in terms of building whatever's been working. One of the resources that I point everyone to is if you look at Netflix and their engineering organization and the number of open source projects they've put out which is basically, "Hey, we've been building this online streaming service that nobody's really built before, and we've had to build a lot of stuff to make all this work." And they've given so many talks around how they've done it.

And I think one of the things that ends up happening as you connect into that developer ecosystem, is it does two things. One, it's a great way to put the ideas out there and then you're then getting access to really sharp minds that are then able to challenge you, and they're able to draw far analogies which is, "Hey, that's really interesting that you're applying that to a streaming problem, but I actually encountered something in an eCommerce problem and here's how we solved it." And so you start getting that kind of feedback loop in these developer communities.

And then two, it's an amazing way to recruit really great people because you're now exposing the technical problems that your company is working on, and guess what, people want to work on really interesting problems, and if they see the interesting problem that the companies working on, they'll come and engage, and it's become a really effective way to recruit.

Patrick: [01:15:53] Back to your default, your idea of the pipeline for recruiting. One of the things I've thought a lot about is this idea of default open. Historically companies are a culture of default closed, and something about the speed and the openness of the internet seems to change the return on being default open.

Chetan: [01:16:09] Yeah.

Patrick: [01:16:09] And like massively ramp that return.

Chetan: [01:16:11] Yeah.

Patrick: [01:16:11] But we've certainly seen we're by no means an open source company but we've been a lot more open I think than would be natural or normal, and every time you do it, it shocks you with the positive return and weird stuff that comes inbound that wouldn't have otherwise.

Chetan: [01:16:24] I think that's absolutely right. I think that one of the things that is really different now is because of the speed of innovation, the whole concept of your approach to something being so proprietary that that's going to be your ultimately defensible IPs, essentially not accurate. What ends up being defensible over time is actually what we talked about earlier which is the customer relationship and being the trusted vendor, and it's no longer this idea of we figured out some really unique process that makes this things different and so therefore, we have to like shroud it in ultimate secrecy and we can't even expose it to our customers about how we do it, and it's this black box interaction of, "Do you want to go to A to B? Okay, we'll just get you there. Don't worry about what happens in the middle." Whereas I think that these large companies have shown by being so open, Google has been really exemplary from the beginning of just put out these papers of, "Hey, here's how we're processing massive amounts of data." And it's like, "Oh, wow. That's a really good idea." And putting out these papers, and putting out these talks of, "Hey, here's how we were solving really interesting technical problems." You just didn't realize that that enables you to become a stronger organization and it really has nothing to do with defending your core assets.

Patrick: [01:17:43] I love as a closing point the idea that successful software is all about building trusted relationships.

Chetan: [01:17:48] That's right.

Patrick: [01:17:49] And that technical details are less important in the long run. So, my closing question for everybody is to ask for the kindest thing that anyone has ever done for you?

Chetan: [01:17:56] Yeah. Look, I'm incredibly thankful of all of the mentors that I have come across in my career, I've just been super lucky to be with really amazing investors from the very start of my investing career, so really great people like Harry Weller, Robbie, and Jon Sakoda, Ira Mazool who took a really active role in mentoring me, and then folks like Peter Fenton who I got to observe from a very early stage in terms of how to be a great board member and a great business partner and how to be super-prepared and for board meetings and how to think strategically about advising entrepreneurs to my partners today, like Bill, and Eric, and Sarah, who are constantly pushing me and making me a better investor. And I also as you know, we've both done this, which is like learning in public and finding brand-new connections through Twitter that then become sort of informal mentors to you that then sharpen your own ideas about what's next. And so I think that idea of just being forward-leaning and having that learning mentality and being completely open-minded, and you just realize how many great knowledgeable people there are in the world that are just open to being very kind and being informal mentors that I think has continued to really surprise me that I'm super, super thankful for.

Patrick: [01:19:17] I just love episodes where I know the title already when we're doing it, so this will be go slow to go fast. Maybe the subtitle will be like, a masterclass in building software. Such an interesting end-to-end discussion. I've learned so much from you, so I appreciate doing it in public so others can learn as well. Thank you for your time.

Chetan: [01:19:32] Awesome. Thank you, Patrick.

Created by Sunghoon Kim