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

Okay. We are live. We're back. Good afternoon, everybody. Once again, I'm Brad Zelnick with the software team at Crédit Suisse. Welcome back for day 3 of the 24th Annual CS Tech conference. This year, virtual streaming right into your office, right into your living room. For this session, we are delighted to be joined by none other than Mr. Olivier Pomel, who is the Co-Founder and CEO of Datadog. Olivier, thanks so much for being with us today.

Thank you for having me.

For sure.

Format of this presentation will be a fireside chat. I have a number of topics that I am going to ask Oli about. And as well, I will try to keep my eyes on my email. If there's something that you all would want me to weave into the conversation, just try to send me an e-mail, and I'll keep my eyes there. But other than that, let's jump right in. Maybe just for starters, Oli, Datadog is an amazing company, rapidly growing, solving important and complex problems. But for those less familiar, can you just give us an idea of what Datadog does and how the platform has expanded over time?

Yes. So what we do is monitoring and analytics, and we do it for companies that run the applications in cloud environments, be it private cloud or public clouds. And as you know, the good news is that just about everybody is busy moving some or all of their infrastructure and applications into the cloud. We started the company in 2010, and we started it as a data platform that would bring together the development and the operation side of the house that found itself fully at the heart of the problems that companies were facing when they're moving into the cloud. Our first product was infrastructure monitoring for this cloud environments, which we shipped in 2012. And then since then, we've expanded to what used to be different categories that now fall under the umbrella of what is called observability, things like application performance monitoring, or APM, or log management, user experience monitoring, network monitoring, all that kind of stuff.

Thank you for that overview. Maybe just to dive into what's been happening this year, and we've been asking this of many executives. I'm sure you get the question all the time, including recent earnings calls. But COVID has created a ton of challenges and, in some ways, has accelerated us towards a more digital world, a more digital economy. What sort of impact does this have on your business? And how, if at all, do you need to adapt to a new way of doing business?

Yes. So I mean, obviously, there's been an impact like on every single business. We -- the first thing that happened to us, actually, because of COVID, was that we did see like a slowdown in headwinds in Q2. As you know, what happened is a lot of our customers, the large customers that are at scale in the clouds try to conserve cash and save as much money as possible by reducing their cloud workloads, meaning trying to reduce their Azure bill or their AWS bill, which had an impact on the growth we get because we bill basically in the way that's directly correlated with the amount of infrastructure our customers move into those cloud environments. But we've seen that actually revert to normal after the -- after Q2, after the initial panic of COVID was gone. On the flip side, what was interesting is we also saw this transition to all remote and everybody at home and everything online, has a very clear win for the cloud. It was impossible in April to buy toilet paper, but everybody was on -- everybody's kid was on Disney+ all day and everything worked. And so the companies that were in the cloud actually could scale up, could scale down, could we do -- could change their mind and adapt, and the others could not. And as a result, we've actually seen a number of new companies embark on the cloud journey that did not before, companies like hotel chains and amusement parks. And basically, the ones that were especially distressed in that time also made it very clear to them that they need to transform and they need to join that party. So that was interesting. On the internal side, obviously, everybody switched to working remotely. We had to retool quite a few of our internal functions, things such as how do you involve employees, how to make sure people know their coworkers and how we couldn't make -- how do we make sure we know how employees are doing something that we do. We also have to change some of the ways we go to market. Counterintuitively, the part of the business that had the most retool was not the enterprise sales that meet customers face-to-face, but the commercial sales that call up customers on the phone. And the reason for that was all of us have only started calling up customers at work to calling up customers in home. This sort of changes the whole dynamics. So we have to make sure that we adapt and we retool the teams, and I'm super proud of what the team that have completed. It goes to show that humans are very adaptable. The unthinkable happens and then 2 weeks later, everybody is on to the new thing and just like nothing happened almost.

