Gitlab: Deep Dive Interview with Former Executive

Key issues discussed in this interview:

• The product-market-fit of Gitlab
• Gitlab’s sweet spot and sales motion
• Competition against Atlassian and Microsoft
• Industry headwinds and tailwinds

ARPU: Can you describe the company's product and the key problems that the users are using the product to solve?

Former Executive: Sure. So GitLab is a DevOps automation tool. The reason someone wants a tool like GitLab is because they are developing a digital product and they want to get their product to market faster with fewer bugs. It's the same reason that anybody buys any DevOps tool. Now, how does it do that and why does it do that? If you think about the process of creating a digital product, there's a bunch of different things that happen and they all fit into a little bucket anywhere from the idea stage on through to the production stage, to where the application is actually being deployed.

Prior to tools like GitLab, each of those stages in the process of bringing a piece of software to market and iterating through perhaps creating new versions later on, each of those stages was managed manually. The process that you go through is pretty standard. So GitLab provides the automation piece between each of those individual phases. You could still do that before GitLab, but what you didn't get before GitLab was a unified view into the data between each of the tools at each of those stages.

So before GitLab people put together their own DevOps pipelines using a bunch of different tool sets and those tool sets, of course all had their own data storage and their own data pieces. They talked to each other their own way. They weren't aware of each other. If you wanted them to work together to automate it, you had to hire someone to come through and tie all the processes together, figure out which pieces of data to move when and where and why. It was a bit of a manual process of getting that done.

GitLab automated all that and allowed companies to much more quickly bring their products to market faster. Not only that, but to bring better products to market faster. Because by cutting out the manual processes, you removed a bunch of error and the way that the CI and applications security testing worked lots and lots of automated tests could happen without you having to intervene in order to be able to happen.

So prior to GitLab there are all these different stages. You mentioned that all these different stages have different set of tools. Is there any attempt between the different stages or tools, to integrate with each other, and try to bridge the gap between these stages?

Well, that stuff existed beforehand. So you take a look at GitLab to most significant competitors, Atlassian and Microsoft. Let's look at Atlassian first because they had the most complete product. GitLab's product is broader than Atlassian's. But when GitLab first started Atlassian's product was broader than GitLab's. The approach was very different. GitLab wanted to be an integrated tool from day one. Atlassian has a product called Jira, which does defect tracking and issue management in the software development process. They acquired all the other tools that they had across the DevOps lifecycle as a way of selling more Jira. Okay. So each of those companies that they acquired to add to their portfolio, were based on different technology. They worked differently.

To this day Atlassian's products really are not very well integrated. Part of that is by design because the way that their sales motion works, it's driven by integration partners. This gives the integration partners a profit center by performing the integrations. But it doesn't work that way. It doesn't work right out of the box with everything all working together. That puts a little bit of friction for some customers. For other customers that's fine. But for some it puts some friction and obviously it's enough friction that GitLab is much more widely deployed than Atlassian these days. Atlassian still makes more money for a variety of different reasons, but GitLab is more widely deployed.

Microsoft's product, they bought a company called GitHub and GitLab was actually created as a way to do GitHub better. So the deal with GitHub at the beginning was that it was a consumer grade product, targeted at end users who would pay their own money to use the tool. When corporations started to want to use it, there were no enterprise features. It had to be run in a hosted environment and a whole bunch of other stuff. GitLab was designed from day one to be an enterprise tool. So that was the big difference there, but GitHub has moved on since then. GitHub it's now owned by Microsoft. There's a whole suite of development tools that go from end to end. But again, Microsoft acquired GitHub because they wanted to sell more Azure. So GitHub is a tool to sell Azure, and yes, they've got a lot of development tools that completely swamped the whole development life cycle. They've got something for everything, but a lot of those tools are outdated. Microsoft acquired those tools as a way to sell Windows back when selling desktop operating systems was their main focus. Now selling cloud space is their main focus, and now they're acquiring tools to sell in the cloud space. They've got a bunch of tools. No, they're not really all that well integrated.

