Datadog 🐕 The Archetypal Example for SaaS Product-Led Growth
7 lessons for product leaders from one of today’s foremost product rockets
What if I told you there was a public SaaS company growing at >60% per year, more than twice the growth rate of its peers, that spends more on product development than sales & marketing?
This same company has more than 7x’d its enterprise value since IPO.
Lined up against the other best SaaS companies on the metrics that matter, it consistently outperforms. Hint, it’s the line with deep green across the board:
As a result of this performance in public, in the right circles, the secret is out on Datadog. It is conversationally referenced as the archetype of product-led growth in SaaS. For these groups, its product strategy, including concepts like “unifying disparate services” & “land and expand” have become canonical.
But, where exactly can product leaders find this documented? What IS Datadog’s product strategy? What lessons can product leaders take from it? Enter this piece.
To celebrate Datadog’s 7x in enterprise value, let’s focus on 7 lessons for product leaders from one of today’s foremost product rockets 🚀.
Lesson 1: The Problems of Big Trends Make for Great Products
What do all those software engineers even do?
Indeed, how is that the modern technology company appears to have relatively similar user-facing footprints but ever-expanding engineering departments? The answer to the question is complex. Even seasoned product leaders struggle to simply explain the phenomenon.
One version is that many of the buzzwords that we all hear about development today - scale, cloud, microservices, containerized applications, and distributed application architectures - are converging.
Take scale for instance: as a product grows in usage, components shackled together when a single pizza could feed the engineering team fall apart. Similarly with the cloud, the delivery of software as a service has transformed the delivery model of software such that any deployed feature becomes something that has to be maintained.
Most importantly, today’s applications are no longer monoliths. In the old days, the entire app was written into a single build. At a small scale, this works. A few engineers can work on the same build. But at scale, this creates nightmares. As a result, today’s applications are built on distributed architectures. It’s APIs all the way down. Different teams manage different microservices. This helps contribute to the proliferation of engineers.
In addition, as a result of the cloud, applications started to be housed across multiple places: some services might be on premises, others in Microsoft Azure, and others still on Amazon’s AWS. We have entered the era of “multi hybrid cloud,” for large enterprise players like digitally transforming banks and retailers.
Not only is the application itself programmable, the entire application stack and underlying infrastructure itself is entirely programmable. With this great power, has come great sprawl. While this can be great for developers, it is a veritable nightmare for operations - the teams accountable for managing all of this to keep it up for the end user.
2009
And so it was for Olivier Pomel and Alexis Le-Quoc at SaaS company Wireless Generation in 2009. The company had a strict “No Jerks” policy when hiring. It was working. Nevertheless, the developer and operations teams at Wireless would constantly find themselves at odds.
Operations argued developers threw applications over the fence. “Finger pointing” was common. Developers argued operations could not do their job of maintaining uptime and reliability. They “hated” operations. As managers of development and operations, Olivier and Alexis were at the center of this corporate drama.
And herein lies the founding lesson of Datadog. A big problem caused as a result of major trends is a potentially great product. Alexis and Olivier started discussing what they were seeing. They considered creating a company. After all, they quite liked each other. When Olivier was investigating the university network back in Paris years prior, it was Alexis he found hacking it. The two had a history, enjoyed each other’s company, and a fundamentally great insight. But they were not quite ready.
2010
That moment would come in 2010, when Wireless Generation was acquired by News Corp. After several “after work conversations,” the two decided to leave and found their company. The two set out to build a product that would sit at the center of all these trends and help solve the fundamental problems of monitoring and observability:
As software and the cloud transformed companies, Datadog would help developer and ops teams monitor their entire stack.
Actually, neither Alexis nor Olivier has a dog. Rather, at Wireless Generation, production servers were known as “dogs,” and databases were naturally, “data dogs.” Data dog 17 was the particularly nasty Oracle database the team had to “sacrifice goats” to prevent from going down. In honor of exemplifying the problem they were trying to solve, Datadog 17 was the original code name for the project.
Over time, Datadog stuck. 17 didn’t.
Lesson 2: Obsess Over the Problems of the User to the Point it Generates Inbound
Part A - Solve the Right Problem
The starting point for Datadog was the problem Olivier and Alexis were having. There must be a better way for dev and ops teams to talk to each other. Despite having firsthand experience of the problem, Olivier and Alexis remained obsessed about the customer. Furthermore, despite both being engineers, they did not write a single line of code for six months. They just studied the customer problem.
Not that the pair would not have liked to have written some code. The problem was, they couldn’t get funded. VC’s didn’t understand why they were starting an infrastructure company in New York City. Those succeed in the Bay Area. NYC was only tech insofar as that tech was adtech, media, or commerce.
This put the pair into “oh my god, how are we going to survive?” mode, and pushed them to make sure they were solving a real, not a dream, problem. Now, they credit that time with creating an early DNA of customer obsession within the company. As Olivier says:
It forced us to spend all of our time with customers and people who were related to the problem. It grounded us in the customer problem.
One critical lesson for the pair was that the problem was not just Wireless Generation’s. The whole industry was going that way.
The DevOps trend had begun. Visionary tech teams were collapsing the dichotomy between developer and operations teams with modern observability tools. Validating this trend would help Datadog stay focused in the early years. For the longest time, Datadog would just focus on this single product, infrastructure monitoring metrics.
The early team also got a deep understanding of the problems with legacy solutions, so they could architect a better solution. These included:
Being designed to work with monolithic, static, on-prem environments
Not working with dynamic and ephemeral infrastructure
Not built to work for the broad set of technologies commonly used in modern SaaS
Not built for dev & ops team collaboration
Unable to handle cloud scale
As a result, Datadog was conceptualized to work at cloud scale across the latest ephemeral technologies including microservices, containers, and serverless computing.
2011
The customer work would translate into a seed round at the end of April. Then, the team was able to get to work on the original version of Datadog. The team stayed under 10, all engineers, for “the longest time.” One person was a product person, but still an engineer by trade. That person just loved spending time with customers.
The initial architecture the team put together at that time still accurately describes the high level today:
Datadog deployed agents and clients across the client’s stack. These send information to the Datadog API, which intakes and processes that in a data layer, streams, and makes it available in a web API for Datadog to show visualizations and dashboards upon. With those dashboards the team made a product decision that now manifests as a product principle today: “Simple but not simplistic.”
Furthermore, streaming technologies like Kafka are still the circulatory system of Datadog to this day. Nearly every piece of telemetry they ingest passes through Kafka, as it goes into the platform for processing or storage. The solution is highly scalable. Datadog solved the right problem from the get-go.
Part B - Generate Market Interest
In addition to helping build a robust initial architecture, another benefit of the team’s early customer obsession was generating inbound. They drummed up this interest through two activities in particular.
First, content marketing. Very early on, the Datadog team started writing content. Because the people that use infrastructure monitoring are technical, the blog leaned into that. It featured deep research on the latest topics in technical fields. For instance, the team has invested in pieces on the theory of monitoring, advancing the state of the art for the field.
Second, going to conferences. They went to the events with their laptops and did demos. They got in front of customers to get real feedback and see how they react when seeing different screens. For cheaper conferences like DevOpsDays, they sponsored a little booth. As Olivier tells it:
It’s a way to start generating a flywheel of getting customers inbound
Indeed, the content marketing and conferences created the first important leg of enabling product-led growth: sufficient inbound market demand.
2012
Lesson 3: Enable Self-Service with Short Time to Value
In 2012, the team was ready to launch. With customers banging at the door, Datadog was able to get off to a strong start, and raise a $6.2M series A from Index Ventures towards the end of the year.
But up until there were 30 people at the company, Datadog still did not hire a dedicated salesperson. Instead, the team spent further time finessing the initial versions of the product. Several lessons from this time would turn out to be important later.
A major lesson was that of false positives. When you ask customers about alerts, they will tell you to err on the side of false positives. They would rather prefer an alert that is wrong. But in reality, the opposite is true. Two false positives and your product is out. Customers think it does not work. This biased the Datadog alerts teams to have the product principle of always having a super high level of confidence about alerts.
Another important lesson was learning what customers can and cannot do on their own. Customers could, with open source solutions, put together basic monitoring. But one thing they simply could not do on their own was know what was going on outside their account, on a cloud provider. This helped Datadog develop features and pitch to potential customers the benefits of understanding outages across Datadog’s clients on a cloud provider. Solving these types of problems driven by new trends helped Datadog position itself as a modern provider compared to legacy solutions.
The result was that, by the end of the year, the team was getting quite a bit of inbound. They understand the product’s packaging, what they were selling, who they were selling to, plus now what the first six months of usage looked like.
2013
The enormous success of cloud infrastructure penetrating enterprises left Datadog with many willing customers. But the realities of not having a salesperson on the team meant they instead put in time and energy to finesse the self-service signup flow, and reduce time to value.
In his analysis of what makes a product-led growth company, John Ma identifies a few criteria:
✅ Self-Service or Free Trial
✅ End User Buyer
✅ Time to Value
✅ Clear Pricing
Datadog would establish all four of these in this time period, embracing a bottoms up go to market strategy. End users could trial the Datadog software directly from the website, without ever speaking to a sales person. Time to value was 15 minutes. After 14 days, they could easily purchase it:
Unlike many SaaS businesses, Datadog was built to not to require professional services. To this day, professional services revenue has been immaterial. This is a far cry from most SaaS companies. It is simply difficult to dial in the self-service and time to value. Remarkably, Datadog was able to, from nearly the beginning.
This makes Datadog truly the archetypal example for SaaS product-led growth. In just one example of this, its onboarding instructions are playful, with dashboards that are relatively “plug and play:”
The model worked. By the end of 2013, Datadog surpassed 100 paying customers.
There are three more lessons! Don’t miss the second half of the Datadog story. Smash that red button:
Hope you enjoyed this week’s deep dive into Datadog. We’ll end this week’s newsletter with three small thoughts.
GOING PUBLIC
Casper was founded in 2014. Since going public, its stock struggled so mightily it just went private.
What can we learn from its story?
It went public too early.
Here are private companies founded before it:
SpaceX, 2002
Reddit, 2005
Stripe, 2009
Ola, 2010
Figma, 2012
Nubank, 2013
Private markets have more stomach for volatility along the journey.
PRODUCT MANAGEMENT
Big plans, loosely held
Such an important trait in product management.
As new evidence comes in, be willing to shift on a dime
CRYPTOCURRENCY
Two months ago, Solana had a $47 billion market cap. The Ethereum competitor was behind other Ethereum competitor Cardano (whose token is ADA).
Since then, Solana has “flipped” - exceeded in market cap - both ADA and XRP.
Now it has a $65 billion market cap. That is more than Datadog.
It is amazing to see the cryptocurrency quickly become, for all intents and purposes, the “number three” crypto (Although technically BNB and Tether have higher market caps).
Excellent write up I've been long DataDog for quite some time.