Building Successful Developer Products in a Crowded Landscape

Michael Grinich (00:02):

Welcome to Crossing the Enterprise Chasm, a podcast about software startups and their journey moving upmarket to serving enterprise customers. I'm your host, Michael Grinich. I'm the founder of WorkOS, which is a platform that helps developers quickly ship common enterprise features like Single Sign-On. On this podcast, you'll hear directly from founders, product leaders, and early stage operators who have navigated building great products for enterprise customers.

In every episode, you'll find strategies, tactics, and real world advice for ways to make your app enterprise-ready and take your business to the next level. Today I'm joined by Spencer Kimball, the co-founder and CEO of Cockroach Labs. Cockroach is the company behind CockroachDB, a cloud-native distributed SQL database that stores data in multiple locations to deliver consistency, resiliency, locality, and scale to the cloud.

Fun fact. The name Cockroach was actually chosen because it's the database you can't kill. It's that resilient. As they grew Cockroach Labs, they had to scale for enterprise. Their customer list now includes names like Comcast and Bose. We'll dig into all this and more as we talk about how Cockroach moved upmarket to cross the enterprise chasm. Spencer, welcome to the podcast.

‍

Spencer Kimball (01:16):

Thank you, Michael. It's nice to be here.

‍

Michael Grinich (01:18):

Let's get started. Tell us a little bit more about where Cockroach is today. Where's your business and team at? What's your current focus?

‍

Spencer Kimball (01:25):

I think we are over 450 employees now. We have offices in New York, San Francisco, Toronto, London, and some smaller satellite offices. We have about 250 customers. The point of this podcast is really moving to the enterprise and that's really where the ponderance of our revenue comes from. We have many different products now, but it's all the database. There's just different flavors in how it can be consumed.

There's the self-hosted licenses that are sold and there's different flavors there. There's a core. There's an enterprise version. And then, we have a cloud platform, and now a serverless version of that cloud platform to make the consumption really fine-grained. That list grows, it feels like, every year.

‍

Michael Grinich (02:08):

You started Cockroach about eight years ago or so. Take us back to that timeline. When you were starting the company, what was the problem you were trying to solve? What kind of company did you set out to build here?

‍

Spencer Kimball (02:20):

Databases have been the core feature of my professional life and always where the biggest problems lay. I had 10 years at Google. In that decade, I helped them with databases and also saw quite a bit of evolution in terms of how they thought about databases. When I left, it was an interesting experience. To be, after 10 years, exposed to only Google's infrastructure. To see what was available to any entrepreneur starting a company, which is what I was doing.

That really was the genesis of CockroachDB. Because in that review of all of the open source databases that were available, and even the closed source databases, you got so used to how Google built things and you saw all the reasons for it. You have your own ambitions and there was just nothing that did everything. Although, Google built something that did everything. You had the proof point. It was very obvious.

We didn't end up building the database and that startup that we did after Google, but that's where the idea came from and the name. And then, that name sort of stayed with us, which is why now we sell to Fortune 10 companies and I'm talking to the CIO and have to explain the colorful name to them.

When we set out to build Cockroach, I guess the best way to think about it is we were fast following what Google had built internally for very obvious reasons. It's a good place to start. I'd always give that advice to anyone starting a company. If you can't conceive of yourself as a prime customer, you may be barking up the wrong tree. Because nothing is better than really satisfying your own needs. That makes you an excellent initial product manager for the product.

‍

Michael Grinich (03:55):

I know before Cockroach, you were one of the co-creators of GIMP, which is a super popular image editing software in Linux and it's an open source project. Cockroach also started out as an open source project. Can you talk a bit about that and how you envisioned that wrapping into the business model? Maybe how that's evolved so far?

‍

Spencer Kimball (04:14):

That's a good question. One of the really big lessons I learned from writing the GIMP was that ideas are cheap and execution is all that matters. I'll just give you the short version of that. Peter, who is one of my co-founders of Cockroach, was also my co-author on the GIMP. We've been working together almost 30 years now. When we started on the GIMP, we were faced with the fact that Photoshop wasn't available in FreeBSD or Linux.

