How to Build and Sell a Product that Customers Love with Olivier Pomel, CEO Datadog

My name is JB. I'm one of the founders of Plato. So let's start with a simple question. How many of you guys' product rely on a highly functioning engineering team? Yeah, everyone, right? So that's pretty much what we're trying to help at Plato. Helping the engineering teams run smoothly and being super productive thanks to mentoring. Super privileged and excited today to have Olivier here. So for those who don't know him, Olivier is the founder and CEO of Datadog. So why don't you tell us a little bit about what Datadog do?

Sure. So hi everyone. Yeah, looks like it's working. So, so Datadog, what we do is we do monitoring and we do analytics for application and infrastructure in cloud environments. So basically any company that is running infrastructure, servers, applications, and that is running it in cloud environments is a customer for us. And the good news is that just about every single company is busy right now moving from legacy to public and private cloud. Cool.

It's a very niche environment. How did you end up in that world?

So we— so I started the company with a longtime friend friend and coworker of mine. And by the way, we started the company in the US. So despite the French accent and all of that, I've actually lived in the US since 1999. And it was natural for us to start the company in New York. So what happened to us is that we had— in a previous company, I was running the development team, and he was running the technical operations team, or ops team. And the story there was that we knew each other very well. We had worked together in 4 different companies before that. We hired everybody on our teams. We scaled them from scratch, basically. We had a strict no-drag policy. And yet we ended up a couple of years down the road with developers that hated operations, operations that hated developers, finger-pointing, all of the things that you can imagine. So the starting point was, why don't we give all of those teams the same viewpoint? Like, how do we get them aligned and understand their problems, their infrastructure the same way? So that's how we got started. We started the company in 2010. We didn't quite understand at the time that the cloud was going to be so big. We thought, hey, you know, it looks cool. Why don't we build it for the companies that are moving to these new cloud environments? Maybe that's a great way to get in. The other thing we didn't quite realize was that bringing Dev and Ops together, bridging those two teams, was not just a feature of the new world, it was actually one of the key reasons why companies and enterprises would be moving from legacy IT to the cloud. So we ended up right in the, in the center of it. And when you fast forward, you know, today the company It's about 700 people. We've been doubling the size of the company every single year. And it turns out, you know, everybody is moving to the cloud and everybody needs to understand what's happening to their systems and applications.

So living the problem first, that's what, that's what's at the root of Datadog. So we're here to, to talk about building and selling a product that customers love. So extremely relevant because I think not only your self-proclaimed, but also acknowledged in the community by being one of those companies that actually are very customer-centric. So let's start with what is, in your opinion, a customer-centric company? What's your definition?

Right, so the one thing that's counterintuitive is that everybody wants to be a customer-focused company.

I'd like to consider myself like so.

The problem is that most companies end up being either sales-driven or engineering-driven. And if you want to be customer-focused, you can't be either of those. So you have basically to keep correcting what's happening within your sales teams and within your engineering teams to make sure everybody is focusing on the customer first. What this means is that, you know, if you let everything be sales-driven, you'll end up being very short-term. Sales teams are great at figuring out what's going to get a deal done, and very often getting the next deal done done is actually not what you want to do for the long run for your customers. But on the flip side, if you let your engineering teams run on their own, you'll end up with organizations where people focus too much, way too much on their solutions, focus way too much on the long term, what will make sense and be sustainable in the long term. And you end up bridging that gap back to the customer, which is hard. So I would say it's a struggle of every day to make sure that we go back to the customer and and start from there.

And how did this kind of style of management or company culture start? Was it a conscious choice?

So the choice for us was actually we were forced to do it. Because when we started the company, it was really, really hard for us to raise money. So we were based in New York, which is not the obvious place to start an infrastructure company. Most of the companies in the US started in that space, were in the Bay Area. Neither my co-founder or myself came from Google or Facebook, you know, so we didn't have the obvious credentials for, you know, helping companies run at very large scale. So basically we didn't have, you know, millions and millions of dollars. We didn't have a whole suite of people that were repeating to us that we were geniuses so they could invest in our company. So we basically had to focus on the problem. Like, we spent the really the first couple of years of the company listening to customers and trying to understand what the problem was.

