Reviews & Takeaways

Rob Falcone did an unbelievable job with this book. It's short, straight to the point, and honestly one of the more practical sales reads I've come across. Whether you're just getting into sales or you've been doing it for a while, there's real value here, especially around how you actually connect with a customer during a demo.

The biggest takeaway for me was the idea of the 5-minute discovery phase. Instead of jumping straight into a product walkthrough, Falcone emphasizes slowing down just enough to understand the customer's pain points first. It sounds simple, but it completely changes how you position what you're showing. You stop demoing features and start aligning directly to what they care about.

Another concept that stood out was the YOU – THEY – YOU framework. Start with the customer, tie it to how others like them are solving the problem, then bring it back to how your solution fits. It keeps the conversation focused, relatable, and way less "salesy."

Overall, this book is a reminder that great demos aren't about showing everything. They're about showing the right things. If you're trying to get better at demos, discovery, or just making your conversations more impactful, this is 100% worth the read.

Solid intro to the platform. Covers infrastructure monitoring, the Agent, dashboards, APM, and log management at a good pace. It's clearly designed to get you up and running fast, not to go deep — but that's exactly what I needed to orient myself before the livestream tomorrow.

The hands-on labs are the best part. Actually spinning up the Agent and seeing metrics flow in makes the product click in a way the slides don't.

This course fills in a gap that the Core Skills path leaves open. You can learn about dashboards and monitors all day, but if you don't understand how data actually gets into Datadog in the first place, you're missing a critical piece of the picture.

The installation and configuration section was the most useful part. Seeing exactly how the Agent collects system metrics, checks running processes, and tails log files from the host gives you a much clearer mental model of the platform. When a customer asks how Datadog gets data out of their environment, this is the answer — and now I can explain it properly.

Earning this badge felt like a natural checkpoint after working through the individual courses over the past few days. On its own, each course teaches you one piece of the platform. But finishing the full Core Skills path is where it starts to feel like a complete picture rather than a collection of features.

The biggest thing I'm taking away is that this is just the foundation. There's a lot more depth to go into with APM, log management, and infrastructure monitoring at scale. But having this base makes it much easier to actually engage with that material rather than starting from zero. It's the right place to begin if you're serious about learning Datadog.

This one was more important than I expected. Tagging sounds straightforward until you realize how much of the platform depends on it. Filters, dashboards, monitors, cost allocation — it all traces back to whether your tags are structured and consistent.

The part that stood out most was how tags create the backbone for filtering across your entire environment. If you have five services running across three regions and your tags are inconsistent, you lose the ability to slice and compare data in any meaningful way. A solid tagging convention from day one makes the whole platform significantly more powerful.

Good course for understanding what's actually happening under the hood when you look at a Datadog graph. A lot of people interact with metrics without really knowing what type they're working with, and this makes that explicit.

The metric type section was the most useful part for me. A gauge just reports the current value, a count adds up events over time, and a rate normalizes that count per second. They look similar in a dashboard but behave very differently depending on the time window you're looking at. Understanding that helps you build graphs that actually tell the truth about what's going on in your system.

Solid course. Monitoring and alerting is where observability actually pays off, and Datadog makes it pretty intuitive once you understand the structure.

The threshold and notification setup is where I spent the most time. Setting a static threshold is easy, but the more interesting part is configuring anomaly detection or forecasting so you're not just alerting when something is already broken. You're alerting when something is trending in the wrong direction. That's the difference between a team that's always putting out fires and a team that actually has time to work proactively.

Dashboards are usually the first thing a customer sees in a demo, so this one felt directly relevant to what I'm trying to do as a future SE. A well-built dashboard tells a story. A poorly built one just throws data at you.

Template variables were the standout feature for me. Instead of building a separate dashboard for each service or region, you build one and use variables to filter dynamically. It sounds like a small thing but it's huge in practice. During a demo you can switch the context on the fly and show exactly what the customer's environment would look like without rebuilding anything. That's a much more compelling way to show value than a static screenshot.

Notebooks are one of those features that seem secondary until you see how they fit into a real incident workflow. Being able to combine live graphs, text, and annotations in one place makes post-mortems and investigations a lot cleaner than passing screenshots around in Slack.

What I found most useful was how notebooks let you capture the exact state of your data at a specific point in time. During an incident that's critical. You can go back, see what the metrics looked like when the alert fired, annotate what happened, and share that full picture with anyone who needs it. For a customer trying to justify a Datadog investment, that kind of structured documentation is a real selling point.

If the Core Skills path was about understanding Datadog's surface area, the Configuration path is about understanding what's underneath it. Agents, Docker, integrations, tagging, USM — these are the building blocks that actually get data into the platform and make everything else possible.

Finishing this path made me significantly more confident talking about how Datadog fits into a customer's existing environment. It's one thing to show someone a dashboard. It's another to be able to explain exactly how the data got there, how the Agent is deployed, and why the integration setup matters for the quality of what you're seeing. That's the kind of depth that builds trust in a technical conversation.

This course was a natural follow-up to Agent on a Host, and the contrast between the two approaches was the most useful part. On a host, you're configuring files and managing a service. In Docker, the Agent itself is a container, which changes how it accesses system resources, reads logs, and discovers what else is running.

The container discovery piece was the most interesting section. The Agent can automatically detect other running containers and start collecting metrics from them without manual configuration for each one. For a customer with a containerized environment, that's a huge deal — you're not asking their engineering team to instrument every single service. The platform figures it out. That's a compelling point to be able to make in a discovery conversation.

This course clicked for me from an SE perspective more than most. When a customer asks "what does Datadog actually connect to?", integrations are the answer — and there are over 700 of them. AWS, Kubernetes, PostgreSQL, Nginx, Slack, PagerDuty. The breadth of coverage is one of Datadog's strongest differentiators and understanding how integrations work under the hood makes that story much easier to tell.

The part that stood out most was how each integration ships with pre-built dashboards, monitors, and recommended metrics. You're not starting from scratch every time you onboard a new service. That out-of-the-box value is a real selling point for teams that want observability quickly without a months-long setup project. I'll definitely be working integrations into demos going forward.

This was probably my favorite course in the Configuration path. Universal Service Monitoring uses eBPF to automatically discover and monitor services based on network traffic, with no code changes and no manual instrumentation required. The Agent handles it at the infrastructure level. It just works.

From an SE standpoint, this is a powerful objection handler. One of the most common pushbacks on any observability tool is the implementation cost — "how long will it take our engineers to set this up?" USM changes that conversation significantly. You can go from zero to seeing all your services, their dependencies, and their health in minutes. That's the kind of time-to-value story that resonates in a technical eval, especially with a customer who's been burned by a complicated instrumentation project before.

Add your notes here.