Then if we go at a different route and say, "Hey, you know, what if a customer does the best-of-breed, right?" So let's say, I'm going to go and I'm going to use maybe free and open source solutions, right. What I'm going to do because that's what I believe in. So I'm going to go out there and I'm going to use Git for my source code management. I'm going to use Gerrit for my code line management. I'm going to use Bugzilla for my issue tracking. I'm going to use Jenkins for my CI and so forth. Some of those free and open source tools are excellent. Let's say Git for instance, everybody uses Git. No one does source control on anything, but Git these days. That's why it's part of GitLab. That's why it's part of GitHub. They both use that tool. Jenkins is pretty well first class for CI. But again, these things don't really talk to each other. You got to do a bunch of work to get the two. There's tons of consultancy companies that make a fortune doing just that. If I then say, "Well, you know what, maybe I'm not hung on the open source stuff. Maybe I just want a bunch of different products in each space because I want the best one in each thing. So I'm going to use Jira free for issue manage. I'm going to use Git for source code management. I'm going to use, I don't know, Jenkins or CloudBees perhaps for CI. Again, those are all from separate companies and yes, each of them have some sort of integration with the other best-of-breed tools. But if we go and take a look at how CloudBees works with Jira, they have an integration say, "Hey, here's how we work with Jira. Atlassian has a standard method of doing it that is totally different from the way that CloudBees has of doing it. So there's really no standard way of doing it. Again, you're ending up having to hire a consultant to do it. There's nothing wrong with hiring consultants. They do great jobs, but six months from now when Atlassian changes their product, suddenly your integration doesn't work and you got to bring them back in. While that could be expensive, that's not the biggest part of the problem. The biggest part of the problem is it means you've lost production. So if you upgrade to the next version of Atlassian, your integration no longer works.

Now you're back to doing things manually until you can hire someone to get them in to fix it. That slows down your release time. The whole reason you bought the tool set in the first place was to speed up your release time. So yes, there are integrations between all of these tools that exist out there. No, they're not all that reliable. There currently isn't another vendor that does end to end. Could one come in and disrupt the market? Maybe, it's starting all over from scratch in a very crowded field, which makes it hard to get to a scale to where someone's going to take you seriously.

I want to understand a little bit more about customer. Who is GitLab really selling to? Can you walk me through the sales motion?

So the software development tools all have a sales motion that broadly or narrowly mirrors what I'm about to describe to you.

The sales motion for GitLab, the customer journey is the same for whether they're buying GitLab or JFrog or Sneak or Atlassian, or anything else. It's pretty much a bottoms up motivated sales cycle. So when you go to sell GitLab into an enterprise, and I'm really only going to talk about enterprise sales because that's where the money is. SMB sales, where people call on the phone or buy something, I could get 10,000 of those customers and still not make as much money as I did by selling to enterprise once. So we'll leave those aside. We'll just talk about enterprise sales.

Unlike a tool like Salesforce.com, when you sell Salesforce.com or you sell NetSuite or something like that, the first person you call is this CFO or the VP of sales or something like that. Because they're the one owning that decision and they're buying a particular tool and they are having all of their employees use that tool because that tool's going to comply with the things that chief officer needs to have resolved. When you buy a software development tool, that's not how you do it. If I were to sell a software development tool, my first call was into the CTO. Even though I can get them take my call, he's not going to buy anything ever. It's very much a bottoms up sales motion. It's a land and expand. That's not to say that you don't target the CTO and I'm going to get into some GitLab specific things. So this is a sales strategy that I put together that work really well. It tied in with GitLab's tiered pricing model.

If you look at software development tools today, almost every single one of them has some sort of free version. A version that could be used maybe only by one developer or it's open source and doesn't have support, or it doesn't have some of these other features that, or it's limited in some way, but it's free. That's done on purpose because that's meant to attract an individual developer to get your tool and to play with it and try it. Because developers like to do that, they will always want to try a new tool and they will use a tool and they'll play with it and they'll learn it. They'll probably do most of that on their own time, rather than at work. That's where GitLab's open source product comes in. Because that's who's downloading it, individual users. They might find something about it that solves a problem that they're having with whatever it is that they're using at work. So they're going to want to use it at work. So they'll start to use that free version at work. At which point their manager will go, "Whoa, whoa, whoa, you can't be using tools that aren't supported and everything else here." How do we go about getting this supported because the developers really want to use it? Because they socialize it around and it solves their problem and they don't want to waste any time mucking about. So that development manager says, "Okay, fine. I'll go out and I'll buy the tool for you. I'll buy whatever the cheapest version that there is." Because he doesn't have a whole lot of budget. The guy that manages 10 or 15 developers, he doesn't a big budget. So he goes out and he buys the cheapest supported version of the tool he can. That version of the tool is targeted at that development manager, that budget owner. It is priced to fit in his budget. The feature set that it has solves the problems that his employee have.