So that, that's how it all started. So let's come back over the course of Datadog. You've been around for 8 years, and let's, let's start from, from the beginning. So if— how did it all start? So if you could Give more details about these first 2 years. We discussed it earlier, there were multiple phases. And how did you manage to be customer-centric in those early days?

Yeah, so the first thing we did is, so when we started the company, even though, so I'm an engineer, my co-founder is an engineer too. For the first 6 months of the company, we didn't write a line of code, which took some restraint. 'Cause you know when you start a company, you're super excited, you want to get it done, you're thinking of all those beautiful things you can build. And so instead of that, we actually spent all that time talking to potential customers and potential users. And the thing that we found out there is that, so first of all, when you don't have anything to sell, everybody is super happy to talk to you. Like you'll get hours and hours of really fantastic people at fantastic companies, and they'll spend all that time explaining to you what their problems are, what's working, what's not working for them. They'll be extremely candid. That changes once you have something to sell, because then, you know, you're tainted. You have too much of a vested interest, and you're trying to push something, so people won't open up so easily. So it's actually very easy to do that super early on. So then after that, what we did is we built the first alpha of our product. So we spent 6 months building the first alpha, got it to deploy it into a small number of customers. It was— we actually noticed that the product was not exactly what it needed to be. It was way too open-ended, way too general at the point, at the time. So we had to change that quite a bit. But also, one thing that we— that was counterintuitive to us was that we were really limiting ourselves by strictly gating the access to our product. So we had a closed alpha. We handpicked the people that would actually be on the alpha. We tried to pick the best companies, the best people at the best companies. And it was actually really, really hard to get a lot of signal from these customers when we were doing that. What we ended up doing after that is we opened it up to a wide beta. And all of a sudden, everything changed. Because as it turns out, it's a lot easier for users to self-select and to go and start using your product than for you to understand for whom you're going to be the right thing at the right time, and they're going to have some some free bandwidth right now, and all the stars will be aligned so they can, they can get you deployed.

All right, so open beta, or open beta, that was one of the secrets. Um, you're not a strong believer in the MVP, right?

No, I actually don't think for what we do, I don't think it does— an MVP exists. I think it's a completely— there might be exceptions, right? But in our case, we sell to enterprises, we sell a product that serves a fairly large purpose, like it needs to monitor everything that's happening across the whole infrastructure, the whole application. Like there's a very large number of features our customers rely on. And none of these features in, in and of themselves are revolutionary. I mean, that's not why we build a product. Like there's all sorts of differentiation we built in. But you need to have them, otherwise you cannot be minimally useful. And so the way we see it is it's more of a continuum. Like you keep adding those features. And then at a certain point you have enough of them that customers can start buying. And the, the hard part there is to figure out really how you know which of those features are, and that's why you have to again go back to the customer, make sure you have enough of them so that you can actually extract some signal from those conversations.

So we're 2 years in, you're on the market now, you've launched. And so that's the next stage for the company. So how do you now at that stage make sure that Datadog is still customer-centric? So what are the things you put in place? What are the tricks and hacks? And how big is the company at that time maybe?