Yes. No, it is amazing. I mean, if we think -- if you had told me earlier in March that come December, I would still be effectively here talking to you from my desk at home, I probably would have had a hard time believing it. But thank you for that update. Maybe if I can, I wanted to ask you a question about the evolution of computing architecture. I mean, even since Datadog was founded in 2010, architectures have changed quite a bit as we accelerate towards this digital economy that we talk about, but we suspect we'll see an even greater shift towards containers and microservices-based architecture and even more femoral serverless computing workloads and things of that nature, which, by the way, people always talk about multi-cloud. To the casual observer who's not technical, that might just mean I'm a company that uses Workday and Salesforce. But what I really think of composite applications, relying upon fine grain services, you tell me, I don't know the extent to which there were really companies out there that are designing apps where different components are being served and serviced from different locations, whether that be edges or central clouds or across multiple public and private clouds in one end-user experience, for example. I'd be curious to get your sense of that. But as the underlying architecture sort of fragments, what sort of challenges does this type of complexity bring from a monitoring standpoint? And how has that shaped your roadmap?

Yes. So the way we think about it and we think about the problem is all that's happening has been happening over the past 10 years and is going to keep happening is just an increasing complexity. There's more and more and more complexity. There's more software being built in every company because they're becoming -- starting to interact with their own customers and users digitally. They have more engineers to write that software. They're making more change more quickly because they're becoming agile, it means they're raising every year, they're raising every month, every week, every hour. They have more pieces of infrastructure. And as you mentioned, these infrastructures are more dynamic. We went from -- if you go back in time, like we had physical servers. You'd buy them, you'd rack them. They never go anywhere. You could see them physically. And now you have microservices and Lambda functions, serverless functions that, basically, our [indiscernible] that's come up and done every millisecond we combine also on sorts of different ways. You also have many more software components. You have so much to choose from today, there's so much open source, there's so much SaaS services and things you can recombine into one application that just help you do more quickly, but also add a lot of complexity. So when you combine all of that, it's a race to complexity. And we see our job as a monitoring provider as being the company that understands this complexity and mix to humans. On the other side of it, understand where they are, what's happening, what impact their change is going to have, how they can make changes that actually works. So the software works and we can make changes to it. So this is the -- this is our job. Like we're here to solve the complexity, and we're here to be -- to understand the picture of everything that comes between the human and the bits that are moving in the machine. And we see that complexity just growing over time.

It makes me wonder with that complexity, it would seem that the value of what you're offering increases. Now on the other side, there's competition, but if you -- if the value of ultimately what you're helping to enable in terms of availability and uptime and response times and latency and things like that is increasing, if the problem you're solving because of this complexity is that much more difficult to solve on a like-for-like basis, I don't know if it's fair to even think this way, but should you be capturing a greater percentage for that same app as designed and deployed today versus an analog of it 5 or 10 years ago? Should you be capturing a greater percentage or greater economics of that budget? Or however, somebody might think of that. Is that fair? Do you think about it that way?

Yes. There's 2 things to think about it. One is in terms of the pure technical complexity. I think when you move from 1 big physical server to 1 million serverless functions and 10,000 containers that we combine in all sorts of ways in real time, obviously, you're shifting some of the value from actually running the infrastructure to understanding it to managing it. And so that's what we do. Another way to think about it is because of the digital transformation that enterprises are embarked on right now, the footprint and the impact of their software stack is increasing over time, with the end state being the whole business is running in software. And we see that today with some of our cloud native customers, the companies that just were buying the cloud and operate completely online. Their whole business is run by the application. So if they understand what happens in the application in real-time like they understand what happens with their business. So 2 words to think about it that tell you that, yes, this is -- there's tremendous amounts of value, and it goes way beyond keeping the lights on. It goes way beyond the value of, hey, if I -- if my servers don't come down, I will get more orders in. It goes towards my engineers can create more value and we can ship more software. They can generate more revenue for me because all my business is running online. And also because I understand what my business is doing, I can take better decision in real time. So this is this other whole -- what a stack base involved in that.

Got it. Very helpful. And as we think about the competitive landscape for observability and what you do from an outside looking in, it would seems like there are a number of other players in the market, names like Dynatrace or New Relic, even Splunk, to name a few, all seemingly going after the same opportunity. Can you just put some context around how it is that Datadog differentiates.?

