Time to First Answer: The Only Data Platform Milestone Worth Tracking

"Go-live" is a milestone that hides failure

Data platform projects report on the wrong thing. Percent complete, tables modeled, sources connected, sprint velocity, go-live date. All of them can be green in month seven on a project that will never produce a decision.

The failure is not visible in those metrics because none of them measures the only thing the platform exists to do, which is turn a question into an answer somebody acts on.

One metric does measure that, and it is uncomfortable enough that most programs avoid it.

Time to first answer, defined precisely

Time to first answer is the elapsed time from project start to the moment a named person makes a real decision using a number the platform produced, without checking that number in a source system first.

Every clause in that sentence is doing work.

A named person. Not "the business." A merchandising director with a first name, who will confirm they used it.

A real decision. Something with a consequence: an order placed, a markdown taken, a store visited, a vendor called. Not a dashboard viewed.

Without checking it first. This is the trust test, and it is the clause that separates a working platform from a demo. As long as the number gets verified in the ERP before anyone acts on it, the platform is a suggestion engine and the ERP is still the system of record.

What good looks like

For a mid-market retailer with a POS, an inventory system, and an ERP:

Under 2 weeks. Achievable when scope is one decision, sources are class one connectors, and the person who signs off is in the room. This is the target.

2 to 6 weeks. Normal and healthy. The extra weeks are metric reconciliation, which is real work.

6 to 12 weeks. Something structural is slow: credential lead times, a legacy source, or a definition dispute nobody has escalated.

Over 12 weeks. The project is sequenced by activity rather than outcome. Nothing about the technology explains a number this large.

Compare that against the industry default, where the first business decision is expected some time after go-live at month nine. Under that plan the metric is not slow. It is undefined for three quarters.

The second metric: time to second answer

First answer measures whether the thing works. Second answer measures whether it scales, and it is the number that predicts whether the platform is still used in a year.

Time to second answer is the elapsed time from the first decision to a decision of a different shape, in a different part of the business, made by a different person.

Healthy platforms show a steep drop. First answer takes three weeks, second takes four days, tenth takes an afternoon. The marginal cost of a question falls because the reference layer, the definitions, and the joins are already built.

Unhealthy platforms show a flat line. Every question takes three weeks because every question is a bespoke project with a ticket, a queue, and an analyst. That is not a platform. That is a services team with a warehouse attached, and it will hit its capacity ceiling and stay there.

If the second answer costs as much as the first, the problem is almost always a missing semantic layer. Metric definitions were solved once, for one question, in the query rather than in a shared place.

How to instrument it without a tracking project

Three fields in a shared document. Question asked, date. Answer delivered and trusted, date. Decision made, date and person.

Record it for the first twenty questions. It takes a minute per question and it produces the only reliable read on whether the platform is compounding or stalling.

The gap between "answer delivered" and "decision made" is the interesting one. If answers land in two days and decisions take three weeks, the constraint is not the platform, it is delivery: the answer is arriving somewhere the decision-maker does not look, or in a form they do not trust, or without the context that would let them act.

That is a different fix from anything in the data stack, and no amount of pipeline work will move it.

Four patterns the metric exposes

The stalled first answer. Week ten, no answer yet, because the team is modeling tables in order rather than answering one question end to end. The fix is to pick one question and cut a thin slice through every layer, accepting that eight layers will be ugly.

The untrusted answer. Answers are produced from week three onward and every one gets checked against the ERP before anyone acts. Reconciliation was skipped. Nothing else matters until a finance person signs off that one metric matches.

The undelivered answer. Answers are right and trusted and live in a BI tool that district managers do not open. Delivery is a layer, and it is the layer most often left to last and funded least.

The flat marginal cost. Twenty answers delivered, each one three weeks. The team is heroic and the platform is not compounding. Build the semantic layer now, before the analyst who knows all the joins leaves.

Using it in a business case

Put the target in the plan as a commitment, with a name attached. "A named decision-maker acts on a platform number without verifying it, by week six."

That single line changes how the project gets sequenced, because it cannot be met by any plan that models everything before answering anything. It forces a thin slice, and a thin slice is what produces a testable result in week two instead of a surprise in month eight.

It also gives the steering committee something falsifiable to review. Percent complete is unfalsifiable. A named person either acted on a number by week six or they did not.