So the product went to the market when we were about 10, 15. And I think that phase of reaching initial scale, I would qualify it as being from 10, 15 to, a bit less than 100 people. So, so at that time, so what we did is, so first of all, we wanted to set ourselves up so that we would be directly aligned with our customers. And one recurring theme for us is that we want to hear the bad news quickly. We want to— actually, we're looking for the bad news. Like, you're not going to learn anything if you, if you go and meet your customers and you say, you lead by saying, isn't it great? And they say, yeah, yeah, it's kind of great. And then you find out actually it's not all that great, and they're going to churn, and something bad's going to happen. So you actually want to get the bad news. One way structurally we set ourselves up for that is we didn't sell— for a very long time, we didn't sell yearly deals. We only sold month-to-month, meaning that customers had the opportunity to churn all the time. Meaning if something is wrong with the product, Or if we don't solve the right problem, you know, it's not valuable enough, then we know right away, like, customers are just going to churn. We can have a conversation with them. If you don't do that, if you, if you start selling term deals, you're going to have the bad news about a year later, and by then you've wasted a year, you've gone in the wrong direction, and you've done all these mistakes that you could avoid otherwise. The other thing that we're doing, that we were doing, if we're still doing, was that we wanted to make sure that the whole company was was as close to the customer as possible. So for example, we had the whole engineering team on support rotations. So we still had professional support. We have support engineers that are in the front lines and that do a lot of the work. But every single engineer is on a 1-week rotation throughout the year that actually brings them in front of the customer. And it's fantastic because, first of all, engineers are super happy when it starts. And they're even happier when it ends and when you don't have to start to fix all these issues. But really, what it gives is it gives a lot of empathy for the customer because they see actually what problems they face on a day-to-day basis. They also see the consequences of their choices. Sometimes certain things in the product look like fantastic ideas, and then when you see it from the customer's perspective, it turns out, yeah, actually it was It was a bit confusing. So it was a great idea, but we're going to change it because it doesn't work quite as well. The other thing we did to expose the engineers to the customers is we actually— we do a lot of event marketing because we sell to companies that migrate to the cloud. And most companies have to go to events to learn about it. Like, everybody's new to it. So everybody's going to conferences for that. So we go and we exhibit at these conferences and we give lots of demos. And we actually bring engineers to do all these demos, and everybody's on rotation and everybody's going to get to, you know, 1, 2, 3, 5 maybe of those conferences and spend every time a full day basically giving demos to potential customers or existing customers and answering questions. And that's something that also, it helps build empathy for the customer. It also helps make the whole engineering team more confident about the problem they're solving and about their relationship to the end user.

You had an interesting trick at the events to make engineers more comfortable. I mean, we're also selling to engineers, and some of them are introverts, or like communication is not for some engineers like their best skills. And you had some interesting skill, like trick, to make them feel more comfortable.

Yeah, so one thing that's not natural when you're an engineer like me, actually, is going and seeking other people's attention. Like, you're not— I don't want to use stereotypes because obviously everybody's different, but generally speaking, a lot of engineers are not going to be super comfortable trying to talk to 40 different people in 2 hours. That's not what everyone's job is on an engineering team. So what we do for that is we actually have other people on the team that are responsible for getting people's attention and then introducing them to the engineers so that there can be a demo. So then everybody enters a rhythm where engineers can do demos and answer questions, and there's never a shortage of people talking to them, which solves that issue.

And so, you know, some people say you can only improve what you measure and track. So what were the metrics that you were measuring, tracking, and trying to improve on a day-to-day basis?

Yeah, so curiously enough, for a company that's gathering so many metrics, we are not incredibly metrics-driven for the product. You know, it's interesting because we, we process what, like 4 or 5 trillion records a day for our customers of their own metrics. But when it comes to our product, we think that most of the metrics are lagging indicators. And they don't convey all the nuance of the value that our customers are going to find with our product. So we don't actually train ourselves to optimize to the metrics. The things we'll watch, you know, we'll watch as a company, we'll watch the volume of data and the volume of infrastructure that our customers are monitoring with us because it's a sign of the value we give to them because they deploy us into more places. We'll watch the engagement, of course, you know, but that's not original. And we'll watch the churn, which is why we, very early on, were focusing on that.

Cool. So let's fast forward a little bit. So now you're, as you said, around 700 and growing. You said, you told me, around 16 offices around the world. So what does it mean at that scale to be a customer-centric company?

[Speaker:JASON M. LEMKIN] So when you scale, some of the things that worked initially are not going to work anymore. So for example, we can't have the executive team meeting with all the customers all the time. My co-founder, myself, and our chief product officer were doing a lot of the product work initially. We were spending all that time with customers. You can't scale this way anymore. So one thing, the first thing we did is we actually created a very strong product management function. We didn't have product managers for the very— for the longest time. I think the first product manager was hired once we were over 100 people. But now we're investing heavily in product managers, and the role of the product manager is very specific. Product managers are not here to invent product. They're here to spend the most time possible with the customers, so outside of the office, to understand what their problem is and to understand what they're using, what they're not using, what they're paying for, what they're using or not using, and why. And basically understand, get the best understanding possible of the problem and the value that those problems represent for the customers. Then after that, what they do is they present our product, and they get feedback from customers on the product. So their role is not to invent the product, but to make sure it solves the right problem. And it has the right value. That's what they do for us.