Yes. So there's a few things. I mean -- so first of all, I'd say we actually are not focused on competition internally in terms of how we develop products or how we go to market. We try and focus on the customer problem, not the -- who else is doing what. The way we go to market also is focused on planning s many whitespace deals as possible because everybody is new to the cloud. So when we actually land into an account, we don't have to displace anybody else. It's not a knife fight with some other products that are being installed. It's -- the fight is to show value as quickly as possible to the customer and then grow with them as they expand their footprint in the cloud environment. Now in terms of differentiating, I think there's only a few companies that have scale and momentum. And I'd say the ones that are -- that have scale momentum, like you mentioned, Splunk or Dynatrace, these are companies whose roots and center of gravity is very much in the older guard of on-prem applications. Every single one of the enterprise customers we land in large enterprises, they're already running a Splunk somewhere on prem and maybe you Dynatrace or NetDynamics [indiscernible]. They're still going to make different choices to go on the cloud and use something that is purely cloud-native like we are. Our focus and our differentiation is to be born in the cloud, to unify all of the various streams of observability, everything from infrastructure monitoring into APM, to use our experience monitoring to log management, all the various facets of it and also to be built to be as widely used by our customers' employees as possible, meaning we're not differentiating by winning RFPs, by having these extra features that we can put a check box next to it. We are differentiating by having every single engineer use us every single day and have a so-called second monitor, so they can keep tabs on what's going on in the environment, and that's what guides all of our product they've logged in.

So if I've heard you right, I mean, you said a few things, but one of my takeaways is if the requirement is cloud first, then you have a natural advantage. I mean, is that fair? In which case, much of what you're running into is greenfield. But even if there's even a small percentage of opportunities that are displacement of a legacy provider who maybe didn't do an adequate enough job and somebody comes along and looks for the right solution, which happens to be Datadog, is -- just as the category matures, is that even happening more so today? Or is this such a small part of the demand that it's not even eventful to talk about?

So we see it today. Interestingly enough, these are the -- this is what end up being the largest land deals because customers have already reached some scale, and they're trying to replace something at scale as opposed to starting anew in the cloud and something smaller and then growing with us. So we'll get a few larger deals. These were from displacement. This is not what we focus on. I mean, for the one thing, the vast majority of the market is not attributed to it yet. In relation to that, and to much better use of our team's time to go after the net new, it -- even if you have the better product and everything else, it could you take you more time to unseat some existing deployment than it is to go into a brand-new whitespace deployment.

Well, that makes sense. Although when it happens, I can imagine, if somebody else went through the trouble of -- and the pain of sometimes landing and establishing the need for a solution, and then you get to come in and capture the expand, I could see where that's attractive. Perhaps to just change subjects, I wanted to ask you about open telemetry as we just think about the competitive dynamic, and it's hard to ignore the open source movement in the space, which I know Datadog has been a big supporter of. But if I take a step back and look at some of the changes in pricing and packaging of at least one of your competitors that they made while, at the same time, open sourcing the majority of their agents, it's hard to not draw the conclusion that this may be a commoditizing force in the industry in some way. So maybe, number one, what would you say to that? And number two, how, if at all, does this influence your thinking about monetizing any of your modules?

Yes. So first thing I'd say is on the open source side, we actually started with open source agent from day 1. So all of the things that we use to collect data on our customers' infrastructure are all open source, and they always have been. So that's something that some others are doing now, but we were on that from day 1. For us, we think the goal is to get as much data as possible from as many sources as possible. What matters is to make sense of it, to put it all together and to focus on taking care of the mess that comes in putting it all together, so that the customers won't have to when we can solve their end-to-end problem. So open source is very much part of our strategy. It's always been, and we're happy to open source what we do and we're also happy to -- on the customer side, we're also happy to integrate with whatever else there is out there that is open sourced, such as open telemetry to which we participate and so forth. On the question -- the broader question on pricing and commoditization, it's hard for me to comment on what other vendors are doing on pricing. I think they're trying different things. And obviously, in this case, we know they're trying it because the models that they had, it was not working, so they're trying to shake things up a little bit. We're not a big believer in per user pricing for most things. There's a couple of reasons for that. One is that it limits the usage of the product, and our mission is to get as much data as possible to as many users inside our customers as possible. So we think it stands in the way of doing that. Another reason is that for what we do for the same user, that can be a 3, 4 orders of magnitude of difference in terms of the amounts of data generated. And so it's very hard to actually design a model where you go for quality and, at the same time, you only price per user. Like you end up with a situation where you either go out of business or you have really, really, really bad service [indiscernible]. So we don't think it's -- that is the right thing. Going back to the broader question of commoditization, I think if you zoom out a little bit and if you think of the broader picture, the one we just discussed around complexity and complexity just shooting up over time, and the fact that there's going to be much more value to be captured by actually making sense of it, we see the opposite. We see that the problem is getting harder and more valuable, not more commoditized. What's getting commoditized is solving the problem as it was 10 years ago. But the thing is 10 years ago is where we were maybe 10 years ago as we move forward. That's not the problems companies have today. And so that's the -- that explains the race to complexity and the race to making sense of all these data and the growing importance for our customers. Another way to look at it is to think of the -- if you want to think of the broader market, the cloud providers, I think, has a total of maybe, what is it, $90 billion in the ARR or something like that, and it's growing at 35%, 40%.