So the sales motion at GitLab is nobody waste any time trying to sell these guys, they find it. Marketing does a great job of getting it in front of them, they'll make a purchase. After they've made that purchase and there's a team already using it, that's when a sales rep will start to get involved, if the company is interesting. The idea is just to try and get more than one team using the product. Because once you do that, you can then go up a level. There can be thousands of developers at an enterprise. I want to get more of them. I don't want to go and sell to each individual development manager one at a time because that's time consuming and not a good use of my time. I want to make this sale bigger. So I'm going to go and I'm going to take the premium version of the product. That premium version of the product has feature sets that's targeting that development director. The guy who a dozen of these development managers work for. It's priced to fit his budget. He's got a much bigger budget than the development managers and it also has feature sets that solve his problems. These features might not necessarily be of interest to the end user developers, but guaranteed that development director has people on his team that do more than just write code. He probably has people on his team who are responsible for security testing or who are responsible for end user usability studies or other sorts of things. That the main developers don't particularly care about. But this guy has teams that do, and you're going to go to him and go, "Hey, you know what? You've got a bunch of developers who are using this product." That's great. They get some good value out of it. There's a whole bunch of feature sets that they're not accessing that the rest of your team probably cares about. If his current team is really happy with it, he may expose his other teams to it. Then not only did you certainly get an up in the number of users, but you also up the ASP, the average selling price. Because this new version is more expensive because it's got the other stuff in there.

Then you do the same thing again at the higher level. Once you've got a division using it, you then have permission to go and speak to the CTO and go, "Hey, look, you really need to be using the ultimate version because it's got the advanced testing. It's got the deployment management and the Kubernetes orchestration. It's got all these other things in it that your end user developers don't care about, but you do."

That's the sales motion and it works pretty well. It's a sales motion that's not unique to GitLab. If you look at everybody else's product, they've got a couple of different product here and they're all priced at the guy who's the budget owner. But the features are pointed at the guy who works for him, if that makes sense.

Got it. Can you elaborate on Gitlab’s market segmentation?

This, again, is not unique to GitLab. You divide the market into three different segments because the sales motion in those segments are different. You've got an SMB, a mid-market and an enterprise and the motions are different. So an SMB market, the sales motion in that market is typically self evaluating, self guiding. The customer was exposed to your company only through marketing. They may have had one or two questions so they call tech support, but that's where they're at and they order online.

The mid-market group has a different sales motion. A mid-market company has a slightly different sales motion. They're looking at companies here that have less than a 1,000 employees, more likely around 500 or so. But the motion stays the same to about a 1,000 employees and then it changes. They will do a formal evaluation because they want to make sure they're not wasting their money. They also are more likely to buy a SaaS product than a non-prem product. Because they are smaller they don't have dedicated teams to keep applications running. They would rather have somebody else take care of that. Their purchasing process is often driven through third parties.

So typically this is where the channel reigns supreme. You got some company with 750 employees, they're doing a bunch of software development work. They don't want to take any of their full-time employees and have them build integrations or implementations for products. So they hire a third party to do that. That third party affects their decision making greatly. So the mid-market is almost always dominated by sales partners. So you recruit a bunch of channel partners to the mid-market.

Then the third tier would be the enterprise tier, their sales motion is the motion I originally describe it to you. That's how it works. They'll have more than a 1,000 employees normally. They’ll have people who are dedicated to keeping software up and running. They are security conscious. They will never make a purchase without interaction with people from the company that they're purchasing from. Their sales may still be driven in part by channel partners, but they will never make a purchase without meeting someone at the company who's providing the product.

What would you say is a sweet spot or vertical for GitLab? I know GitLab has a pretty diverse customer base, but would you say there's a sweet spot that you guys could identify?

