Data beats opinions — most of the time

Everything we build in software can, in principle, be measured. Clicks. Events. Funnels. How far people get before they drop out. Which features they touch and which ones they walk straight past on the way to the thing they came for. You do not need anything exotic to see it. Event tracking and a dashboard in something like Firebase, Google Analytics, or Mixpanel already tells you more than most teams act on.

And when a question is really open, you do not have to argue about it. An A/B test turns the argument into an experiment: ship both, split the traffic, watch, decide. The companies that are best at this treat it as a habit, not an event. Booking.com became known for running thousands of experiments in parallel, on the working assumption that most ideas, including their own, are wrong until the data says otherwise. That mindset is worth borrowing even at a much smaller scale.

The reason this matters is uncomfortable. Just because a stakeholder wants something does not mean users need it. Those two get confused constantly, usually with the best intentions. Someone senior has a strong hunch, the hunch becomes a requirement, the requirement becomes a roadmap item, and nobody stops to check whether real people behave the way the hunch assumed. The higher up the hunch comes from, the less likely anyone is to test it. Which is exactly backwards.

So I try to push as many product decisions as possible onto real usage instead of the loudest voice in the room. Feature flags and staged rollouts make that cheap: expose something to a slice of users, measure adoption, and only then commit to it fully. Build a little, measure honestly, learn, repeat. It is a slower kind of confidence than a strong opinion, but it is the kind that survives contact with real people.

Data does not only help you decide what to build. It helps you decide what to kill. That is the part teams avoid, because removing something feels like admitting a mistake. But a feature nobody uses is not neutral. It is weight. It has to be maintained, tested, worked around in every future change, explained to every new hire. Usage numbers give you permission to remove things, and removing things is one of the most underrated ways to reduce technical debt and keep a product honest. A North Star metric helps here too: if a feature doesn't move the number that really matters, its presence needs a reason beyond “we already built it.”

I want to be careful not to overclaim, because the data-driven story has a failure mode of its own, and it is a serious one. Numbers tell you what happened, not always why. They can only measure what already exists, so they nudge you toward local improvements (a better button, a shorter form) and away from the bigger bets that have no data point yet because nobody has built them. A team that only optimizes what it can already measure will polish itself, very efficiently, into a corner. Some of the products that mattered most would have failed an A/B test in their first week.

So gut feeling still matters. Experience still matters. Intuition still matters. Often it is what tells you which experiment is even worth running, which number is lying, which anomaly is a bug and which is a signal. I am not arguing for switching off judgment. I am arguing for not letting judgment win the arguments it should lose. Over a long enough horizon, the data usually turns out to be right, and the opinions that fought it turn out to be expensive.

That is roughly how I hold it: opinions start discussions, and data usually ends them. But there is a limit I keep bumping into. Even the best data only helps so far if you don't understand how the software underneath it is built: how the number is produced, what it costs to change, what is really easy and what only looks easy from the outside. You cannot ask good questions about a system you cannot picture. Which is where the next thing I believe comes from.