The Workflow Has Two Halves. Only One of Them Has a Product.

Every analytics tool you own serves the same half of the job. The other half never got a product — so it runs on your analysts’ hours, and eats the work they were hired to do.

There is a moment familiar to anyone who has sat in a Tuesday review. A number on the screen is doing something nobody expected. The tooling to display that number is excellent — it loaded instantly, it is accurate, it is well-designed, the company pays real money for it every month. And it is, at that moment, completely useless, because the question in the room is not what happened. It is why, and what should we do. The tool has nothing to say about that. Someone volunteers to look into it. The decision gets made anyway, before they report back.

The instinct is to read this as a gap in a product — something the vendor should get around to shipping. It isn’t. It is the seam between two halves of a workflow, and only one of those halves has ever had products in it.

Six steps, one product category

Lay out what actually has to happen between a business question and a decision, and it comes to roughly six steps. The question has to be decomposed into something answerable — “why did activation drop” is not yet a query. The data has to be pulled from the right places and reconciled. The analysis has to be run. The statistical artifacts have to be ruled out, because half of what looks like a finding is seasonality or a definition change or noise. The result has to be translated back out of chart-language into what it means for the business. And then someone has to decide.

Now take an inventory of the analytics tools your company pays for and mark which of those six they perform.

They do the second one. Warehouses, pipelines, event trackers, BI licenses, the dashboard layer, the lake — every one of them is engineered to get accurate data in front of a human being, quickly and at scale. This is not a criticism. That half is genuinely hard, it has been solved well by serious companies, and the products that solve it are mature and competitive.

But it is one step out of six. And it is the step that was always the most tractable, because it is the one that decomposes into an engineering problem. Storage, transport, and display are things software has known how to do for forty years.

The other five steps have never had a product. They have had a person.

The work that quietly moved onto someone’s plate

That is the part worth sitting with, because it inverts a decade of buying. The assumption was that the tools were the system and the people were the friction around it — the slow part, the queue, the thing to route around. Flip it: for the second half, the person was the system. The analyst in the queue was not a workaround for immature tooling. The analyst was the tooling. There was no product there to buy, so the work went where unbuilt work always goes: onto a person’s plate.

Which means every time a company bought a tool that stopped at the chart, it was quietly handing the remaining five steps to whoever was standing closest to the data. Nobody wrote it up that way. It didn’t appear in the business case, which compared software costs against software costs. But the work landed all the same — and the backlog that every data team now complains about is not a resourcing failure. It is that structure, working exactly as designed, at volume.

You can see the shape of it in how analysts actually spend their week. Long before the current AI cycle, a survey of over eight hundred practitioners by TMMData and the Digital Analytics Association found that most of the profession’s time went not to analysis but to the mechanics around it — accessing, blending, and preparing data — with nearly four in ten spending more than twenty hours a week on it. The number is old, and that is precisely the point: this is not a new inefficiency introduced by modern tooling. It is the permanent condition of a workflow whose second half runs on human hours and always has.

And human hours ration. This is the mechanism behind every symptom operators complain about. A queue forms, because demand for answers exceeds the hours available to produce them. The queue gets triaged, which means most questions are not answered but declined. The ones that survive triage come back after the decision they were meant to inform has already been made on instinct. None of that is anyone’s fault. It is arithmetic.

What the industry calls it, and what it gets wrong

To its credit, the industry has noticed the gap. It has a name for it: the last mile of analytics — the well-documented distance between producing an analytic output and anyone actually changing what they do because of it. The name has been around for years, and there is a whole literature about closing it: better data storytelling, better visualization, tighter alignment between the data team and the business, a decision-intelligence layer bolted onto the end.

The honest version goes one step further than the name allows. A last mile implies you are nearly there — the road is built, the trip is almost done, and what remains is the final stretch. That framing makes the gap sound like a delivery problem: the insight exists, it just needs to be carried the rest of the way and presented more persuasively.

But the insight usually does not exist yet. That is the whole trouble. In the Tuesday review, nothing was waiting to be carried anywhere. The question had not been decomposed, the analysis had not been run, the confounders had not been ruled out — none of the five steps had happened, because the only thing that can perform them is an analyst who has not gotten to it yet. This was never the final stretch of the same road. It is the other half of the trip, and it was never paved, because for the entire history of the category a person was walking it.

