Datadog, Inc. (DDOG) Earnings Call Transcript & Summary

Okay. Good morning, everyone, and welcome to the Oppenheimer Tech Conference. This is our first day. And my name Ittai Kidron. I'm a technology analyst at Oppenheimer. And with us today is Datadog, Olivier, the CEO; and Yuka, IR, watching over, making sure everything is okay. Olivier, thank you very much, and Yuka. Thank you both of you for joining us today for the session. We will do a little bit of a fireside chat here, conversation. But then, of course, we like the audience to get involved as well. You have a Q&A opportunity there on your screens that you can use. And also, for those that know me, you can e-mail me the questions. I'll be watching -- I'll be multitasking here and watching the e-mail at the same time. And as questions come in, I'll try to work them into the discussion. So guys, thanks again for joining us today. I really appreciate your attendance.

Olivier, I followed you for many, many years, and it's been quite impressive to see the evolution of the company. Maybe you could talk about quickly the evolution of the company, how you've expanded into observability, more recently, DevSecOps, cybersecurity. Help me think about the evolution over time. And also, how do you think about the gaps in your portfolio and the direction of the company going forward?

Sure. Yes. And first, thanks for having me today. So when we -- when I started the company with my cofounder, Alexis, we didn't actually set out to -- or set out to build a better mousetrap. We didn't say, hey, we [ sell ] a better customer monitoring product or -- we set out really to be able to have a platform that would be as broad as possible. It brings all the teams on the same page, like the teams -- those teams can actually share the same understanding or the same reality and work together towards that. So we started building this data platform. And then we just have the first use case for it, which was cloud infrastructure monitoring. And we stuck to that use case for many years because there was a ton of traction for it, obviously. The whole market started building from legacy IT to cloud environment, and it gave us a really good way to enter inside of customers' environment. But really, we always wanted to expand past that. And as soon as we could, we started branching into the other parts of the broader observability, particularly which were APMs or application performance management and log management. And in 2019 is when we actually saw good traction for APM and log management. And that really was, for us, the point where we decided to take the company public. It was the proof point that we could grow beyond a single product company, that the platform vision and the data platform vision could actually come true, and that we could deliver growth for many, many, many years as we kept adding use cases, having new personas and rolling out different historical categories into our platform. So obviously, we've kept adding to the observability suite, and we've added either experience monitoring, even waves. We've added network monitoring. We added database monitoring. There's a number of things that we've added in there that we sell part of the broader observability category. We also started entering new categories that were quite separate, but which we think, in the end, target the same users or the same systems with different users and belong in the same place. So that's the case, for example, of security. We think security is not a sole problem, security monitoring, security automation in general. And we think that the way it's been approached to that by security specialized vendors is just not going to work. So we think we can have something to bring there that is very unique, and that we can solve that problem in interesting ways. So we added security. We started entering more into developer workflows with obviously [ ICDs ], observability products. We see many more applications to what we do in ITSM workflows, in real-time BI, which is categories that we don't have really product SKUs to [ die for ], but we think are very relative to our platform. So we see plenty of paths for expansion. And we want to keep doing what we've been doing so far, which is use of very large surface of contact with our customers to expand and solve a bigger problem for them. So I think we're still -- the way we present it is we're still on discussion with surface, and there's a lot more work to do.

Interesting. So -- but again, at the core of all this correction from, Olivier, is the data platform, right? That's what it really enables all of this optionality on top of the platform.

Yes, it's the data platform and the fact that the whole product is targeting a very broad set of users. It's not -- we never built it as a specialist product, something that, in fact, people use all day long, but everybody else is scared of. We've built it as something that should appeal to every single engineer, every single product manager, every single business analyst.

Got it. So I guess, if I had to put you on the spot here and ask you if you had to use one word to define your company, what are you? An observability company? A security company? How would you define yourself?

Well, one word is going to be difficult. But the way we see it is -- what we aim to be is the platform that stands between the humans and the [ bits ] in the enterprise. Basically, everything that has to do with understanding the applications, building the applications, securing the applications, understanding what they are doing for the business. And by the way, if the business is digital, the application is the business, therefore understanding the business itself. That's what we aim to be. You can think of it as the nervous system for the digital enterprise system.

