"Data-driven" is one of those phrases that sounds rigorous until you watch it in practice. I've been in meetings where a PM presented twelve slides of analytics and then said "so we need more data before we can decide." I've done it myself. You pull the numbers, the numbers are ambiguous, and instead of making a call you ask for another analysis. Another week passes. The team waits. The metric you're watching doesn't actually tell you what you need to know, but it's the metric you have, so you keep looking at it.
The data-driven PM who can't make a decision without more data isn't being rigorous. They're hiding.
The data that doesn't exist
Here's the thing about building new features: by definition, you don't have data on how users will respond to something they've never seen. You can proxy it. You can look at analogous behavior in your existing product. You can run a small experiment. But at some point you're making a judgment call with incomplete information, and dressing that judgment call up as "data-driven" is just adding a layer of false confidence.
At Uzum, we were deciding whether to add a "save for later" feature to the cart. We had data on cart abandonment rates, we had data on return visit patterns, we had data on what categories users browsed without buying. None of it directly answered the question. We could have spent three weeks designing an A/B test. Instead we looked at the data we had, made a judgment call about what it implied, and shipped a version to 10% of users. We learned more in two weeks of real usage than we would have learned from any amount of pre-launch analysis.
The cost of delay is real. It doesn't show up in your analytics dashboard, but it's there. Three weeks of engineering time spent waiting for a test to reach statistical significance is three weeks you didn't spend on the next thing.
When metrics become a shield
The more insidious version of the metrics trap is using data to avoid accountability. If the data said to do X and X didn't work, it's the data's fault. If you made a judgment call and it didn't work, it's your fault. So you make sure there's always a metric pointing at your decision.
I've watched PMs build elaborate dashboards that always look good because they're measuring the wrong things. Retention is up - but retention is measured as "logged in at least once in 30 days," which is a low bar that doesn't tell you whether users are getting value. Order completion rate is up - but it's up because you removed a step that was catching fraud, and you'll find that out in three months when the chargeback rate spikes.
Every metric is a model of reality, not reality itself. Every dashboard is a set of choices about what to measure and what to ignore. When you treat the dashboard as ground truth, you're trusting someone else's choices about what matters - usually whoever set up the analytics two years ago, who had different priorities and different questions.
The metric that's been trending up for six months without a single bad week is suspicious. Either you're doing something remarkable or you're measuring the wrong thing. In my experience, it's usually the second one.
A metric trending up for six months without a single bad week is a red flag, not a success signal. Either you're doing something remarkable or you're measuring the wrong thing. Check what the metric is actually counting before celebrating.
What I actually do with data
I use data to pressure-test hypotheses, not to generate them. The hypothesis comes from understanding the user problem, from reading support tickets, from watching how the system actually behaves under load. Then I look at the data to see if it supports or contradicts what I think I know.
When the data contradicts my hypothesis, I take it seriously. When the data is ambiguous - which is most of the time - I make a call and document my reasoning explicitly. "We're building this because we believe checkout abandonment at the payment step is driven by payment method availability, not UX friction. We'll know we're wrong if abandonment stays flat after we add the new payment methods."
That last part is the part most PMs skip. If you can't articulate what would tell you you're wrong, you're not being data-driven. You're just collecting data until it says what you want it to say.
The decision you're actually making
There's a decision underneath every "we need more data" conversation, and it's usually not about the data. It's about who's accountable if the call is wrong. More data means more cover. It also means more delay, more cost, and sometimes a window that closes while you're still analyzing.
I've made calls that turned out to be wrong. I've also watched teams spend weeks on analysis for decisions that were obvious to anyone who'd spent an afternoon with the support queue. The analysis felt safer. It wasn't.
Data is a tool. A good one. But it doesn't think for you, and it doesn't make you right. It makes you feel more confident, which is sometimes the same thing and sometimes very much not. The skill is knowing which situation you're in.