Yeah, the low hanging fruit was definitely financial companies. Government came a close second and that's changed a bit. I mean, but financial companies care a lot about security and GitLab is a secure product that you can run securely and it helps increase the security of the tools that you were creating. So it's right in that bailiwick.

If you take a look at GitLab's two real competitors, GitHub is not a secure product. So you'll find very many financial institutions that rely on GitHub for much because GitHub, you either have to run it on Microsoft's services in a public cloud, multi-tenant. That's a no-go if you're a bank or you're running it either on your own private cloud or on your own hardware. Although nobody really runs them on their hardware, but you're running it as a black box VM where you don't have access to the internals. That's a problem for a bank because GitHub and any tool is made up of a whole bunch of components. A good number of which are open source. Open source components get passed on a regular basis. The vulnerabilities that are being passed are well known. So inside of that GitHub black box where I don't have any control over and I can't update anything, it's running a whole bunch of things, including things like the SSL library, which gets patched on a almost weekly basis. If I am worried that someone is going to hack into my network traffic and see the messages going between my developers and the server, I care about that my SSL library is up to date. I can't update it if it's inside of Microsoft's black box that they have for GitHub enterprise. So I'm stuck with it until Microsoft updates it. That's a problem for me. If I'm a bank or I'm a government, that's a huge problem. So you won't find very many of them relying on it for much more than departmental projects and stuff. So those two pieces are the low hanging fruit.

Another one will be software development companies, companies whose job it is to produce software that they then resell. Companies like Salesforce and NetSuite and name a game company, right? Because that's all software. They're also very good targets. They have a lot of churn. Because they develop tools themselves, their ability to switch and move on to do other things at later dates is easier than other tools. So if you're selling to other software developers, you need to make sure you've got a good customer success team in order to keep them on. So when you look at GitLab's churn rate, you notice it's very low. There's not many people get on GitLab and move off. The ones who are moving off aren't moving off of the whole tool set. They may be moving off of one of the visual piece because they found something better. Most of those are probably software developers who then two years later may move back on because GitLab came out with a new thing. They are more agile than other developers. They're also easy to sell to. But this is more of a game with a subscription product.

If we're talking about company viability and profitability with a subscription product, the game is to keep the customer. You look at GitLab's pricing and it's cheap. Even at the list price, which nobody pays for the most expensive version of the product, it's less than a tenth of a percent of the fully loaded cost of the develop. It's not next to nothing, but the deal is you end up keeping it for 10 years. So if I lost money selling it to you the first year, and if you look at GitLab's cost of sales, the acquisition for a new customer indeed they do, currently it costs more to acquire a customer than that first year sale gives you. But that first year sale's not it, the customers keeping it for, let’s say, 10 years. So the real sale is actually 10X what you just sold them over the course of the next 10 years. So keeping those customers is really important. The low churn rate GitLab has is stellar for showing how well that's going to work.

So you mentioned GitHub just now, can you just talk to me on the head to head win rates against GitHub? So I know GitHub seems more popular in the wider development community. How is GitLab doing against GitHub?

Well, this is a confusion to a lot of people who aren't software developers. To anybody who's not a software developer, GitHub looks way more popular. You hear more about it. You will not find very many developers who do not have a GitHub account or who are not using GitHub. That doesn't mean that corporations are using GitHub for their main development. That means that individual developers have a GitHub account because GitHub is a social network, as well as a place for them to keep their private projects and a place for them to collaborate with other developers who they don't work with. Yeah, GitHub is extremely popular. Yes, tons and tons of developers, users matter of fact, almost every developer you know has a GitHub account. Heck I have a GitHub account. Everyone does. It doesn't mean that they're winning enterprise deals. They do win some enterprise deals. They don't win the richest ones, the ones that the banks and the governments and things like that, because it's really hard to run a secure version of it on prem.

So if you look at it, the number of paid users of GitHub, the number of humans using it is much higher. But they're all paying a few bucks a month. They're all individual guys using it. Whereas you look at the number of enterprises using GitLab and the number of users at enterprises using GitLab for their company, it's very different comparison. It is very rare for a GitLab sales reps to lose a deal against GitHub. If we went into a situation to where GitHub was a competitor, it was extremely rare for somebody to say, "No, we're not going to use GitLab. We're going to choose GitHub instead." There were times where that would happen with Atlassian products, at least at the beginning of my time at Gitlab, but towards the end that even stopped.