We were newly exposed at that stage. Just think of 1993, the advent of these sort of Unix on personal computers, and we loved that model. We loved all the open source software. We couldn't believe GCC was free. We couldn't believe Emacs. We nevertheless had a hankering for these desktop applications. Especially graphics, which both of us were very interested in. We said, "You know what? We have this itch. Let's scratch it. Let's build something that's like Photoshop."

We had these grand plans and we started working on it. Maybe a year into it, seriously, a whole year of working on it. We had something that was just kind of useful. We were so excited and we were looking on the alt.graphicstack, whatever newsgroup. You didn't even have the worldwide web at that point. You used these newsgroups with these files that you attach to the messages in order to put together a binary. We were about to announce it and we saw on this newsgroup that someone else had an idea that they said was very far in development. And it was a lot better than what we were building with the GIMP.

It was off the charts in terms of how cool it was and we were so deflated. I can't even tell you. Anyone that's an entrepreneur knows that feeling when you find out that a competitor has done something. In this case, what's really interesting, we almost stopped working on the project. We didn't, because we were like, "You know what? We're just going to do this because we love doing it. It's fun. We've had a great time." I never heard from that project again, but we almost stopped working on what we're working on.

The reality is that nobody has a novel unique idea. That is, by the way, extremely true in databases and even in distributed relational databases. Someone else has already thought about it. That's okay. Because your superpower is always execution. It is never the idea. Don't be cagey with your ideas. Float it out there, see what people say, because people are going to remind you, "You might not have seen this, but this company over here is doing something that looks like what you're doing."

That can be an unfortunate experience, but a good one in the long run. You don't always find those things out if you start worrying about NDAs for every investor you talk to. That's just one little bit of advice there. I think that the database space, because it's so competitive and there's so many good products that are open source already, it didn't feel to me practical to even think about building a database that wasn't open source. I personally wouldn't use one. I wouldn't want to be locked in with your most critical piece of infrastructure to a system that you've got no real flexibility and leverage versus the vendor.

Plus, sometimes you want to extend these things on your own. I've always kind of had that ambition. That certainly was true in most of my jobs, where we actually got down into the lower levels. And so, I just felt like that was a requirement. I think the market responds favorably to that with databases. When we started in 2015, the open core model, which has gone out of favor right now, was very viable. Elasticsearch had been doing very well with that, as one example. In that model, you have an open source core, and then you put enterprise features around it.

The reason people were doing that is because the pure open source model was often not working. Especially something expensive like a database. "Okay. We'll pay for support for the first year. If this thing is now running well, we're not using support. Wait. Why are we paying this company a million dollars every year?" That's the first thing to get cut when times get hard. A pure open source company has a real risk of churn and contraction, because if it's just service and you have a good product, you might be on the chopping block first. The enterprise features are what really drive lock-in, but you have to be very careful.

You want to make sure that the core product is good enough. People will definitely start to use it and feel like they can go a long way with it. And then, the enterprise features ... Ideally, they're things that only your most sophisticated customers that are really going to make up the bulk of your revenue actually need when they get to scale. They're actually happy to pay for it, because it's real value. That can be a difficult balancing act. Especially, in the early days. That was the open core model.

Unfortunately, I know this is a long answer, but Amazon kind of deflated that model. They did it to Elasticsearch and others, but Elasticsearch was kind of a prime example. Because Elasticsearch had some security features that really made their enterprise product sticky and those were not open source. That was part of their enterprise offering. They were building a big business on that and they put a huge amount of great work and equity into their core to make it super useful.

Then, Amazon took that core and they just re-implemented the security features and others and they put that into the open source. In some ways, Amazon was being altruistic, "We're going to add this great feature," and they didn't completely puncture it, but they put a big dent in the Elastic business model and resold Elastic as a competitor. They benefited from all of Elastic's work by just removing one of Elastic's key ways that they were deriving value from their customers, benefit from their customers.

