Why every PM needs to think like a data analyst

There’s a version of product management that treats data as something you check after you ship — a way to confirm what you already believed. That version is losing ground fast.

The PMs I find most interesting are the ones who treat data the way an engineer treats a spec: as the thing that defines what you’re actually building, not a post-hoc justification for what you already decided.

The question behind the question

When a stakeholder says “can we add a feature that does X,” there’s usually a real question underneath it. Something isn’t working. A metric is moving the wrong way. A user complaint keeps showing up in support tickets.

The instinct is to answer the surface question — sure, here’s the spec for feature X. The data analyst instinct is to ask: what problem does X solve, and how will we know if it worked?

That second question sounds obvious. It isn’t. Most feature requests never get asked it.

What data analysis taught me about product

Working as a data analyst before thinking seriously about product changed how I see both disciplines.

Data without a question is noise. You can query anything. A dashboard that shows everything is as useful as a dashboard that shows nothing. The hard work is deciding what to measure and why — which is a product decision before it’s a data decision.

Correlation is everywhere; causality is rare. It’s easy to find metrics that move together. It’s much harder to run the experiment that tells you whether one caused the other. Good PMs know this distinction. They design features as experiments, not pronouncements.

Aggregates hide the real users. A metric that looks healthy at the average can be terrible for 20% of users who matter most. I learned to look at distributions, not just means. The outliers are usually the most interesting part.

The underrated edge

Here’s what I think gets undervalued: a PM who can write SQL and build their own dashboards doesn’t just save time. They change the questions they’re able to ask.

When you depend on a data team to run every query, you ask fewer questions. You batch them. You wait. By the time you have answers, the context has shifted.

When you can query the data yourself, you can follow a thread in real time. One answer leads to the next question leads to the next query. That’s how you find the insight that wasn’t in the brief.

What I’m still learning

I’m not arguing that PMs should replace data teams. The deeper you go into causal inference, experimental design, and statistical modeling, the more specialist knowledge matters.

What I am arguing is that the gap between “PM who can read a chart” and “PM who understands what the chart is actually measuring” is significant — and most PMs sit on the wrong side of it.

Closing that gap is one of the most direct ways to get better at the job.