Two teams have spent three weeks arguing about whether signups are falling. Growth says down 12%. Product says flat. They escalate, and the escalation arrives on your desk as a request for “an independent analysis of signup trends”. An afternoon with the tables shows the whole story: growth counts a signup when the email address is submitted, product counts it when the address is confirmed, and confirmation rates dropped after a change to the mail provider. Both numbers were always correct.
No analysis settles that argument, because the argument is not about a number. It is about a word that two teams define differently and nobody owns. A third number, even a very good one, becomes a third position in the fight.
The tells
The answer would not change the decision. The test is blunt: walk through each possible result and ask what happens next. If the plan is the same whether the number comes back high, low or in the middle, there is no decision downstream and the request is curiosity or habit. Both are fine, and neither justifies four weeks.
The decision is already made and wants cover. The signs are recognisable — the ask names its conclusion (“show that the new pricing worked”), the deadline lands before any honest analysis could finish, and questions about method get waved off. This is not always illegitimate. A sound decision often needs explaining to a board. But it is a communication job, and it should be scoped as one, out loud. What you cannot do is lend evidence to a conclusion you have not checked; when that happens once, every future number you produce carries an asterisk.
The real problem is a broken process. The forecast is blamed for stock being wrong, but stock is wrong because returns get recorded from memory at the end of a shift. No model repairs an input that was written down incorrectly. The tell is that everyone agrees the numbers are accurate and everyone still distrusts them — that gap is almost always operational, and it lives upstream of anything you can compute.
Nobody owns the definition. Two teams, two meanings of “active customer”, and every analysis quietly picks a side. The fix is not analytical. Someone with authority has to choose a definition, write it down, and have both teams use it. You can supply the options and the consequences of each. You cannot supply the authority.
The disagreement is about priorities, not facts. Support wants faster response times, engineering wants to ship a migration, and the request is for “data on the impact of response time”. Both sides will accept whatever number arrives and keep their original position, because the dispute is about what the company should value this quarter. That is a management call wearing the costume of a factual question.
Building anyway is expensive
Time is the smallest part of the cost. A dashboard that answers a question nobody was deciding on still needs a data source that changes, a definition that drifts, and a person to fix it at 9am when it breaks. Every one of these is a permanent liability attached to a temporary need, and they accumulate faster than they are ever retired.
The larger cost is trust, in both directions. Deliver the independent signup analysis and the two teams learn that escalating to data produces an artefact rather than a resolution — so next time they escalate again, and the underlying definition stays unowned for another year. Meanwhile your own credibility thins: the more work you produce that changes nothing, the more your work looks like something a company does rather than something it needs. Nobody says this out loud. It shows up later, as a budget conversation.
There is also a queue. Time spent on a request that could not have mattered is time not spent on the one that could. That trade is invisible to everyone except you, which is exactly why you are the person who has to make it.
Saying no so that it helps
“That’s not a data problem” is true and useless. Alone, it reads as territorial, and it leaves the person who asked exactly where they started.
A useful no has three parts. Name the actual problem in plain terms: the two teams are counting different events, and confirmation rates fell after the mail provider change. Name who owns it: someone needs to decide which event counts as a signup — that is a product call, not an analysis. Then offer the smallest thing that genuinely helps: the two definitions written down, each with its number, on one page, handed to the person who can choose. That page took an afternoon and ends a three-week argument. The independent analysis would have taken a fortnight and extended it.
Say it to the person who asked, before saying it to anyone above them, and say what you would build if the blocker clears. “Once there is one agreed definition, a weekly signup view is half a day’s work” keeps the door open and makes clear you are declining the framing, not the person.
Sometimes you will be overruled and told to build it anyway. Build it, and put the reservation in writing once, calmly, at the start. That record matters later, and it is not the same thing as sulking.
When a spreadsheet, a rule, or a conversation wins
Plenty of requests are real but do not need modelling. Forty rows updated once a month is a spreadsheet, and turning it into a pipeline adds fragility and subtracts nobody’s work. A rule written with a domain expert — flag every refund over €500 from an account younger than 30 days — often beats a classifier when volume is low, the logic is stable, and someone must be able to explain each individual decision to a customer or a regulator. That is the same instinct as starting with the simplest model that could possibly work, carried one step further back, to the point where the simplest thing is not a model at all.
And some questions are answered fastest by talking to people. Churn spiked in the Nordics last quarter; the segmentation analysis takes two weeks, and the three account managers who cover the region already know that a competitor undercut them on annual contracts in January. Call them first, then decide whether the analysis still has a job to do. It usually has a smaller and sharper one.
None of this shows up well in a performance review. There is no artefact, no link to paste, no dashboard with your name on it — just a project that did not happen and a decision that got made properly. The only way to make it visible is to write it down: the question that came in, why it was not a data problem, what the real problem was, and who took it. That note is the deliverable. It is also, over a year, the most valuable thing in the folder.