That was a difficult one for us and that actually pushed us in the direction of the Business Source License (BSL), which is another license that has some great properties that are open source-like and it leaves it open source. I won't go into the details. You can just search for it and find out more details on it, but it gives you a little bit more protection.

‍

Michael Grinich (09:39):

Can you talk about those early days as you were commercializing with the open source product? I'm curious what your go-to-market team looked like. What was the sales motion there as you got a bunch of this adoption of developers playing around or using the product, maybe in small installations, and then converting those to actual commercial relationships?

‍

Spencer Kimball (09:56):

Well, you'll find as you're going to market that there's very different kinds of sellers that are appropriate for different stages of growth. And it's rare. Although, I've seen the examples of it, but it is rare that you find someone that goes from that initial selling period or phase all the way through to, say, $100 million in revenue. What happened to us is we had our first seller that was just extremely good at doing what I'd call, "An exploratory sale."

When you start with a relational database that's distributed, it's hard to say how you're going to price it and who's going to buy it. How far up market can you go? Do you have the right features for them? Can you find an acute pain point, where they don't mind that you don't have a bunch of stuff that's ultimately on their security compliance roadmap and things like that? Or list of requirements.

That's a difficult balance and it requires a lot of active listening, which is of course a skill you need at every level of sales. But at that beginning stage, it's like, "Let me hear everything you have to say." I'm going to spend a lot of time understanding what this prospect is asking for, what their problems are. And then, I'm going to just figure out which of our value drivers, how we think of ourselves, the capabilities of our product resonate or will resonate with that.

That's a difficult dance when you don't even know how much your product should be costing. Ultimately, a product like a database, it's very much you're selling on value. You need to figure out exactly how important it is to their use case and you discount accordingly. You have to look at all the comparables in the market, but there's usually a limit to how far that kind of an initial seller will go. Because their superpower is really that very flexible selling process. Not necessarily, "How do I actually hire a bunch of more reps and manage them and do territories and all those kinds of things that are necessary for scale?"

‍

Michael Grinich (11:47):

For companies looking to hire their first couple of reps like that, for that type of sales motion ... What characteristics do you think they should look for? What's the ideal person or persona? If you were giving advice to a founder on how to interview those first couple of hires, what would you say?

‍

Spencer Kimball (12:02):

Well, I think their recent work experience is probably going to be a good way to set a filter on all of the possibilities coming in. Maybe also a way to sort of position the job requisition. But I'd look for somebody that has very clearly followed that pattern I just described. In other words, they were the first salesperson at a company ideally that has some good overlap.

Let's say, they were selling to the same segment you think you're going to target. Or they're selling the same kind of product category or something that's relatively close. They were the first seller. They had a pretty good run up. And then, ultimately, as it grew, they decided they didn't want to work there anymore. They might have gotten someone that's hired over them as a boss or something like that. That actually is a really good profile. They've shown that success.

Often, you'll see one of those people and you'll see that they've done that in other companies too. If I was doing this all again, I'd be looking for that. Now, you can also find somebody that's the unicorn, where you saw that they were the very first person in sales at a company and they took them to $250 million or something like that. Hire that person too. That would be great.

But I think the selling to the segment is incredibly important. You might even go so far as to look at the persona they were selling to. Are they talking to CIOs? Are they talking to CTOs? Are they talking to chief architects? Are they talking to developers? Are they really selling a product that has open source uplift? Are they selling a product that people are trying for free on the cloud and that's the entry point? They're just upleveling their experience through layering on support or additional features and services.

These are all very different modes of selling. And if you put somebody from one to a very different kind of consumption, for example, there could be a pretty big impedance mismatch. Trying to match up the things that you can, goes a long way, because you really want this person to hit the ground running.

‍

Michael Grinich (13:56):