That's about right.

And this is -- we are going to claim a larger and larger share of that revenue as time goes by. That gives you a sense of the opportunity. That gives you a sense of the raising around basically. So commodity is not what worries us.

Well, to that point, thinking about your opportunity as a derivative of what the cloud service providers are doing. And I think everybody agrees, as we look out on the horizon, that's hundreds of billions, if not $1 trillion plus in size in terms of total opportunity. What are the reasons that, as a take rate or a percentage of that, the category and/or Datadog's opportunity should be more or less? And maybe along those lines, as you talk about pricing, when I think about pricing and software, especially in infrastructure software, I always describe it as sort of a best fit curve. You're not going to really match the specific needs and value exchange of every single customer, especially your largest ones, which is where discounting comes in and ELAs for certain companies and all sorts of mechanisms. So maybe, I guess, the question would be from a price perspective, if it were to evolve, along which dimensions do you think it may make sense, if not for a per user model, and I appreciate all your comments as to why that might be limiting? Is there any reason to consider evolving it from where it is today?

Yes. At the end of the day, as you pointed out, all pricing is imperfect. And what you're trying to go after is you want to understand what's the best proxy for customer value. You also want to make sure that it is -- it doesn't introduce friction. In our case, we're very lucky in that good proxy for customer value is the complexity and the size of their cloud infrastructure. So basically, a good proxy for that is the cloud bill and the many components that go into that, which is why most of our products are priced on a per plan instance basis, which basically track our customers' cloud bill. And so that's a -- it's a great way to also have a model that also doesn't introduce friction because we don't go -- we don't need to go and call customers up. When they expand into the cloud, they don't know -- they don't need to know where -- to go and call us up either, and it consumes us in a way that is very similar to the way they are going to consume AWS on Azure. So that's a very natural fit this way. As we pointed out, another source of complexity is the number of users. In some situation, it might make sense to charge per user. In most for us, we think it doesn't, so that's not somewhere that we go. Over time, as the way our stack -- or customer stacks are built and the various components that come into it and hold the way the pricing models for the infrastructure vendors and the cost of their [ generators], as all of that evolves, we might change the pricing model as well. But the key goals for us are to have something that attracts the values, attracts the complexity of our customers' environment, attracts the -- it doesn't have friction and that also gives customers control, so that they can align what they pay with the value. And that's something that comes to -- continues to play, in particular, when you think of machine data and things like logs, for example, where any application can generate any arbitrary large amounts of logs. That's fairly divorced from the value that you can get out of them. And so what we do for that is we try and unbundle things as much as possible and give real-time controls to our customers, so that they can decide to turn on, turn off, sample, archive, process, not process and which part of processing they want. So they can really fine-tune what they get and what they pay for.

Very helpful. Maybe to just shift gears a little bit, Oli. I've been amazed by the rapid pace of innovation that you've been able to sustain. In your most recent user conference at DASH, you not only released new features to already existing modules, but you introduced completely new modules like continuous profile or compliance monitoring, which extends you deeper into security use cases and incident management. Can you maybe talk to us just about the bigger picture? Why is it so important to continue this rapid pace of innovation we've seen? And how do you make sure you don't stretch yourself too thin in terms of focus or even resources to support all of this? And should we think of this innovation as more to sell into the existing customer? Or does it drive overall differentiation to improve your overall relationship and use case win rates, if you will? I imagine it's some combination of all these things, but I would love to hear your perspective.

