Measure the Time From Evidence to Decision

Product teams have never had more help making decisions. We have dashboards, research repositories, experimentation platforms, strategy templates and a constant stream of advice about how to use them. AI can now produce analysis, prototypes and code faster as well. Yet many organizations do not seem to be deciding much faster.

I think we often diagnose the wrong delay. When progress feels slow, leaders look at delivery: estimation, sprint planning, engineering capacity or release frequency. Those things matter, but the work is frequently stuck before delivery begins. The team has enough evidence to act, while the organization is still discussing whether the evidence is sufficient, who owns the choice or which stakeholder has to agree.

That delay becomes more visible as production gets faster. Generating another prototype in a day does not help when nobody will choose between the two already on the table. Producing another dashboard does not help when commercial, product and finance teams use different definitions of success. Faster coding can even make the imbalance worse by increasing the number of options waiting for a decision.

I would therefore add a simple operational measure: the time from credible evidence to an explicit decision. The clock should not start when somebody first has an idea. It starts when the agreed standard of evidence has been met. It stops when the organization records a choice, names the person responsible for acting on it and sets the condition for revisiting it. The point is not to turn every conversation into a service-level agreement. It is to make prolonged indecision visible.

Consider an onboarding experiment that shows a clear improvement in activation but introduces more support contacts. The experiment itself may have taken two weeks. The release may require only a few days of engineering work. But the result can sit unresolved for a month while Product argues for activation, Support warns about workload and Finance asks whether the extra contacts affect margin. Delivery reporting will show no bottleneck because nothing has entered development. Evidence-to-decision time will show exactly where the work stopped.

The same applies to less comfortable evidence. A security review may reveal that a planned AI feature requires controls the team did not anticipate. An outage may show that a dependency is less reliable than assumed. Customer research may undermine a feature already promised by Sales. In each case, the organization can commission more analysis to avoid making the trade-off. That creates activity without resolution and often produces the noisy dashboards teams later complain about.

This metric should not reward reckless speed. Some decisions deserve care, particularly when they involve customer data, safety or irreversible commitments. I would compare similar decision types and inspect the oldest unresolved items rather than celebrate a company-wide average. The useful question is not, “Why did this take ten days?” It is, “What new information did we gain during those ten days?” If the answer is none, the delay was organizational rather than analytical.

Tracking this also improves team autonomy in a practical way. Leaders can see whether teams lack authority, whether success criteria were never agreed or whether incentives are in conflict. The remedy might be a clearer escalation path, a pre-agreed threshold for experiments or a joint metric across departments. It is rarely another template. Frameworks are useful when they support a choice, not when they provide a more sophisticated way to postpone one.

I want product organizations to become faster at learning, but learning is incomplete until it changes a decision. If evidence arrives quickly and choices remain slow, improving delivery velocity will only build a larger queue in front of the real constraint.