Let's talk about customer acquisition. How did that work for Cockroach with the open source model? I know that you guys did a lot of devrel and type of community work. How have you spread the word about this product and got people to start using it, which has led to that commercial success? How did people first discover it and really start adopting it?

‍

Spencer Kimball (14:15):

In the early days, it was really our technical content marketing, which was done by the founders and from our engineers. Every time we built something new that was innovative, we would really describe how it worked. I'll tell you this. I haven't done the computations to figure it out recently, but when we were doing this, say, seven years ago, six years ago, if we had something that hit the front page of Hacker News, it was worth about half a million dollars in Google AdWord spend.

That's incredible free advertising. And if you're selling to, as we still are actually, but at that time it was true as well, chief architects ... Boy. Those are the people that are interested in reading about the latest distributed database on Hacker News. That actually proved to be a very effective strategy for us. I'd say that almost all of our initial customers, they came to us because they were interested in that technical content. That really was what got their attention and really put our brand and associated our brand with technical excellence.

By the way, when you're selling a database, there is nothing more important. Selling a database is kind of like selling a car. When you sell a car, a lot of the people you're advertising to are not in the market for a car. They probably won't be in the market for a car on an average of another two-and-a-half years or something like that. It's not that different for databases. If you don't have the decision point of, "What database do we use for this new project," you're probably not thinking about how you're going to spend all the money and time to change your application to use a new database.

It doesn't matter how much better the new database is. What that means, just like with cars, you've got to establish your brand. You have to be very crisp really in any prospect's mind that you're the database for a particular set of problems that they see is on the horizon. "Now, I'm thinking." When that decision point comes, you're going to be number one or number two. If you're not number one or number two, you don't have much of a chance of winning. You've got to get very aggressive and you have to be on the opportunity as soon as they're making that decision.

Getting that advanced brand building in is extremely important. That just requires, for our people that'll be listening to this podcast, when you're selling a technical product of some sort, that you figure out what message with your audience is going to resonate about who you are as a company. For us, that was like, "Hey. We are the really sophisticated database." The very high-end database for folks where data is a significant problem. Whether it's scale terms of data intensivity or it's geographic scale.

"Hey. We've got to go across continents. We've got data sovereignty, latency problems." Those are sophisticated needs. You want to very clearly establish your brand as being the brand that solves those kinds of problems. And if you get too diffuse, because you start getting greedy, "We can also solve every little problem ..." Then, you'll actually run the risk of really doing nothing for anybody.

At least, that they're going to clearly associate in their heads, "Cockroach? That sounds complicated. I don't really know if it's for me." Because you weren't talking to them. You were talking to everyone. I think that's pretty important. If you think about BMW, when they're doing their advertising, it's a very specific concern for that sort of a customer. And that's what sticks in their head.

‍

Michael Grinich (17:20):

How did you have to evolve the product for those enterprise customers? I'm curious if you can talk about the balance between demands for maybe specific features for larger enterprise customers, and general improvements you were making to the core database product itself.

‍

Spencer Kimball (17:33):

That's a great question and I probably need hours to answer it. When we started, the enterprise was not ready for cloud consumption of databases. They are in 2023. So in eight years, that has dramatically shifted. We started off being able to sell it self-hosted, which actually makes the requisite amount of enterprise-ready capabilities much simpler to me. You're really just building the database that does what it says it can. It can scale and geographically, in terms of total size, it has the business continuity. That sort of thing.

Which is, by the way, a huge problem in and of itself. We're still working on that part. But if we had to start with a cloud platform, if you were building this in 2023, the enterprise requirements around a cloud platform take years to get ready. Years. Because you need all the security capabilities that are expensive to build, oftentimes require a lot of third party stuff. They require audits and clients.

It's a multi-year process. I'm sure people on this call have been selling to the enterprise and know exactly what I'm talking about. Every single customer, they've got a list of 300 security questions, which often required detailed responses. Building up that muscle takes time. That's why most businesses start at lower segments in the market. Higher velocity sales usually have lower average selling prices (“ASPs”), but they have a smaller set of requirements. They might not even need SOC 2.