Got it. Okay. That's a great way to define it. All right. So going back to the core, where we started, the infrastructure, how much of that is still the most common landing spot with new customers? And can you talk about the balance of the revenue mix between infrastructure and the rest of your business right now? How has it changed? And if you and I will talk 2 years from now, what would you expect it to be?

Yes. So we -- this is still a product we lean with, infrastructure. And we see it in most of our new levels. It doesn't necessarily have to be this way that we've seen. Some other products can also lend themselves to being great new logo drivers. For example, synthetic testing tends to be like -- it can actually be a great stand-alone readable product. However, we haven't seen a need to mess with what's working. It's a very big trend of sales force to align the marketing on lending new logos with the infrastructure monitoring product. It also is a product that sets ourselves very well for growth because it tends to be the [ preferred ] tool in the environment, has a large surface of contact and is a great basis for expanding to other products after that. So it's still mostly what we live with. And we see no reason to mess with that too much, even though we're experimenting a little bit with the ways we think we can generate more growth by having other products in the mix as well. We -- in terms of the revenue mix, so 4 years ago, it was pretty much all of the revenue. Today, we didn't disclose the exact mix, but we said in the last call that the other products like log management, APM, et cetera, were about [ $150 ] million in revenue. So what this tells you is that infrastructure, if you zoom out, but very broadly, it's about half of the business. And it's -- the rest of it is growing a little bit faster, but infrastructure is still growing fast. So moving forward, it's going to be a smaller and smaller proportion of our revenue. But we don't really care so much like when you -- in terms of where the revenue comes from the observability side because we think that there is a -- the category themselves are very backwards looking. But there's quite a bit of fungibility between them in terms of how you can solve the [indiscernible] consolidating with infrastructure monitoring sometimes, sometimes you can consolidate with APM, sometimes with logs, sometimes it doesn't matter. So it's too hard about that, but we see it mostly as the correct line in product, the basis for the business on top of which we -- what we spend.

Got it. As we think about market adoption so far, if I try to think about your new business in any given quarter and perhaps how much of that new business is a displacement versus a greenfield as sort of an indicator perhaps for the -- just broadly speaking, right, the adoption of these types of tools within customers, how much of your business of new business in the quarter is still a greenfield versus a displacement?

The majority of it is greenfield. And when we say greenfield, it means it doesn't displace another product at scale. It might -- it always does, to a certain extent, complement or displace some open source and do-it-yourself, because everybody, every single customer has that somewhere. And the reason we do it -- like we actually keep it this way. We're focused on greenfield because the whole market is transitioning. Everybody new -- everybody is new to it, [ understanding ] small. And also, it's the best way to -- or was the best use of the sales team's time, basically. But yes, we win a number of displacements. We mentioned them on the earnings calls. But they tend to consume more energy than going after the greenfield. So in the end, if you think in terms of productivity per dollar spent on the sales and marketing side, you get much better returns from [ publishing ] on the green space.

Got it. Well, it'd be fair to say that while a lot of new business is greenfield, a lot of perhaps expansion is brownfield?

It's true, yes. You will see that as customers expand, especially as they're getting deferment to the term migrations, they're going to retire some of the tools they were using before or stop expanding some of those tools and extend with us instead to come by. That's definitely [ different ].

Okay. Now I want to talk about your module approach. Again, you've added all of these capabilities that you went through. There's a very large list of things that you do right now. Do you feel, though, is there a risk where just growing the list of capabilities and products could create either customer confusion, on some level, could undermine perhaps your ability to penetrate within customers? How do you keep people focused? I guess, that's the question, and make sure that they'll get lost in the shuffle of all of this stuff. And then second, I guess, you're still clearly evolving the product. But what if, Olivier, you and I talked 2 years from now, and it's actually the number shrinks because things get consolidated and streamlined to just to facilitate better, faster adoption.

