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 it 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.
Lesson 4: Optimize for end usersâ usage, not RFP checklists
2014
The company would start 2014 off with a $15M series B. With the ability to double down on growth, the first major feature the company would ship in the year is broadening to support multi-cloud environments.
As the above picture alludes to, at this time Datadog began, there are OK statuses for all three of AWS, Amazon, and Google Cloud. This product would go into general release in 2014. Critically, it not only made Datadog compatible with any cloud, but also hybrid and on-premises (on-prem):
This helped Datadog achieve what is now encapsulated in its product principle of âubiquity.â By building agents and connectors for every part of a clientâs stack, Datadog was able to get data on the entire picture for clients. Nowadays, it is not uncommon for Datadog clients to have more seats than engineers at the company, because it is such a ubiquitous part of the businessâ operations.
Fundamentally, Datadog invested in the value proposition of integrating with customerâs complex environments. This would prove to be a critical advantage. Teams with Datadog feel unbound. They can harness the full spectrum of SaaS and open source tools.
The other big investment Datadog would make in 2014 was into scalability and performance. As VP of Product Ilan Rabinovitch explains it:
The most important part of our tech stack is stability and performance for our customers.
By investing early in its life on its first productâs stability and performance, Datadog would establish a reputation as a partner enterprise clients could trust at scale. This is not an uncommon reason for clients to claim to love the company.
2015
Indeed, by 2015, Datadog had attracted numerous high-profile customers such as Netflix, Spotify and EA. This would help the company start the year off with its now regular yearly financing, a $31M series C.
With all the firepower came a litany of options. The question was: where to focus? It turns out, again, a major trend makes for great criteria to define a niche.
In Datadogâs case, the team decided to focus on companies moving from legacy IT to public and private cloud. This gave the product and sales teams a clear customer. It createed a bit of a funnel within the market as well. Not everyone transitions at the same time. But when they do go to that transition, they signal it by going to certain conferences. Datadog was there to chat then. Instead of focusing on an industry, Datadog focused on a moment in time for companies.
Importantly, the company stayed focused on building and optimizing for their end user. They did not, ad nauseum, add a list of 77 features to their product to succeed on an Request For Proposal (RFP). Olivier describes the problem with this approach:
You end up with products that are super super complicated and they get sold, and then one person uses them and everyone else is scared.
Instead, Datadog defines success for product as broad adoption at customers. The core problem the product team solves for is bridging the gap between teams. The product exists to get development and ops on the same page. To avoid any decrease in usage, they avoided adding functionality for the sake of succeeding in deals with competitive products. In some of those processes, Datadog would simply opt out. It preferred to stay focused on customers migrating off legacy open source solutions.
The strategy would work. The year would be one of superlatives. The company landed in the Forbes Cloud 100. It surpassed 1,000 customers. It also began throwing its weight around in the market, with the acquisition of Mortar Data. By the end of 2015, the Datadog playbook was singing. Datadog had established a bottoms-up go to market funnel for a focused user persona.
Lesson 5: Build a Platform to Unify Disparate Services
If youâre going through hypergrowth, you will have a different company every 6-12 months.
That is one of the core learnings of Elad Gilâs High Growth Handbook.
This was especially true at the end of 2015 for Datadog. As Chief Product Officer Amit Agarwall tells it, the company was also at a strategic crossroads. While sales had officially gone âgangbusters,â the company had just one product in the market: metrics for infrastructure monitoring. Did it want to invest in product development? One tool the executive team used was this simple growth matrix:
One growth strategy the team could pursue is market penetration, in the bottom left. Using the existing product, targeting existing markets, they could do more marketing and hire more salespeople. Datadog was already doing this.
Another was market development, expanding the existing product to new markets. The team planned to do this as well. As Amit says, âthese [first two] are not real questions or strategic decisions. These are things you have to do.â
Yet a third strategy is entering new products with new markets. Think Alphabetâs âOther betsâ segment. Established companies can try and enter new markets. Companies like Amazon and Alexa sometimes succeed. But as a startup this is âalmost like a non option.â As a small company, the risk of diversification is too high.
That left the team with product development – the introduction of new products in existing markets. Seems simple to go from there, right?
Not quite. It is worth appreciating the myriad reasons the team had not to pursue product development. The executive team was worried about waning quality in the core product, making it difficult for sales to sell multiple products, diluting the brand, and stretching a small company too thin.
But, the key insight for Datadog was that they could build a platform atop the existing agents and connectors, deployed across customerâs entire tech stacks. The team was also getting signals from customers that they had to use three disparate products: an infrastructure monitoring product, an application performance monitoring (APM) product, and a logs product.
Putting the end user first, the team dived into this. They found that users lost a lot of information context switching between three applications. A typical stack at a client might look like Datadog for infrastructure monitoring, Dynatrace for application performance monitoring, and Splunk for logs monitoring. So, despite being a small 150 person company, Datadog made the bold decision to step into product development.
The big mistake SaaS companies make going from a single to a multi product company is losing leadership in the single product. To avoid this fate, they completely separated the team for application performance monitoring.
2016
As had become an annual tradition, Datadog started 2016 out with a big fundraise, this time a $95M series D. It was one of the largest funding rounds for a NYC company that year.
The additional funding helped the team continue to expand out the APM team and launch the product in beta. Engineers on the team generally actually ramped up quickly, because of the platform nature of the infrastructure monitoringâs agents.
The team also began monitoring serverless environments, another major trend the team was early to.
Finally, armed with a tenth of a billion in cash, the company was ready to make the migration into a full court press on the enterprise segment of the market. Datadog established an enterprise sales team.
2017
By 2017 Datadog had more than 4,000 paying customers across the world. Annual recurring revenues were north of $100 million, and more than 600 employees were spread across its worldwide offices. Datadog even made Wealthfrontâs Career-Launching Companies List. The series D was so big, and the business cash flow positive, that the company did not raise.
Instead, Datadog put cash to use. To complete the three use cases, the team made the opportunity cost tradeoff. Could it afford to set up another team for scratch for logs? Instead, the the company found a strong team who had already put a product in market. Datadog acquired the Paris-based Logmatic.io.
2018
Logmatic.io operated a platform-agnostic service for querying and visualizing logs to monitor and troubleshoot online services. After shutting down logmatic, Datadog had the team build a log product atop the Datadog platform. This launched in 2018, completing the three use cases the company had discovered a few years earlier.
The team had grown the core platform, built a new team for APM, and acquired a startup for logs:
After all this work, critically, Datadog did not bundle the products. As Amit Agarwal explains, bundling can âdiscount the value of the individual products.â Instead, the company established clear, usage-based pricing of each APM and logs.
The strategy worked. Datadogâs dollar-based net retention rate (DBNRR) was 141% in 2017, 151% in 2019, and 146% in 2019 – industry leading figures.
Moreover, achieving these three use cases was considered a âfirst” in the industry. This would set the tone for Datadogâs IPO.
2019
The next year would be spent gearing up for IPO, and we would finally get a glimpse under the hood of Datadog in August. As expected, the first line of S-1 emphasized the three products united:
Our SaaS platform integrates and automates infrastructure monitoring, application performance monitoring and log management to provide unified, real-time observability of our customersâ entire technology stack
The company took its platform strategy to the public markets, and on September 20, 2019 Datadog became a public company.
Lesson 6: Optimize Landing and Expanding
The âland and expandâ strategy may now be canonical in SaaS circles, but Datadog continued to exemplify optimization of the strategy after IPO. Analysts did not expect Datadog to continue quarterly revenue growth the way it did:
How did Datadog so dramatically outperform revenue growth expectations eight quarters after IPO?
For one, Datadog continued down the path of product development. Two of the additional customer use cases were in the areas of simulating user behavior and understanding a real userâs specific experience. The team released Synthetics and Real User Monitoring (RUM) in the User Experience (UX) area in 2019:
This added one more product to upsell to customers who are happy with the initial real-time unified data platform. Synthetics is a particularly interesting category to analyze. The category, on its own, is not huge. The product is relatively commoditized. As a result, most providers tend to have fairly high churn. But when you have a broader platform, like Datadog, the broader platform becomes the differentiation. And categories that are not necessarily attractive on their own become land and expand opportunities.
2020
In addition to use cases, the Datadog team has enhanced the platform services provided on top of its data integration platform:
The average in-house team might be able to bring some of the data that Datadog brings together with in-house tools, but these platform services serve as another layer of differentiation. The company continues to layer on ML insights and automation tools that Datadog is uniquely able to focus on, given its focus on monitoring. To this end, the company acquired Madumbo, an AI-based application testing platform.
Datadog also launched the Datadog marketplace. This was a critical launch because it nearly completed the Datadog as a platform strategy. Now developers anywhere, not just internal application developers at Datadog, could leverage the Datadog platform to build applications:
By giving developers access to the collection, storage, and features of Datadog, the company further enables its end usersâ usage. Becoming this type of marketplace is the natural habitat of high marketplace SaaS companies like Salesforce and Atlassian.
These new product developments helped drive both NRR (>140%) and customer adds (>50%), the two key components of growth in a land and expand strategy. Today, 75% of new logos land with two or more products.
Datadog continues to emphasize frictionless adoption and time to value with these new products. The S-1 summarizes the strategy best:
our newer products are often adopted first by first selecting customers at small scale before our land-and-expand model enables greater adoption over time. And frictionless adoption from our single integrated platform is a key value proposition for our customers
The success of Datadogâs land and expand optimization led it to end 2020 with over 2,000 employees. Remember when we said Datadog had 100 customers in 2013? Or 1000 customers in 2015? It ended 2020 with over 14,000 customers. đ¤Ż
2021
Lesson 7: Consistently Increase Product Velocity
Today, Datadogâs end-to-end observability platform continues to broaden and deepen. Importantly, its product velocity has continued to increase – as it had up until this point in the companyâs life.
Where Datadog had 350+ integrations at IPO, it has 450+ now. Where the inaugural Datadog conference, Dash 2018, announced 3 main features, Dash 2019 announced 19 key features, Dash 2020 had Olivier quoting over 200 features, and Dash 2021 Olivier quoted over 300 features. The product team literally measures its velocity by features shipped and focuses on increasing it.
This year has several major new products. These are not small features. Compliance monitoring helps continuously monitor production environments for misconfigurations. Error tracking helps aggregate, triage, and prioritize frontend application errors. Continuous profiler provides low-overhead application code profiling. These are important product launches, executed at ever greater speed.
From the beginning, Datadogâs mission has been to bridge gaps between teams. This guiding mission, plus the productâs foundational nature at the data platform layer, has enabled Datadog to pick up a series of smaller categories that are not necessarily interesting on their own. The company will continue to unify teams by picking use cases like these up.
The result of this product velocity has been vast outperformance. At IPO, analysts projected Datadog to do $610M of revenue in 2021. It will end up at $1.3B.
Further, when stacked up against the other fastest growing SaaS companies, Datadog stands out. At last twelve months revenue growth of 56%, it is ahead of all of the following flashy SaaS names:
- Zscaler: 55%
- Docusign: 54%
- Braze: 52%
- Cloudflare: 52%
- Bill.com: 51%
- Unity: 45%
- Okta: 44%
Amazingly, Datadog is now prioritizing product development over sales and marketing. Whereas in many parts of its history, Datadog spent more on sales and marketing than product development.
Now, that has flipped. As I outlined in my piece on product rockets, that makes it really stand out in the landscape:
Product Lessons from the leading SaaS PLG Company
In the story of Datadog, we have encountered the core operating principles of product-led growth, executed flawlessly. This is the operating playbook for future founders to follow.