In fact, many of our early cloud customers did not need SOC 2, but that was an interesting on-ramp for us, for our cloud platform. We really went down market on that, but now it's starting to go upmarket. And it's good that it worked that way, because we needed the time to build all these things. It's a significant effort. I'll also say that the enterprise segment or strategics or whatever you want to call them, they are not all created equal. Certainly, not for a database.

I'm sure this applies to other kinds of software as well. Financial services wants very different things out of a database in terms of performance, capabilities, and so forth. Big tech, which is another one of our verticals that is really resonant, they really need Cockroach, they have shockingly different requirements. There's just something to keep in mind when you ask about what we had to build really for the enterprise segment. In satisfying those two top verticals, for us, we don't do twice the work.

That would be a huge exaggeration, but we definitely do an extra 25% work, I'd say, to satisfy them both. That's just something to consider. Again, I made an earlier comment about, "How much do you bite off and try to chew?" Sometimes it's a lot better to be narrowly focused. Win there and then expand. Doing too much at the beginning, conflating all these different things together, not really being super narrow and clear in your focus actually can set you up for a significant hardship if not failure.

‍

Michael Grinich (20:23):

Spencer, last question for you. You're coming up on a decade running Cockroach. Looking back, I'm curious. What surprised you? What advice maybe would you give your past self? Along with that, what advice would you give the next wave of entrepreneurs, people building companies today?

‍

Spencer Kimball (20:41):

Well, for the decade I spent at Google, which was very formative, I was building for Google Engineers primarily. This predated their Google Cloud Platform (“GCP”) efforts. I was building infrastructure there mostly. Google Engineers, the group of people you have lunch with are using your product ... That's pretty different. When I started Cockroach, I realized, "You know what? Wow. I'm going to be selling to enterprise customers like ExxonMobil or something." That was one of our early customers.

That was very frightening for me and I didn't think I'd like it. I didn't think that having to educate people about distributed databases that maybe weren't interested in it or just had a very early stage need ... It just felt like such a big gap that I thought that maybe it would create a huge amount of friction and I wouldn't like it. It turns out, I love selling to enterprises. I love helping them with their problems, because there's a lot of them and all of them are trying to modernize and build in the cloud. It's a very fertile ground to actually make your customers successful.

Maybe my advice for everyone is you have to get your head on straight. You might not do it immediately, but when you're in it eight years, you have to figure out how to rationalize the incredible expenditure of time and effort on one thing. One egg and one basket. And ultimately, the way that that's worked successfully for me is to really say that our number one goal is not IPOing or having some financial success for the company. Our number one goal is making our customers successful.

If we do that, we will get to that outcome, but making your customer successful is all the leverage that you have. If that's what you're focusing on, you can make that happen. To hell with the eventual success of your company. If you're only focused on that, you might do all kinds of short-term things that are wrong. But if you just work on your customers, that is something that you can take to your grave.

Ultimately, that's why I was so happy to build the GIMP. It was like, "Is this thing useful to me?" And then, "Is this thing useful to lots of other people?" That utility building. That utility optimizing for that. I think that's the sure path, not just to success, but to the happy mind state as you're in pursuit of it.

‍

Michael Grinich (22:54):

Spencer, thanks so much for your time. It's been really great hearing about how you've scaled Cockroach the last few years.

‍

Spencer Kimball (22:59):

It's my pleasure. Thank you for having me.

‍

Michael Grinich (23:06):

You just listened to Crossing the Enterprise Chasm, a podcast about software startups and their journey moving upmarket to serving enterprise customers. Want to learn more about becoming enterprise-ready? The WorkOS blog is full of tons of articles and guides outlining best practices for adding features like single sign-on, SCIM provisioning, and more to your app.

Also, make sure to subscribe to this podcast, so you're first to hear about new episodes with more founders and product leads of fast-growing startups. I'm Michael Grinich, founder of WorkOS. Thanks so much for listening and see you next time.

‍