You already have everything you need.
If you’re using Sentry, you have traces, structured logs, and now application metrics. Most teams use that stuff for debugging and stop there. But get this: that same data can answer most of the product questions you’ve been sending to a separate analytics tool, maintained by a separate team, with a separate data model and a separate bill. (Not all of them. We’ll get honest about the gaps later.)
This isn’t a post about whether product analytics tools should exist. It’s about the fact that developers have been sitting on top of a goldmine of product insight and outsourcing the questions to someone else. You don’t have to.
There’s a reason this matters more now than it did five years ago. The line between “product manager” and “software engineer” is blurring. Engineers are increasingly expected to think about adoption, retention, and user behavior, not just uptime and latency. If you’re a product engineer (and increasingly, that’s just “engineer”), the tools you already use for debugging are the same tools you should be using to answer product questions. You just haven’t been querying them that way.
Every product question maps to telemetry you already have
