Framing the Problem
The exec meeting ends with the sentence from the chapter opener — "let's use AI to reduce churn" — and everyone looks pleased, as if something has been decided. Back at her desk, Iris asks the data team what happens next, and gets an answer that surprises her: nothing. Nobody can type a single thing yet. "Reduce churn" is a wish, and a computer cannot be pointed at a wish.
Turning a wish into a task a model can actually attempt is called framing — pinning down what exactly gets predicted, for whom, predicted when, and what happens with the answer. It sounds like paperwork. It is the opposite: more ML projects die in framing — or die later because of framing — than anywhere else in the workflow. And as Iris is about to discover, this step belongs less to the data team than to people like her.
From Wish to Question
Watch what the data team does with the wish. "Reduce churn" becomes: for each active customer, predict the probability that they place no order in the next 30 days. Look at how much got decided in that one sentence. It names who gets a prediction (each active customer), what the prediction is (a probability, not a yes/no), what event it is about (no order), and over what window (the next 30 days). It is measurable, buildable, and checkable — thirty days after any prediction, reality grades it.
Here is the part that reframes the whole book so far: every problem you have met already got this treatment — you just never saw it happen. "Predict delivery time in minutes, for this order, at the moment it is placed." "Predict whether this review is fake, before it is published." Someone framed each of those, quietly, before a single example was collected. A useful comparison: a patient telling a doctor "make me healthier" gets no prescription, because nothing is treatable until it becomes "bring this blood pressure into this range by this date." Diagnosis before prescription — framing is that discipline, and from here on we will watch it done in the open.
Define the Label, Define Success
The framed sentence hides a decision that deserves its own section. What exactly counts as "churned"? No order in 30 days — or 60? Does a customer who paused their account count? What about someone who only ever orders during football season? Whatever the team picks becomes the label — the known answer attached to every training example — and the model will learn to predict exactly that, not the vague human idea of "a customer we lost". Pick 30 days and the model learns to flag slow-but-loyal monthly customers as churners; pick 180 and it warns you long after the win-back window has closed.
Notice that nothing in that paragraph is mathematics. What counts as a lost customer is a product decision, and so is the other conversation that happens now — the one Chapter 6 equipped you for. Which mistake hurts more: sending a win-back discount to someone who was never leaving, or missing someone who was? What score would make this worth shipping, against what baseline? Teams that settle the error costs and the bar before training judge the tournament calmly. Teams that skip it end up arguing about what "good" means after the numbers arrive — with the numbers themselves lobbying for whoever built them.
Predicted When, Acted How
A prediction is only worth the action it enables. The churn model's entire purpose is a list: these customers are at risk this week, in time for a win-back email or a targeted discount to change their mind. That word "in time" is load-bearing. A model that flags churners the day after their thirty quiet days are up is technically correct and completely useless — a perfect prediction with no possible action is trivia.
So framing always asks: what will we do differently because of this prediction? If the honest answer is "nothing, but the dashboard will look impressive", the project should die right there, at a cost of one meeting. This is the same discipline as Topic 05's checklist — where the question was whether ML is the right tool at all — extended one step: even when ML fits, the prediction must be attached to an action, or it is expense without effect.
The Framing Checklist
Iris writes the page down as five questions and pins them above her desk, because this — she now realizes — is her actual job on any ML project. The data team shapes what is technically possible; but what counts as churn, which errors are survivable, and what the company will do with the answer are product calls. On this step, the PM is a co-author, not a client placing an order.
Five questions, all in plain English, none requiring a line of code. The rest of the chapter rides the answers: the features, the tournament, the deployment rhythm, and the monitoring all trace back to this card. When a project goes sideways months from now, the postmortem will usually find the wound here — a label that meant the wrong thing, or a prediction nobody could act on.
- "Framing is a formality before the real, technical work." It is where projects are won or lost. A wrong label definition wastes every downstream hour — the model will faithfully learn to predict the wrong thing, beautifully.
- "The data team frames the problem." They shape it — what is learnable, from what data. But what counts as churn and what action follows are product calls; the PM is a co-author of the frame, not a client waiting for delivery.
- "A great model with no action attached is still progress." Prediction minus action is pure cost. "What will we do differently?" gates the whole project — and "the dashboard will look impressive" is not an action.
- This is where the book's promise — being able to judge an ML idea — becomes a repeatable procedure. Five questions, reusable on any "let's use AI" sentence you will ever hear, starting with the next one.
- The churn frame built here is the worked example the rest of the chapter rides: features, tuning, deployment, and monitoring all inherit these answers.
Knowledge Check
Why can't the data team start working from "use AI to reduce churn"?
- Plateful doesn't have enough data collected for a churn model
- It's a wish, not a task — nothing for a model to predict
- Churn is too complicated for machine learning to handle
- The team first needs to choose which AI product to buy
The team defines "churned" as "no order in 30 days" instead of 180. What does this choice actually change?
- Only how long training takes — the model comes out the same
- Only how the results are reported to the exec team
- Nothing — the model figures out the true meaning of churn from the data on its own, whatever the team wrote down
- What the model learns to detect — including who gets wrongly flagged or warned too late
A model predicts churners with excellent scores, but only identifies them after their 30 quiet days are already over. What is this?
- Trivia — the prediction arrives too late for any action
- A measurement error — scores that good must be miscalculated
- A success — high scores mean the project achieved its goal
- A data problem — collecting more examples will fix the timing
Which framing questions are product calls rather than data-team calls?
- All five — the data team just executes what the business writes down
- None — framing is a technical activity from start to finish
- What counts as the label, which errors hurt more, and the action
- Choosing which model type the team should train
You got correct