So they're big PM teams, big product teams, and investing in them. And also, how do you relate to that phase where— to the early stage mode? Do you still have some locally, some actions and initiatives that are more scrappy, early stage?

Yeah, actually. So one thing that's a big challenge is When you start branching into new products, so either you start new products or you go into new markets which require some tweaks to your products, different kinds of companies, different geographies, things like that, all of a sudden you're back into startup mode. And it's easy to not realize that. It's easy to get used to, basically get used to winning, and then you expect everything's just going to work this way. And so the one thing you need to do there is you need to make sure that the teams that work on these new products behave exactly as you would have when you were a tiny company, which means soliciting as much feedback as quickly as possible, which means also going as wide as possible with the betas. In a way, there's quite a bit of tension there, you know, because when you have an existing product, you don't want to taint the opinion of the existing product by releasing a new product that is not going to be as polished, that you're going to distribute very widely. But still, if you want that product to work, you need to go very wide very quickly. The other thing you need to do is you need to create a culture where people seek the bad news. And it's actually a lot better to go to a customer and ask them, okay, so this new product, are you going to pay for it? You've tried it, etc. Is it good enough? Are you going to buy it? It's actually much better to hear from them No, I'm not going to buy, and this is why, than to, you know, kick the ball, kick the ball down the road, you know, and kick it down the road, hope that maybe in 3 months, 6 months, 9 months, they'll change their mind, or, you know, maybe I'll give you some feedback and they haven't told you anything yet. So it's actually a good thing to know what's not working. It gives you a thread to pull. It tells you where you need to go.

So it's a great transition to— because I want to talk about pricing. So it's great you talked to customers, they tell you their problems, you solve them, but at some point you need that kind of tough discussions, or, all right, it's going to cost XX dollars, or, or whatever. So how do you, do you keep your customer as a, as an ally in that discussion, and how do you start the discussion and, and have it still successful?

Yeah, so it's counterintuitive because you'd say that's the part where you're going to be disconnected from your customer because your customers want to spend as little as possible, or you want them to to pay you as much as possible, so obviously there's going to be some disagreement there. I think the first thing is you have to agree on which kind of company you are and which kind of product you are. The way I see it, there's two kinds of products, two kinds of companies. There's the low-end disruptors, where the major feature is that it's cheaper, and if you do that, basically the dynamics with your customers are going to be they'll push you to be cheaper and cheaper, and to figure out what you can take out of your product so that it can be as cheap as possible. Or you can be the, the high-value product where you're going to be charging for your product, you're going to try to charge more for your product, and you're going to have to deliver more value for that. So the cycle with your customer is to deliver more and more. So you have to agree with your customer that they're looking for high value, high impact, and not as cheap as possible, because otherwise you're never going to meet. Once you've agreed on that, you are going to be aligned in the mid and long term, right? Because your customers, they want you to be successful. They want your company to be in business 2 years from now. They want you to ship new features. So they really want you to be successful. So once you've done that, that's good. After that, there's still going to be some friction, but that friction is also how you're going to learn about the value of your product. And about what you need to do and where you need to go next. You're still going to hear, you know, from customers, "Yes, so for that particular part of the product, I totally see the value. We want it. It's fine. That other part, we don't see the value yet, so we're not going to buy it. It's a large amount of money." You know, asking for money and putting a dollar amount on the product really focuses the mind for the customers, and it helps you get really, really good feedback on where you need to go. So I would say in the long run, it's a very healthy relationship to have.

Super interesting. It's not just being customer-centric, it's not all about building the product, it also reflects on like the sales team, the way you sell, because the way you frame it, it's all about seeing your customer as a partner. Let's do this together. You want me to succeed and I want you to succeed, and the commitment on your side is to pay. And I think that's super interesting, super valuable lesson here.

Yes, and really focusing on value. You have to understand where the value is. And again, that's the job of the product managers. That's why we spend all this time with customers.

So you guys are quite big now compared to us. We're 12 now and growing, thinking about tripling the company size within the year. And in your way of thinking about culture, like how do you scale your culture? And even from like maybe 12 to 30, in our case, it seems like a huge challenge. And from 2 to 700, what are the tips and tricks on how to scale the culture? And at your level, as a CEO level, how do you make sure that everything is kind of going right?

