The request lands in a Slack thread: “Can we get a churn model?” It comes from the head of customer success, it is polite, it is specific, and it is already an answer rather than a question. Someone has decided what the solution looks like before anyone has said out loud what the problem is. Build it exactly as asked and there is a fair chance that six weeks later a model with a respectable AUC sits in a repository, unused, while the customer success team carries on doing precisely what it did before.
The request is a solution in disguise
“A churn model” has a shape baked into it: supervised, scoring accounts, probably a dashboard on the end. What it does not contain is who acts on the score, when they act, or what they do. That part was never written down, because the person asking had already skipped past it.
Stakeholders propose solutions because proposing a solution is what a helpful person does. They have thought about the problem, and they bring you something concrete instead of a vague worry. Treat the concrete thing as evidence, not as a specification. Behind “a churn model” there is someone watching revenue leak and wanting it to stop. Behind “a dashboard for regional performance” there is usually one recurring argument the dashboard is meant to settle. Behind “can you pull the numbers on X” there is often a slide due on Thursday.
Requests also get compressed as they travel. A director says something in a meeting, a manager turns it into a ticket, and by the time it reaches you the decision has been squeezed out and only the artefact remains. Working backwards from the request to the decision is decompression, not pedantry.
Two questions that find the decision
What will you do differently depending on the answer? This is the load-bearing question, and it should be asked plainly, without hedging. If the answer to a churn score is “customer success calls the top 200 accounts each month”, you now know almost everything that matters: the output is a ranking, not a probability; only accounts that can be phoned belong in the population; the model runs monthly; and precision in the top 200 is the only part of the metric anyone will ever feel. If the answer is “we’d know”, stop and keep asking. “We’d know” is not a decision, and a project built to serve it has no way of succeeding.
What happens if we do nothing? This one prices the work. Sometimes the answer is “we keep losing about forty accounts a quarter and nobody notices until renewal season”, which is a real cost and justifies real effort. Sometimes the honest answer is “nothing much” — and hearing that early saves everyone a month. It also surfaces urgency that the ticket hid: a request that looks like curiosity can turn out to be blocking a contract renewal in three weeks, which changes what “good enough” means.
A third question is worth keeping in your pocket: who has to agree before anything changes? Analysis that requires two departments to alter their process is a different project from analysis that one manager can act on alone, even when the maths is identical.
Making the question measurable
Once the decision is visible, the vague ask has to become something a query can return. Three things need pinning down, and each of them is a conversation, not a guess.
The population. “Customers” is not a population. “Accounts on a monthly plan that have been paying for at least 90 days and have a named contact” is. Every exclusion should trace back to the action: accounts nobody can call do not belong in a list of accounts to call.
The time window. “At risk of churning” has no clock in it. “Likely to cancel within the next 30 days” does. The window comes from the action too — if customer success works a monthly cycle, a model predicting churn over the next year tells them nothing about who to phone on Monday.
The outcome. Churn has to be defined in the data, and there is rarely one obvious definition. Is it the day the subscription ends, the day the customer clicks cancel, or 30 days of no activity? These give different labels, and therefore different models. Pick one, say why, and check the choice with the person who will act on the result, because they have an opinion about it even if they have never phrased it as a definition.
What you end up with looks less like a request and more like a sentence: “Of the monthly-plan accounts with at least 90 days of tenure and a named contact, which 200 are most likely to cancel in the next 30 days, scored on the first working day of each month?” That is answerable. It is also checkable — someone who knows the business can read it and tell you it is wrong before any code exists, which is the cheapest moment to be told.
Write it down and get it agreed
Send the question back in writing before starting. A short paragraph is enough: the decision, the person making it, the action that follows, the population, the outcome and its window, and what “good enough to act on” means in numbers. Add one line for what would make everyone abandon the project — if the top 200 accounts turn out to be 90% of the revenue anyway, the ranking is pointless and it is better to know that on day one.
Then wait for a reply that says yes. This is not bureaucracy; it is the last cheap moment in the project. Half the time the reply corrects something important — the wrong population, a definition finance uses differently, a constraint nobody mentioned. Some of the time the reply is a version of “now that you put it like that, we already know what we’d do”, and the work stops before it starts, which is a good outcome that nobody will congratulate you for.
The written question also protects the work later. Six weeks in, when someone asks why the model ignores annual contracts, the answer is a line in an agreed paragraph rather than a defensive memory of a meeting.
The perfect answer nobody needed
The failure this prevents is not a bad model. It is a good one, delivered on time, technically clean, cross-validated properly, aimed at a decision that was never going to be made. The model that ranks accounts by churn risk when customer success has no capacity to call anyone. The dashboard that answers a question two teams stopped arguing about a month ago. The forecast that arrives weekly for a budget set once a year.
Nothing in the modelling rescues those. They fail at the first step, and they fail quietly, so the blame lands on adoption or on stakeholders not being data-literate, rather than on the hour of conversation that was skipped.
That hour is the highest-return hour in the project. It costs nothing, needs no tooling, and is the only part of the work everyone involved can check.