The last mile of data work
Most analyses do not fail on the maths. They fail on the last mile.
When was the last time an analysis you built actually changed someone's mind? Most organisations that call themselves data-informed cannot answer that question, and the reason has almost nothing to do with their data.
I have just finished teaching Data-Informed Organisations at Hyper Island. It is one of the final courses of a data analyst programme, and it arrives after students have spent two years learning to query, clean, test, visualise and govern data. This course is about the last mile, which almost nobody teaches: getting a completed analysis to change what a real organisation actually does.
Four weeks, real clients, eight teams, ending in a live recommendation delivered to a room that pushes back. Very few of the analyses that go wrong in that room go wrong on the maths. They fail because they are handed over as findings rather than as decisions, to a person who was never going to act on them, answering a question nobody was stuck on.
Data-driven treats the model or the metric as the decision-maker. Data-informed treats data as one strong input to a decision a person still has to own.
20
minutes of questions and interruption, after a 15-minute recommendation
The pushback is the assessment, not an accident
1
person who actually approves the decision, however many are in the room
DACI: one Approver, always
What the four weeks actually ask
The course is built around four questions, one per week. None of them is a question about analysis technique, and by the end it is obvious why.
Who is in the room, and what are they actually deciding?
Before any data work, the translation job: from the thing a client asked for to the decision they are stuck on, and the one person who owns it.
What does success look like, and how will we measure it?
Which numbers deserve attention and which are noise dressed up as insight. Judgement, not mechanics, since the calculations were never the hard part.
How do we structure it, and can we defend it in the room?
Answer first, then the reasoning. And then delivery itself, which is a separate skill from having been right.
01 — A request names a deliverable, never a difference
Ask a client what they want and you get a request. A dashboard. Better visibility. A weekly report. Every one of those names an artefact, and none of them names an outcome.
This matters because you can deliver a request perfectly and change nothing. The dashboard ships, it is accurate, it is well designed, and six months later nobody opens it. Not because the work was poor, but because nobody ever committed to an outcome. They committed to a deliverable, and a deliverable is something you can complete without anything being different afterwards.
The translation runs from a topic to a decision. A topic is "delivery times" or "customer churn". A decision names who is choosing, between what options, by when, and what is at stake if they get it wrong. Clients rarely arrive holding the second one. Getting there is the work, and it happens before anyone opens a laptop.
There is a second tell, the same failure approached from the other side. Ask what changes depending on how the analysis comes back. If nobody can say what they would do differently in either case, the analysis was never going to drive a decision.
If nobody can say what they would do differently either way, the analysis was never going to drive a decision. It was going to decorate one already made.
And an analysis aimed at the wrong person is wasted however good it is. The person who sends the request is frequently not the person who can act on it, which is why the discipline is to name one approver. Not a committee, not "leadership". One person who owns the call. When that cannot be named, the ambiguity is itself the finding, and usually the thing the organisation is actually stuck on.
02 — Most metrics are noise dressed up as insight
Once the decision is named, the next question is what would count as success, and this is where a lot of otherwise strong analytical work quietly goes wrong.
A metric that only ever goes up tells you nothing about whether to act. A metric that reports what already happened cannot help you steer. And a metric nobody owns, with no cadence for reviewing it, is a number on a slide rather than an instrument anyone uses.
The useful distinctions here are old and unglamorous: vanity against actionable, leading against lagging, and whether individual numbers connect upward to a direction and downward to something a team can actually do on a Tuesday. Individual metrics are not a measurement framework. A framework is what makes the connection explicit.
03 — Say the answer first
Analysts are trained to think data first and conclusion last. It is how the work is done, and it is how it gets written up. Busy stakeholders need exactly the opposite, and the gap between those two habits is where good work goes to die.
Answer first, then the reasoning, then the evidence underneath it. After every finding, say both halves out loud: so what, and now what. A finding without a recommendation attached hands the interpretive work back to the person who has the least context for it.
This is also the point where a lot of analysis reveals how thin it actually is. With a rich data export in hand, it is entirely possible to spend three weeks modelling and arrive with a recommendation that fits in half a sentence and cannot be defended.
04 — In someone else's room, you have no authority
The final week is about delivery, which is a separate skill from having been right, and the one that decides how the last ten minutes go.
A consultant has no positional power over a client. You cannot instruct them. Everything from that point is influence, and influence has a grammar you can learn: contracting the meeting in the first sixty seconds so everyone knows what it is for, signposting, pace, the willingness to pause, and knowing when a stated objection is not the real interest behind it.
The last one matters more than it sounds. A client who says the sample is too small may be saying something quite different underneath, and answering the stated objection while missing the real one is how a well-founded recommendation dies politely in the room.
A note on the brief
The briefs on this course are deliberately incomplete. Scope, success criteria and the specific questions get built with the client rather than handed over.
That is not a teaching contrivance. A consultant is never given a complete brief. Getting the scope out of the client is the job, and on this course it is examinable.
But surely the analysis is the work?
A fair objection, and one worth taking seriously rather than waving away. Rigour is not optional, the modelling is not a formality, and an elegantly delivered recommendation built on bad analysis is worse than no recommendation at all.
True. The claim is not that the analysis matters less. It is that the analysis is necessary and nowhere near sufficient, and that the insufficient part is the one nobody gets taught.
Eight courses covered the craft. The failure mode that remains is not producing a wrong answer. It is producing a correct one that lands nowhere, aimed at a person who cannot act on it, answering a question nobody was stuck on. That failure costs exactly as much as the analysis did, and it is invisible in every quality check you might run on the work itself.
Go deeper
A recurring finding in our State of Product research: organisations are good at collecting insight about their customers, and much less good at acting on it. Kristoffer Avci Nåmark on why the gap between knowing and doing stays open. In Swedish.
Start from the difference, not the deliverable. Before anything gets built, name what should be true afterwards that is not true now. If that cannot be answered, the analysis has no target.
Translate the topic into a decision. Who is choosing, between what options, by when, and what is at stake. "Delivery times" is a topic. Nobody can act on a topic.
Name one approver. Not a committee. If nobody can say who owns the call, that ambiguity is the real finding, and probably the thing blocking everything else.
Give every metric an owner and a cadence. A number nobody reviews on a schedule is decoration. Check whether it can move, whether it leads or lags, and what anyone would do about it.
Answer first, then defend it out loud. Say the recommendation, then the reasoning. Expect interruption, and treat the pushback as the conversation rather than an obstacle to it.
There is a test you can run on whatever you are working on right now, and it takes about a minute.
If the answer came back the opposite of what you expect, what would you actually do differently? If nothing comes to mind, that is the real finding. It is more useful than whatever the analysis eventually says, and it arrives weeks earlier.
Watching a room of analysts arrive at that on their own, and then go looking for the same gap in work they had already delivered elsewhere, was the most useful thing that happened in four weeks.
Your analysis is not the product. The decision it changes is the product.