Naming it the last mile makes an unbuilt half sound like a finishing touch.

Why self-serve didn’t close it

The obvious objection is that this was supposed to be solved already. Self-serve analytics was pitched precisely as the answer: put the tool directly in the hands of the person with the question, remove the analyst from the middle, and the queue disappears.

What self-serve actually did was widen the door to the first half. It gave more people access to the pulling step — more seats, a friendlier query builder, a drag-and-drop chart. That is genuinely useful and it is not nothing. But handing someone the tool is not the same as handing them the answer, and the five steps that convert one into the other were never in the box. So they stayed where they had always been: on a person.

For the people who had the analytical training, self-serve removed a ticket. For everyone else — most of the company — it relocated the bottleneck rather than removing it. The question still required decomposition they could not perform, and confounders they were not equipped to rule out, and the honest ones knew it. The rest pulled a number that confirmed what they already believed and moved on, which is worse than waiting.

The tell is in the scoreboard. A decade into self-serve, dashboard counts go up and to the right, and the number of business questions a company can actually get answered in a week has barely moved. Those two lines diverge because they were never measuring the same half.

The half that was hard

None of this means the first half was easy or that the products serving it are bad. It means the industry built products for the half that could be productized, priced them as though they covered the workflow, and left the remainder to labor — which was reasonable, because for most of that period there was no other option. Software could store, transport, and display. It could not decompose an ambiguous question, choose an approach, rule out the artifacts, and say what the result means. So it didn’t, and people did.

What changes the picture now is not that the second half got easier. It is that it stopped being exclusively human work — that the reasoning itself, and not just the retrieval, is becoming something a system can perform. That is the actual shift underneath the current moment, and it is worth being precise about what it implies. It does not mean the dashboard gets smarter or the chart gets an AI summary pinned to the top of it. Those are improvements to the first half wearing the language of the second.

It also does not mean what the compressed version of this argument usually implies. Read quickly, “the second half runs on people” sounds like a case for having fewer of them. It is closer to the opposite. Look again at where the analyst’s week actually goes: not to analysis, but to accessing, blending, and preparing — the mechanics of the first half, done by hand because the tools stop short of the question that was asked. The unbuilt half doesn’t only tax the person waiting for an answer. It taxes the analyst hardest, by consuming their week with the part of the job that was never the point of hiring them. The judgment — what to investigate, what the result means for this business, what to do about it — is the part they were hired for and the part that gets crowded out first.

So what happens when the mechanical steps stop needing a person is not that the judgment goes away. It climbs — to the questions that are hard because the framing is contested rather than because the query is long: the data model everyone depends on, the investigation nobody else can run, the number that deserves to be distrusted. The same thing happened when spreadsheets put financial modeling on every desk; the controllers didn’t disappear, they stopped doing arithmetic and started doing finance. And the larger event isn’t what happens to analysts at all. It’s the far bigger group who never had one — whose questions were never going to justify a hire, who have been deciding on instinct this whole time, and who get a floor they have never had.

Ultimately the two-halves picture isn’t a complaint about vendors. It’s a correction to a map most companies are still navigating by. The map says: buy the stack, and analytics is handled. The territory says: you bought the half that displays, and you hired the half that reasons — and then you wondered why the answers were slow. Once you can see the seam, the backlog stops looking like a failure of execution and starts looking like the predictable output of a workflow that was only ever half-built.

The half you bought was never the half that was hard.

Key Takeaways

• Six steps sit between a business question and a decision; the tools you own perform one of them.
• The other five never had a product — so they run on human hours, which is why every analytics purchase quietly handed work to whoever stood closest to the data.
• “The last mile of analytics” flatters the gap: a last mile implies the road is nearly finished. This half was never paved.
• Self-serve widened the door to the first half. Handing someone the tool is not handing them the answer.
• The unbuilt half taxes your analysts hardest: it fills their week with plumbing and crowds out the judgment they were hired for. Build it and the role climbs — and everyone who never had an analyst gets a floor they’ve never had.