Right, so the one thing we haven't done so far is we actually haven't written down like, these are the 7 values, or, you know, the 14 things you do. And we've— we haven't done that so far. It's something we'll do in the future because I think as we scale, we will need that so we can better train. But, you know, culture at the end of the day, it's really about— so who you hire, who you fire, who you promote, that's what shows the culture. And for us, the culture we want to have is a culture where we're completely customer-centric. So for example, we train people to— we train the managers to care about the details. So one thing we do, and I think I actually do still as a CEO, is I see every single customer complaint and support email that comes to us. And I don't read most of them, I delete most of them right away, I just scan them very quickly. But what this does is it gives me a sense of— it helps me pattern match, basically. It gives me a sense of what's actually happening. Who are people actually reacting to the product? What are they saying? I never actually act on them directly. I never go back to the customer. I never reply, you know. I don't try to solve the problem. But if I want to actually effect change, what I'll do is I'll go back through the management and through the chain of managers and and make sure that people just get some feedback and decide whether they need to change something. So we encourage people at all levels of the organization to do that, basically care about the details so they can pattern match. The other thing that is very important if you want to maintain a customer-focused culture is that you have to be super careful about the way you talk about the customers inside the company. It's tempting, you know, Sometimes in sales, it can be tempting to talk to customers as, you know, you can sound manipulative as you talk about them because you try to manage them through a sales process and things like that. Sometimes on the engineering side or the product side, you can think that customers are making the wrong choices, or, you know, why are they doing that? You know, why are they doing this stupid thing with our product? The way we see it is If they're doing a stupid, stupid thing with our product, it's our fault. Like, we let them do that, we made them think they should be doing that, or we didn't explain it right enough, you know. So you always have to assume that the customer is right, but also, even if you think they're wrong, the fact that they're thinking something wrong in and of itself is a fact. It exists, and you have to deal with it, and you have to value it. So you can't let yourself dismiss what you hear from the customers.

One of my Maybe one of the last questions here. So along your history, you've acquired 2 companies. And when you have such a strong culture of being customer-centric, how do you make this work? Because you have new people coming in. They have their own culture, obviously. How do you select those companies? And how do you make all of this acquisition work?

So we've made 2 acquisitions, and both were heavily tilted towards the tech platform, the product, and the team. So we acquired companies to build upon. We didn't acquire revenue streams to add to our sales engine. And in both cases, what we optimize for is what's going to happen after we close the deal. Are people going to stick around? How long are they going to stick around? Can they are we going to be able to build on top of that team and turn that team of 20 we just acquired into a department of the company that's going to have 200 and 500 people? So it's all optimized on the fit, what happens after the acquisition, and if the companies are going to share the same values we do.

Cool. Last question, short answer. I'm guessing there's many founders in the audience here. What is the one advice for them and for me as well? You know, like, if— because I think most of us want to be customer-centric. So how do we make this work? What's the one piece of advice that we should take out of this?

So my piece of advice is really look for the bad news. You run towards the bad news. You know, when you— whether it's early, when you just shipped a product, whether it's late, when you are renewing a big customer, you have to The wrong thing to do is, you know, there's some issue in some account, and then you show up in front of the customer, and you know, you, you hope they're not going to be— they're not going to bring it up. You know, hey, maybe with a bit of luck, you know, we can, we can get away with it. Actually, no, the first thing you do is you talk about it, you bring it up, and then you, you actually hear directly from the customer what they have to say about it. It actually goes a long way towards building the partnership, and it also helps you learn from this conversation with your customers.

Cool. Thanks. Time to wrap it up here. So everything is— I mean, one thing that I take out as well is it's a lot about the culture. It's a lot about also coming from the top. And so it brings me back to what we're doing also at Playdoh is really helping your engineering team ingrain the culture in their day-to-day actions. So if you want to learn more about what we're doing, just come to our booth. Thanks a lot, Olivier. I hope you guys learned some stuff here. I did, so that's a win.

And we're customers, so you should check out their booth. Yeah.

Thank you very much.