Yes. So there's 2 sides to the number of volumes. One is the demand side and the customer, and are already dealing with that. And there, I would say, we have the luxury of being able to look at what the platform providers have done. Like if you look at the U.S., they have the magnitude of more SKUs than we do. And it seems to be working fine for them. And by the way, the customer is the same, he likes the sort of these products are being adopted. And you see them being at scale to the tens of billions of dollars in revenue and growing at higher rates. So I think they're not being held back by that on that much. That's on the demand side. On our side, what we get from having all these different modules, and there's different SKUs, is that we get extremely clear signal on where the value is most working or is not working. So when we shift the functionality, in fact, with customer SKU, these customers buy it. If they paid for it, if they expand with it, we know it's working. If there's so much strain from it, if they don't want to pay for it when we start charging for it, then we're not giving value. And it is how -- as a company, that you can expand in many directions with many new products. This is how we keep ourselves harnessed, basically. This is how we know we're working on things that actually matter. The track, otherwise, I mean, it's very easy to fall into is to build the good stuff and not have any idea anymore, what's good there and what's not good there [indiscernible].

Got it. Okay. So very interesting. All right. I want to dive a little bit into cloud security, which is a relatively new area for you. You have posture management, cloud workload protection and cloud seam. You've recently expanded into application security monitoring, and you just bought an API security, if I remember, just last week. Help me think about -- so what has been the adoption of these solutions so far? But this seems to be a push in the industry towards a CNAPP type of architecture around this. Do you share the same view from an architecture standpoint? And if so, what are some of the missing gaps you have right now in order to deliver on that vision?

Well, so the field is evolving fairly quickly on the cost security side. I would say, one specificity of security is that there are a lot more acronyms and vision, they change a lot more quickly than on the -- than we decide. So we have to invest more outside of layers on our end for that. The CNAPP is, I would say, the new, we refer, category that is emerging. I don't think it's super clear yet with what it encompasses and what it doesn't. But what seems to be clear is that customers are trying to respond to it, and they understand that they need it. So it's possible that we refrain some of things we do in terms of holding the right to CNAPP artillery in the future. But in terms of where we are today, we have to build up a long build on security. There's enough -- the problem is so vast that we know there's a number of areas we need to cover. There are some we covered very well today, and we have -- we mentioned in previous calls that we have thousands of customers, paying customers, on our security offering. We see very high growth on the [indiscernible] from a small base, and we get a lot of customer pool there. What we hear from our customers, though, is that there's a ton more they want us to build there. There is more frameworks and cloud vendors and products they want us to support in terms of our coverage. There's more flexibility they need in the rules and what they can do with them. They're for automation. They know on the -- what they can do with them, there's more coverage, which is why you see us do things like buying this -- big API security company, Seekret. Customers need more, and they're giving us the tool we need. So we're very, very happy with the situation we're in right now, where we have this very clear signal from them. It's clear, the intent to use us. This clear revenue stream with them, and we can do this deal with them. It's very similar to what we've experienced when we're building the infrastructure management product back in the days.

Got it. It's interesting. I guess, along those lines, Olivier, it's clear that it's important for you to cover the entire cycle, meaning the dip side and the run side, right, of application security. Because you've had the [ SCA ] and [ IASM ] and RASP through acquisitions as well. And so help me think about the connection of the dev and the run time from an application security standpoint, but also maybe perhaps you can add later on top of that. From a go-to-market standpoint, are these -- everybody's talked about DevOps, when in reality, most organizations is still separate or parts running. So how much does your go-to-market needs to evolve in order to address this? Are you just going to have to wait until the market to come to you? Or do you need to kind of straddle both sides of the equation here?

Yes. So on the first question, it's very important to cover the dev side. And we actually think our differentiation in the -- I mean, there's a couple of things we differentiate on basically aside. But one of them is that we think to actually solve the problem, you can't just rely on security engineers because there are not enough of them. You need to rely on the ops folks and on the dev folks, which means you need to cover the whole spectrum between what the ops team and the dev team is doing and the security aspects of product environment. So that's why we're investing in the full stack, not just the posture management or the CNAPP side of things, but also application security and how to analyze the data of the engine. We also differentiate, by the way, on the lack of friction in terms of instrumenting everything because we have all the instrumentation underneath. So our customers don't need to spend time expanding the applications for security purposes. They'll need to build performance stacks because they are going to intercept data one more time. They also don't need to pay data tax by sending that same design to another place. So we say we can easily be more efficient at the future security efforts for that. In terms of the go-to-market, I mean, you've clearly identified the fact that the buyer can be a little bit different there. So for everything we've done today, the buyer was largely the same person who is paying the deposit [indiscernible]. In security, you might have a lot of that falling under -- on the CISO. And it comes with -- even though the needs are going to be the same, it comes often with a bit of a different language that we need to see here. So as we keep building the product and as we keep interacting more and more with that side of the shop, we also are building our go-to-market team to focus on that part of the [ one ]. The first signs of that, as you'll see, is that we started different blogs in different research teams to focus on security. So we have a blog right now that publishes our own research on security. That's something new. That's something that happened a few weeks ago. And we'll be investing more on that side to associate on their own language more, with the exception of Seekret.

