Invest Like the Best with Patrick O'Shaughnessy - Chetan Puttagunta – Go Slow to Go Fast: Software Building and Investing - [Invest Like the Best, EP.156]

Episode Date: January 28, 2020

My guest this week is a good friend and a 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 investing platform called Canvas. His advice has been critical to our early success. 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. For more episodes go to InvestorFieldGuide.com/podcast. Sign up for the book club, where you’ll get a full investor curriculum and then 3-4 suggestions every month at InvestorFieldGuide.com/bookclub. Follow Patrick on Twitter at @patrick_oshag   Show Notes 1:34 – (First Question) – How Chetan found MongoDB and decided to invest in it 8:01 – The evolution of databases in the growth of technology 16:19 – Market penetration of this space and what investors should be thinking about 21:46 – Advice how companies can build software effectively 25:12 – Tactics to effectively implement empathy led product building 30:33 – Companies asking users what to build vs telling users what they want 34:26 – The need for the right capital, and patient capital in particular 37:55 – Creating the perfect customer experience 44:37 – Common reasons they don’t invest in a company 48:48 – Lessons on scaling, especially in sales and marketing 52:47 – Best recruiting pipeline strategies 59:56 – Pitfalls of unit economic traps             1:00:23 – The Dangerous Seduction of the Lifetime Value (LTV) Formula             1:01:34– The Hierarchy of Engagement 1:02:18 – What has changed for Chetan in his time working with the team at Benchmark 1:06:009 – Later stage life cycle business considerations and Amazon’s AWS 1:13:29 – The business model of open-source software 1:15:54 – Being default open 1:17:53 – Kindest thing anyone has done for Chetan   Learn More For more episodes go to InvestorFieldGuide.com/podcast.  Sign up for the book club, where you’ll get a full investor curriculum and then 3-4 suggestions every month at InvestorFieldGuide.com/bookclub Follow Patrick on Twitter at @patrick_oshag

Hello and welcome, everyone. I'm Patrick O'Shaughnessy, and this is Invest like the Best. This show is an open-ended exploration of markets, ideas, methods, stories, and of strategies that will help you better invest both your time and your money. You can learn more and stay up to date at investorfield guide.com. Patrick O'Shaughnessy is the CEO of O'Shaughnessy Asset Management. All opinions expressed by Patrick and podcast guests are solely their own opinions and do not reflect the opinion of O'Shaunsi Asset Management. This podcast is for informational purposes only and should not be relied upon as a basis for investment decisions. Clients of Oshonosie asset management may maintain positions

and the securities discussed in this podcast. My guest this week is a good friend and business mentor of mine. Chathen Putagunta 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. Chathen has been my key guide for understanding the world of enterprise software as we at Oshana C asset management had 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. Chatham, let's start with a very specific story, one of Benchmarks Founders, Daniel Ratcliffe 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 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 databases, some wonky stuff. So start with the story of MongoDB and how you found it. Yeah. Look, I invested in MongoDB in 2012. and when I first met Elliot, 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, talked to your friends that name your big tech company at the time, it felt like there was a distinct advantage

between those that were trying to do something startup-e 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 were things that were always in my mind, always felt like, hey, agility and productivity was really, really important to developers. And so when I met Elliot, he had this. huge vision because he himself came out of double-click 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 was 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 asked them to play with Mongo, they would tell you, this isn't something I need. Have you tried MySQL? Have you tried, 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 down 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 had wasted all this time on schema planning. You could have learned less and far cheaper. Yeah, exactly. And so. And faster.

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 that could be fundamental in terms of where compute and application development was going to go. And what you saw, because it was. 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 it ended up happening actually was that 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 blowback 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 really mature database. And the company's first commit, code commit was in 2007. And so it took a bit of time to bake. And by the time you got to like 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. 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 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 can 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? 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 a CRM application, which became a huge business. They served an HR business, H-CM 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 rows. A way to think about it is that's the except. So 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 data sets 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 no SQL. I spent most of my career using it. Exactly. So analysts no 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. Why? Well, because a developer can do whatever they want with the 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. all the things that make it hyper-sensitive and hyper-critical, all that technology that needs to wrap around a database is really hard to build and making it scalable, making it useful. And there were a lot of attempts to build very functional specific databases over time. So you saw analytics databases or you saw very high-performance databases. There were databases that were geared very specifically to high-end financial services, for

example. But building this general use 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 have 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 you look at the amount of data that's being 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 users 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 have been right and predicted that this was going to happen. And if you invested in something that was started in like 1992, it wouldn't have worked. It seems like since then, there's cockroach DB, there's timescale DB, 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 use cases? That's right. I think that 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 use 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 an IOT application for time series data, timescale is fantastic and highly performant for that use 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 use 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, one in one 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 that 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 assume they were. 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. That's right. And invest in mispriced securities, maybe when they're not as appreciated as they once 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 penetrated 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 as 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 does the opportunities that look like in the 2020s? I think I go back to what our partner Matt Kohler 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 very, 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 down 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-penterated 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-prem world. So the move to the cloud, We're still in the very, very early earnings of that cloud.