If I understand it correctly — GitLab focuses on the enterprise and mid-market segments and does not pay much attention to the SMB segment. Is my understanding correct?

Yeah. GitLab focuses on enterprise, and mid-market is in second place. They don't spend much energy on SMB.

What do you think is GitLab's most significant weakness?

Right now their biggest weakness is it's expensive to grow. I look at the job that Michael McBride has to do, double sales every year for the next four years. It's absolutely doable, but it's expensive. Because you hire a new GitLab sales rep, it takes them a year to come up to speed. A typical GitLab sales rep will have about a million dollars of quota. Maybe more depend upon things. By the time they're producing that amount of revenue, let's pretend it's a $100,000 a month. By the time that they're selling at a $100,000 month, it's been almost a year since they were hired. So you've paid them this whole time and he's producing less. But in order to grow and double every year, you've got to double your sales reps every year. So you're eating all that cost up front and that's a hard spot to be in.

GitLab is growing their customer base six to eight X of what they are now. There are certainly on the path to do that in a couple of years. Then that hiring can slow down and suddenly the cost of sale goes way down because now you're not paying for sales reps that aren't producing and you knew they weren't going to produce until they had enough experience and ground run to do it. That's the hard place to be in and that's going to cause lots of internal growing pain issues. I think their biggest weakness at this point is that they need to grow fast and that's expensive.

On that theme, what do you think are the leading indicators for the long term growth story of GitLab?

The indicator used to be digital transformation projects. So the way that the world uses software has changed. A lot of companies are or were still doing it the old way. They needed to move their infrastructure to run in the cloud, because it's a lot cheaper and more efficient and faster and secure and everything else. The process of doing that is expensive. The tools that you use to run a software development effort in the cloud as a digital first organization is GitLab. It is the tool for that. If you are wanting to run your organization as a 21st century digital organization, GitLab is the tool that you're going to be using to do that. So the more companies that adopt that model, the more uptake you're going to see on GitLab. So I guess that would be the indicator. A big piece of that has to do with stuff that's invisible though and it's hard to see from the outside. It has to do around the security of individual products and particular embedded products. It's impossible for an outsider to see that digital transformation process.

Traditionally embedded products like the software that runs in the radio in your car. There's software that runs in there. There's software that runs on the generator that generates the electricity of the motor in your car that your headlights work on. There's software in each of these pieces. Traditionally, all of that stuff was written by hand, compiled by hand, and then installed and tested.

These days, the processors and things that you're developing them for are all emulated and run in the cloud. You think, "Well, why should I care?" Well, the reason you should care is because that then opens up a whole development process to the people who are developing these sorts of embedded applications. Because they can emulate the processors and it's all running in the cloud, it means they can run a whole bunch of more tests about it to make sure that it's stable and secure. That may not be that important when you talk about the chip that's in the radio in your car. Because who cares? But what about the chip that works in your father's pacemaker, or in an artificial limb? You don't want somebody being able to hack that? Do you? Or the fact that guidance systems and cars these days do a lot of driving for you. It's not like the old days where you're actually doing the driving and any computers in the car just kept the engine running well. Well, now the chips are driving, so security matters.

So being able to do that development on an emulated chip in the cloud then allows you to test that development very rapidly. That's a digital transformation. Moving from, "Oh, I'm writing software that runs on an embedded chip on the chip itself to running it on an emulated chip in the cloud." That is a digital transformation and that's opaque to anybody who's not in the individual field that's going through to it. That's a big piece that's happening right now. If you look at the EU, right? They've got these mandates in place that by 2030, there's no more internal combustion cars. Which means the cars are now going to be a 100% digital. You think companies like Fiat and Volkswagen Sat and Lada and all these car manufacturers, you think that they've done a digital transformation for these embedded software developers that they've hired? No. They're in the middle of trying to do that right now. So that digital transformation is happening and it's happening now and that's a good indicator of growth. Unfortunately, it's hard to see from the outside.

Maybe you have touched upon this already, but do you see other greenfield opportunities out there?

