How to measure the return on an AI project before you start

“What’s the return?” is the first question any board asks about an AI project. All too often it is answered with an optimistic estimate on a slide and then forgotten. Economic research suggests a better way to think about it, and explains why the first few months tend to disappoint.

The J-curve

In 2021, Erik Brynjolfsson, Daniel Rock and Chad Syverson published a paper that has become a reference point. The argument is simple: general-purpose technologies such as AI require large complementary investments, most of them invisible, such as redesigning processes, training people and organising data (Brynjolfsson, Rock and Syverson, 2021).

During that phase, measured productivity seems to stall, or even fall: there is cost and effort, but no visible result yet. Later, as those investments mature, productivity rises above what the statistics can capture. The shape of that path resembles a J.

The authors estimate that, once these invisible investments are accounted for, total factor productivity in the US was 15.9% higher than the official figure at the end of 2017.

For a project, the lesson is direct: the first months show the cost before they show the gain. Measure too early and you will mistake the bottom of the J for failure.

Be wary of easy numbers

The return on AI is often presented with big numbers. A study by IDC commissioned by Microsoft reports a return of 3.7 dollars for every dollar invested in generative AI (IDC, 2024). It is a figure reported by the respondents themselves and funded by a vendor.

Independent measurements are more modest. An NBER study on adoption in the US found that people who use generative AI at work report saving around 5.4% of their working hours (Bick, Blandin and Deming, 2025). That is a real gain, but it will not transform an operation on its own. The big return comes from redesigning the process, not from speeding up isolated tasks.

A five-step method

1. Measure the starting point. Collect a few weeks of real data: time per case, cases per week, errors and rework, and the time between a problem occurring and someone noticing it.

2. Choose a few metrics, and the right ones. Pick one main metric, which leadership already tracks, and two or three control metrics, to make sure you are not gaining in one place at the expense of another. Avoid metrics that exist only inside the project, such as “model accuracy”.

3. Count the full cost. Include the build, internal team time, monthly infrastructure and maintenance, as well as the invisible investments of the J-curve: training and process redesign.

4. Set the decision point. Agree a date and a criterion before you start. For example: after eight weeks in production, if time per case has not halved, we stop and review.

5. Measure in production. Demo numbers are always good. The ones that count come from weeks of real use, with the hard cases and the exceptions, and that is where you see whether the project has climbed out of the bottom of the J.