And then if you look at the number, the amount of capital or dollars deployed against services against IT, it's... Pimple. 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 startup 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 will. 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 like tailored to their specific need. Actually, it's great to have a general purpose CRM system. And what that then led to is Viva 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 very different

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, Alassian, those growth rates are still really high on very, very large numbers. And then you move one level lower into 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. Of a huge base. Of 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 startup 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. So I'm going to ask a series of selfist 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, or I guess maybe it'll 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 feel 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 would 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?

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, 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 Sister My Career podcast that you did, they often talk about we were building something inside of Instagram for consumers to do a job.

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 become an expert in. So if you have that sort of macro empathy point of view, it solves a lot of decision making along the way. 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 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 easy to say, probably hard 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? 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 slash 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 oftentimes, more than that, more than that,

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 a services contract is actually a commercial engagement with that customer that then allows you. 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 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 that that then becomes software revenue. And two examples that I think are really instructive

are one workday in Viva, which in the early days of both companies, nearly 50,000, 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 Viva's case, they were either running custom homegrown 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 that migration process and training process go much faster. So going back to it, I think that services done right for startups is a huge advantage that simply should not be ignored. Got a couple questions on both those kind of general strategies. So first on the sort of 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 the answer is 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 need 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? 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 as 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 it being done this way? Shouldn't it be done this other way? And you'll find a set of early adopters that 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 that simplifying those systems with APIs and microservices. 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 up with a unique insight and went to a set of early adopters that were airlines themselves. said, shouldn't the 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, where 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, you you start getting real case studies, the momentum then builds and allows you to really redefine in an industry, which is super unique.

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 little about investing edge, but I think this is one source of it. Talk about how important that is. 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 KAC, 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 to start falling apart, your burden gets really high, and then, and then, and then 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 a 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 Milsoft, who I know you know, If you look at what they did at scale in terms of capital efficiency, it's remarkable. They burn something like $8 million to go from $100 million of revenue to a little under $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, 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 commits. 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, LTV should be infinite. And so software businesses end up working really well when you build mature products that customers then continue to renew. And, cost of customer acquisition or KAC approaches zero. And that's a really challenging mental exercise, which is how can you build technology products that have a KAC of zero? And that takes a lot of time to figure out. 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 KAC 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 use case as possible. And then when you think about it that way,

it's just incredibly clarifying. Like 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 looked like faster growing revenue curves or things like that. That seems like a huge scaling challenge. Would you agree that that's the case?

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 a time. Sebel at the same time had an average contract value of $400,000 and was typically selling a thousand licenses at a 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 Sebel in 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 it 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-offs for a million-dollar contract or a $10 million contract, it's very rare that a customer is baking off to solutions. Very, very, very. 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 and solving a problem and then being very patient. Take your time to refine the solution.

Exactly. Creating product maturity. And prematurely scaling and then restarting, it's hyper-painful. And cash is ultimately, there's this obvious saying that the number one recent startup styes 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 an 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 or 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 ask yourself, would my customer pay 15% more for what I'm giving them? You 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 then increased revenue per 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 clearer. It's like, oh, if I have to compound 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. What are the most common reasons that you don't invest in maybe what looks like a promising story, founding team, business? And I'll go from there to sort of the don't. We talked a lot about the dues.

We haven't really talked much about things that cause people to fail other than this premature scale. scaling idea. So what would be the most common reasons that you knock somebody out from consideration when looking at investing? 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 10x, 100 X, even 1,000 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 earliest 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, 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 and 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. build a really big position pretty quickly. Never having met anyone. Yeah, 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 that 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 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 or why you weren't interested in an investment opportunity.

And one of the things that has become very clear to me being in early stage investing for nearly nine 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 they're amazing macro trends in enterprise software. But if you tell me what are the 10 startups 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 new 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 startups? 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. 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 sophomore generally. So we'll keep marching this playbook here. 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 ask them, what went right? I'll say, 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 of 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 ghostlet 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 and running a very structured

recruiting process is super important. If you think about how to hire really, successfully. Again, it's 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. Exactly. And so there's a lot of parallels between recruiting and sales, frankly. You have to build a really big funnel. And you have to have a really great process where the candidates that you're interviewing feel really good as they're going to the process. So very structured. it's very predictable. Sounds like software.

Exactly. Like the interactions are predictable and understandable. And it's a process that's moving along. And you get to the finish line and you're making this dual 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, 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 mishire, or makes a bad hire, it's actually a fault of the company. It's a fault of that process that was run that led to not a great decision. What stands out in memory of the most interesting or compelling recruiting pipeline strategies that you've seen companies employ?