Yeah, kind of. Along the lines of the embedded software guide I was telling you about, let's take a look at someone who uses a whole lot more software and what their tools are. In particular, if we read the GitLab S1 where it talks about the total addressable market, and you look at the total addressable market and the GitLab S1, I don't remember the exact number off the top of my head. But that number represented the current spend on modern software development tools. So people who were already buying CloudBees and JFrog and GitLab and GitHub and Atlassian and synopsis products. That's what that number represents and it's good. But my issue with that number, and this will be an indication of growth potential, is that when you made a sale, the vast number of users who participated in that sale didn't already have a modern software development tool. So they weren't included in that TAM number. I think that the TAM number is understated and I think that there's going to be huge numbers of purchases by people who haven't bought anything in a while. Does that make sense?

That makes sense. Do you see the potential for GitLab to broaden their product offering to someone to address like needs outside of the DevOps space? So essentially to expand into other kind of offering so that non-technical users can be taking advantage of the platform.

So let's choose the game industry for example. There's an awful lot of technical users who write the games. There are probably half, again, as many artists that do the imagery in those games. Those guys aren't technical users. Yet your software build and deploy process, which is what is automated by using GitLab, is necessary for the assets that are created by these guys. Getting them to understand what the guys farther down the line, who are writing the code need from them in order to make it work is important. That's the sort of thing you use a tool like GitLab for. So making the portions of the tool that are important to them or important to other people that need to be accessed by those non technical users accessible to them is a challenge.

I can certainly see some improvement in there, particularly when it comes around defect management. End users of tools are not very technical a lot of times. So let's say the, I don't know, you got a ride hailing app on your phone and you're just some guy who wants a cab. You find out that when you use this thing half the time, it puts you at the wrong spot and so you can't find your driver. It's frustrating. How do you interface with the developers who could possibly fix that tool, who could fix the ride sharing app for you? How do you interface with them? Well, would be nice if you could just log a bug and say, "Hey, on my particular phone when I'm in this particular neighborhood, it always tells the driver that I'm somewhere else. Sure, I could open a web portal to let you log that, but that causes a problem for someone else. Because 800 people may log that same defect. Now I got 800 copies of the same thing and that doesn't do my developers any good. They'll spend all day closing duplicate stuff.

So being able to manipulate your tool, I mean, this is just one example. I picked on this because it's pretty easy and it's blatant when you explain it. That's a challenge that nobody solved well. If you could solve that well, suddenly you've opened up your tool set to an infinite number of people who can participate in the development process and the product will end up being better if they could, if you could make it accessible to them in a way that makes sense.

What do you think is the most misunderstood or under-appreciated aspect of GitLab?

That's a hard question because some of it has changed over time. When I first joined GitLab, the biggest problem they had is nobody knew who they were and everyone thought you were spelling GitHub wrong. Fortunately they're over that. There are two big things that I hear come up from a lot of people and one has to do with open source conversion. So I frequently will have people say, "How do you convert someone from using the free open source version of GitLab to using a paid version?"

It's not only GitLab that gets those questions. I'm sure Red Hat gets that question. The answer is you don't. That the free and open source version of the product is not targeted at the guy who's spending money. The free open source version of GitLab is targeted at exposing the product to an individual developer and individual developers don't spend any money. The enterprises they work for do. So you want to expose the individual developer to it so that he wants use it. So therefore the enterprise will pay money for it. Because the free and open source version of the product doesn't solve the enterprise's problem. It solves the developer's problem. So developers never upgrade from the free version to a paid version, but that's not its intent. It's never meant to do that. That's a very common misconception for GitLab is that, "Oh, look at this. You're not upgrading the free people." Well, no, that's not what it's for. You never upgrade the free people. So that's one thing.

Then there's apple and orange comparisons that you get a lot of times. There was a while where I would get a bunch of questions about GitLab where it says, "Hey, GitHub has, I don't know, 20 million customers, but there are only 2000 contributors to GitLab." You're talking about apples and oranges. A contributor to GitLab is someone who is helping develop the product by adding to the source code. That's not a customer. So those two things there's no place to compare them. So you asked about misconceptions about GitLab. There are two things that come up quite frequently. That last one that I mentioned to you happened most often in the months following the IPO. I haven't heard anybody say that recently. But it is, how do you convert an open source customer? That has been a question that I've gotten since even before I joined GitLab and even until today. It's not understanding the sales motion and the market dynamic of something like that.