Got it. That's interesting. From a partnership standpoint, what I find interesting is that in your space, right, in your core space from observability, you don't really need to interoperate much with your competitors' tools. But I find that link in security, it's a slightly different animal. So when you think about companies that operate in the app security space like -- I don't know, like a Snyk or like a Sysdig on container security, do you envision partnerships on the security side evolving here? Are they going to be a little bit more important to either, a, bringing you a little bit more credibility also in this space, but also filling in gaps, which naturally will take you some time to fill up?

Well, we were also integrating with everybody else, and then some. I mean, we've done that on the observability side, too. That's when we started. We're mostly integrating with our products in terms of data we were getting before we had first-line solutions for a lot of the other use cases in recovery. And we're still doing it today. When we think of automating response to incident, that we actually need to integrate with everything our customers have, so yes, then we integrate. Again, we hate to be the nervous system for our customers, but we see some parts of what they use connected to what we [ go after ].

Got it. Okay. Shifting to the R&D side. You're clearly in a very good position, and you're profitable at scale. You're spending about 30%, plus/minus, right, of revenue on R&D. Help me think about the balance of that investment between innovation, new products versus kind of maintaining some of your existing solutions that have been existing for some time.

So nothing is in [indiscernible], everything is in -- everything is being aggressively developed right now. Because we think, even in infrastructure monitoring, we're still very early. The world is changing quickly. As in the middle of the game, we know since we started the company, that there are multiple transitions within the transition. You'll retain from -- would come from a -- VMs to cloud instances, switching to containers, several layers, now maybe to some edge, several layers. I think there's all these things that are happening that require continued investment and continued evolution of the product. So everything is being actually developed. The way we think about it is not so much in terms of a brand-new products versus existing products. It's more in terms of would a fraction of our engineering investment go into the platform and what goes to new products. It's about half and half. Like about half of the -- that's actually for the teams organized. Half of the team is organized on the underlying platform and everything that is shared with new products. And the other half is working on SKU-specific products. This is what we call use case-specific developments.

Got it. Okay. Well, clearly, you're doing extremely well over there from an innovation standpoint. Let's talk about competition. Some of your competitors have had more challenges recently. Can we think about what you see out there in the marketplace? And clearly, you're running at a very fast pace. But how much time do you really spend -- or an effort do you make in trying to find the customers of those companies specifically and try to kind of target and more aggressively try to displace versus just keep head down and running doing what you're doing with your -- a lot of the greenfield adoption?

So we keep running mostly on the greenfield. Again, it's more efficient from a DORA's in, DORA's out perspective or timing DORA's out perspective. And that's more of a granular long-term success. Also, it's -- I personally think it's a bad idea to try and go and specifically unsafe careers. Because we, thanks to the only few, if you try to force it, it is that it brings your product too close to your [indiscernible] products. Because what you do is you go talk to one customer and yes, they want your product because you product's better. But they'll say, "Well, because this feature, I'm using this old product that we like, you need to give me now a figure, so up to you." So you'll do it. And then you'll repeat it for another 15 customers. Then it will end up with you getting your computer product as opposed to building your own future and where you might need to go. So if you try to force it, it has negative side effects than upgrade. That being said, when it comes from customers themselves, when they are the ones comes to realization that, "I need to standardize. I'm sick and tired of what I had before. It's not delivering what I need to deliver. I want to send it out on you. That's a very different conversation. And that's a conversation we're very happy to have with them.