Graham McNicoll

We had a dashboard for every metric at my last company. What we did not have was a way to answer the question that followed every spike: what actually caused this. There is a certain catharsis that comes from looking at a graph. The number went up. It satiates that feeling of being data-driven. But the insight stops at the surface. You cannot slice it the way you need to. You cannot figure out which users drove the change or whether your last release had anything to do with it. That is where vibe-driven decisions live. The PM squints at the graph and calls it a win. The feature ships. Nobody knows what moved the number. Sales cycles, other features shipping, time of day, back-to-school traffic. Any of those could explain a 5% bump just as plausibly as the thing you launched. We had no way to settle the question without a controlled experiment. Once we started running them, the conversation changed. The vague retrospective — did things improve after the launch — gave way to something precise: did this feature move retention, for which users, and by how much? That is what data-driven actually means. The experiment is where the answer lives. It's the best way to tell causal inference. Industry-wide, only 20 to 30% of features move the metrics they were built to move. The teams that compound learning fastest are the ones who read a graph and ask what caused it. What question is your dashboard raising right now that you have not been able to answer?