Video summary

How Olivier Pomel Built Datadog By Refusing Every Shortcut

Main summary

Key takeaways

Business

Business & leadership lessons from Olivier Pomel (Datadog)

Founding story, strategy, and culture

  • YC rejection (2010) as culture fuel
    • Rejected because the platform’s success depended on getting the first product right (per the PG note mentioned).
    • Pomel frames early rejection as shaping a durable culture: obsessive focus on building something valuable and on creating a self-sustainable business even if fundraising failed.
  • Long-term cofounder partnership
    • Pomel and cofounder Alexi worked together for 10+ years before Datadog and maintain decision alignment by creating structures for continuous communication.
    • Practices include regular open-ended lunches and deliberate alignment before big decisions (e.g., sell vs. not sell).

Big-company decision-making (anti-“manage up”)

  • Core management process: force leaders to “look down” instead of “manage up”
    • The problem: as companies grow, people tell management good news and produce “beautiful stories” rather than reality.
    • Pomel’s systems:
      • Sample reality: read support requests, sales conversations, and all product briefs / release notes.
      • Direct follow-ups: sometimes reply with questions to make local management explain what’s really happening.
      • Result: jolts teams, improves understanding across the management chain, and helps leaders compare “ground truth” vs higher-level narratives.
  • Avoid bottlenecking
    • They design feedback loops so executive input is possible but not required.
    • Product work proceeds on a cadence (product release visibility points); feedback can occur any time, but teams don’t wait for constant approval.
    • Hard changes (like pricing/packaging) use pre-approvals; most other decisions are allowed to ship with later iteration.
  • Experimentation playbook for B2B
    • For many product changes, they test with subsets of customers, apply changes, then scale—relying on reversibility/low risk when possible.

Product innovation playbook (how Datadog chooses new offerings)

The “new product” inputs (3-part process)

  1. Customer feedback (majority)
    • Usually right, but often incremental (“fix this button,” “add an integration”).
  2. Strategic direction (top-down, less direct feedback)
    • Used when they see proof points that new areas matter, but with higher risk of being wrong.
    • Pomel explicitly dislikes the term “strategic,” but describes leadership-led expansion.
  3. Bottom-up internal innovation
    • Engineering/product teams solve problems they personally needed.
    • The organization then productizes internal tools and builds offerings when demand/pain validation exists.

Concrete examples of how expansion surfaced

  • From infrastructure monitoring → APM/tracing
    • Customers built simple tracing/APM versions themselves on top of Datadog, signaling strong demand.
  • Security automation
    • Customers used Datadog to instrument security posture and run security automation, guiding Datadog into security-related product areas.

Product portfolio snapshot (metrics)

  • ~25 publicly charged products
  • ~8,000 employees
  • Emphasis on simplified GTM operations: multiple products but not 25 separate sales processes/teams—one consistent commercial motion.

Go-to-market and investment context (high level)

  • Early fundraising difficulty
    • Pomel notes they lacked typical investor backgrounds:
      • Not from systems management vendors
      • Not from hyper-scale operators
    • Result: “every single other VC also passed” initially, including after mentioning YC.
  • Timing as luck
    • They argue they were positioned at the center of the cloud-era shift (Dev/Ops convergence), which took ~10 years to reach full adoption—making timing crucial.
    • They stress creating “surface area” by trying many things so luck can find you, while noting timing remains hard to predict.

Scaling, public company management, and volatility mindset

Market communication framework

  • They educate the company each quarter with a slide framing stock volatility:
    • Short term: “voting machine”
    • Long term: “weighing machine”
  • Emphasis: focus on building the right products, finding the right customers, and delivering the right service.

Public listing timeline

  • Went public in 2019
  • Lockup expired on/around COVID lockdown onset, causing immediate stock crash volatility.
  • Business impact described as a “seesaw” market response (crash, quick recovery, then further gyrations).

AI disruption: execution emphasis

Market reality vs execution approach

  • They lead observability technically, but claim only ~13% market share by some measures—framing a large remaining opportunity.
  • AI impact on business models:
    • Datadog is usage-based, so changes in pricing/model structure are less structurally disruptive than seat-based companies.

Product initiatives (named internally)

  • “DataDog for AI”: serving AI builders as customers
  • “AI for DataDog”: AI built into Datadog for automation

Reacceleration

  • They saw substantial reacceleration as AI increased operational complexity (GPUs, models) and increased the need for validation/operations, because AI agents produce code you may not fully understand.

Internal product direction: AI for development

  • Company-wide adoption of coding AI (referenced as “Code [Code]G uard”).
  • Pomel’s internal target/expectation:
    • Within two quarters, “mostly don’t write code anymore” (automation heavily assists dev work).
  • Constraints/unknowns remain:
    • What truly works long-term
    • How to structure teams (how many roles: PM/design/engineering/security; roles may converge)
    • Building toward a single unified platform to merge roles/coverage.

Hiring & org growth tactics

  • Don’t hire too early (classic product-market-fit rule)
    • “Don’t hire anyone pretty much before product market fit.”
  • Deliberate engineering growth cap
    • Even during fast business growth, engineering was not more than doubling every year.
    • Rationale: rapid scaling can create dysfunction:
      • ramp/hiring consumes productivity
      • higher risk of blow-ups and long re-stabilization cycles
    • Tradeoff acknowledged: possibly “leave some business on the table” to reduce execution risk.

Key quantified points & targets

  • Portfolio: ~25 chargeable publicly released products
  • Company size: ~8,000 employees
  • Observability market share (claimed): 13%
  • Public timeline: IPO in 2019; lockup expired around COVID lockdown start
  • AI dev goal: within two quarters, development shifts toward “mostly don’t write code”
  • Engineering scaling cap: <2x per year (engineering team growth rate)

Actionable recommendations implied by the discussion

  • Build a culture of ground truth
    • Sample support + sales conversations + product briefs; directly ask questions to surface reality.
  • Design leadership feedback so teams ship without waiting
    • Use pre-approval only for high-impact irreversible changes (e.g., pricing).
  • Create a 3-channel product discovery funnel
    • customer feedback (incremental),
    • deliberate exploration (strategic bets),
    • internal pain-to-productization (bottom-up).
  • Scale org carefully
    • Cap engineering growth to avoid ramp dysfunction; prefer stability over “10x in 18 months” scaling patterns.
  • Treat timing as critical luck
    • Expand experimentation surface area early to increase the probability of being positioned correctly when adoption accelerates.

Presenters / sources

  • Olivier Pomel — co-founder and CEO, Datadog
  • Interviewer (host) — unnamed in the subtitles

Original video