Yeah. And so we'll go back to Mealsoft, which was solving integration problems, enterprise software integration problems. Very specific. 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 your company scale, how do you then differentiate yourself? So there's two things that are available to startups that aren't available, to really, really large companies. One is I think it's really exciting that you're seeing more and more startups embrace remote.

So it is, we're gonna, talent is universal. Embracing 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. 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 there 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 policy 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 they're

just written communication. Yeah, right, that develop, for example, really deep wikis, company wikis. Stripes famous for this. Exactly. 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 in 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 Mulsoft employees with the huge Mulsoft logo and the banner at said be an integration superhero. And for We just plastered these ads all over San Francisco for a short amount of time, which was just being really creative and really fun.

A new goal of mine is to do this at the Greenwich train station. There you go. Yeah, you should. I mean, one of the things that is really surprising is offline addentory is actually really efficient. Yeah. 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 if 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 ad 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 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 a ad of yours at the ground of station. I mean, the possibility is just abound, right? this idea of having, imagine if you could show up at a workplace and have a book, basically, that was the history of that place and you'd be caught up. I mean, there's, I don't know, anybody, especially in smaller businesses, that does anything like that. And it seems like a great use of simple time, but not any other cost to build a really interesting culture. 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 that then transmits to a thousand 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, the very early days of company development of propagating a certain mission and a value system and core of how the company is going to work, you can trust that system to propagate itself and compound. 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, like, wait a minute, let's design a thoughtful process around all this. Well, the other thing is sticking to 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 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. So you work with some incredibly talented investors that don't just do enterprise software. I don't know. That's not the only thing you would look at either,

but I'm 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? Well, Bill's written a lot about the traps of LTV and KAC, especially as it relates to consumer companies. And he has incredible blog posts on this. And so if whoever's listening to This hasn't read them. 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 cack 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. So LTVCAC and the traps of LTVCAC ratios and formulate 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, of being really cash efficient, of 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. 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 chirpins iron idea of working with this group?

I think that what's really interesting is 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 that we each bring a different perspective to every potential new investment. and we're able to look at angles that others are not maybe 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. Turtles all the way down. Exactly, which is if you are 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 that we don't have the next topic that we have to move on to. 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. And 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 ask 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 is 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. 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, like 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 subtopic. And it's been a huge reason Amazon has grown so much has been AWS and the cloud. So very different aspects 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 levels of the game. 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 2007.

809, 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 like go either rent server 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, 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, 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 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 an 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 is 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 inroads and 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 has 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 partner heavily with startups

and go to market with this, hey, we have a catalog of best in class. So enterprise customer, what do you need? Do you need a database? Well, we've got 10 open source database companies that we've partnered with that will deliver really great solution with the Microsoft backing and the Microsoft sort of 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. 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 an enabling technology. What's Kubernetes? It's the technology that simply your listeners, 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 first, you had to have a server and a workload was running on dedicated servers. Then with VMware and Zen Source, we virtualized servers, and we could virtualize the underlying infrastructure and make applications more important. 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 interoperability where if I've built my application, application on containers, moving it from Google to Azure to Amazon to Google to Azure, to maybe I want to host it to Equinex because I'm serving customers in a certain region that they want a dedicated enterprise server for it becomes really simple 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 enabling technologies are moving so fast that it's a really great time as an entrepreneur to start something. And because I think as we talked about at the very beginning of the 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 in software vendors that will then enable them to do a job and do their ultimate business school

better and faster, et cetera. It reminds me to ask you about open source. Open source as a concept is 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?

I think what open source has really taken. 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 has 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. 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

they're 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 e-commerce problem. 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 problems the company is working on, they'll come and engage and it's become a really effective way to recruit. Back to your idea of a pipeline for recruiting, one of the things I've thought a lot about is this idea of default open. Historically, companies are sort of default closed. And something about the speed and openness of the internet seems to change the return

on being default open. Yeah. And like massively ramp that return. Yeah. We've certainly seen that 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.

I think that's absolutely right. I think 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 IP is essentially not accurate. What ends up being defensible over time is actually what we talked about, earlier, which is that customer relationship in being the trusted vendor. And it's no longer this idea of we figured out some really unique process that makes this thing 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. I love, as a closing point, the idea that successful

software is all about building trusted relationships and the technical details are less important in the long run. So my closing question for everybody is to ask for the kindest thing that anyone's ever done for you. Look, I'm incredibly thankful of all of the mentors that I've 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, Ravi Wichanath, and John Saccoda, Ingram Mazul, 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. I always 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. Awesome. Thank you, Patrick. Hey, everyone. Patrick here again. To find more episodes of Invest Like the Best, go to investorfieldguide.com forward slash podcast. If you're a book lover, you can also sign up for my book club at investorfield guide.com

forward slash book club. After you sign up, we'll receive a full investor curriculum right away, and then three to four suggestions of new books every month. You can also follow me on Twitter at Patrick underscore Oshag, Oshag. If you enjoy the show, please leave a quick review for us on iTunes, which will help more people discover Invest Like the Best. Thanks so much for listening.