Yes. I think the -- we always -- the goal was always to build a platform that would bring as many data assets as possible to usually the dev and ops team. And I think, right now, we are adding the security teams to that, and the value prop is fairly similar, and the problem we're solving for them is fairly similar to the issue we had between the dev and ops being separated. So this is a continuation of that. I think, to your point, we can't start innovating on the core products. The infrastructure monitoring, the APM and logs are the first products we had because we're still extremely early in the technology cycle and the production cycle. And the race to complexity we mentioned earlier is not stopping. So there's a lot more that's going to go into that. That's the majority of our investment today. And the good news is because of the large customer base we have there, we have a great amount of clarity on what it is we need to do, and we need to add to that. In addition to that, we wanted to make sure that we position ourselves for solving the broader problem we achieve, not just observability, but everything that relates to understanding your infrastructure, your application and how they -- the impact is on the business. And for that, we have to enter also additional categories. So we -- this year, we entered security. We released a few products in security. It's still very early. It's still going to be a very long burn there. But -- and it's not something that the customers were not clamoring for it. Customers typically clamor for something that is incremental. But we did see customers building their own security systems and security automation and analysis on top of Datadog. So we have the proof points that it make sense to them, and we could actually build a product that would serve those needs for them. So we're expanding the security. And we have a few more categories in the long run that we want to expand into. One of them is potentially ITSM. Another one is potentially real-time BI, that -- for which we don't have any products out today, but we think they are categories that make sense for us in the long run. So to your question about spreading ourselves too thin, we're always super, super careful about that, right? I think the -- that's why we only entered one new category this year. We know it's going to be a long burn. We know it's going to be a long investment. What we prefer to do, though, is we prefer develop in the open. We prefer to ship to our customers early and have them involved, even when the products are very small or they have very narrow placability, and they only target a very small subset of our customers because this, to us, make sure that we solve the right problem. The question -- I've seen all my career in software is not that you build back software, it's that you be able to use that software. Like you solve your own problem. We're trying to optimize for that.

Fair enough. Just with respect of time, I think maybe we can fit in 1 or 2 more questions. Perhaps I'll touch a little bit more on security, which has been an area of focus, and you've introduced compliance monitoring, like we talked about. But how should we think about your broader ambitions here? Should we expect to see a full-fledged SIM offering from Datadog in the near future? Any way that we should maybe think about areas in which you definitely will not pursue versus ones that are very interesting to you? Any sort of guidance would be helpful.

Yes. And so what's interesting about security is that we see a lot of the same problems that we set out to solve initially for dev and ops. When we started the company -- the reason why I've started the company was [indiscernible] is that I used to run a dev team, I used to run the ops team, the teams were fighting all the time, and we thought we should find a way to bring them together. It turns out, in most enterprises, it is the same situation between the DevOps teams and the security teams. They typically don't work super well together. Often, their incentive out to each other. And as a result, it's very, very hard to operationalize security. So we think we can do something similar there. In addition to that, while the on-prem market and the corporate IT market for security is pretty much mature, everybody is using a set of tools for that already, the cloud market is completely open. There's no dominant way of doing things. There's a lot of open source, a lot of build-it-yourself and a lot of -- not done properly. And so we think -- we saw a great opportunity for us there. Now in terms of the -- how we think of that and how it relates to existing categories, the closest you can -- closest fit for what we're going for initially is maybe a SIM, but we only have a small part of that today. It's a long deal towards getting a fully pledged SIM that is specific to products and applications in cloud environments, which is where we're starting.

Excellent. Oli, with that, we're unfortunately out of time. This has really been fantastic. Is there anything that you want to leave us with that maybe we haven't touched on as investors -- what might we think about as we move into next calendar year? What would that be?

Well, I think interestingly enough, the next calendar year, despite everything that happened, looks a lot like the old calendar year. Like it's -- we see the world exactly the same way. It's super early in the big transition. There's the a race to complexity. There's a need to, on our end, to both cover as much of the market as possible from a go-to-market perspective, which means developing our teams around the world and channels and cloud partnerships and all that stuff. And there's also a huge need for us to cover more of the problem space, which is why we are busy hiring engineers and developing new products and entering new categories. So it's a little bit boring, but my -- when I look at my goals for 2021, they're actually very similar to my goals for 2020. Except now, I also know I really would like to come back to an office at some point.

You and me both will. Here in New York, hopefully, we get to see each other in person in some time in the months to come. But with that, thank you so much. It's always great to see you. And hopefully, we'll see you soon.

Likewise. Thank you.