Almost every company I speak to now has pilots running. A chatbot in customer service, a summarisation feature in sales, an assistant for document review. The technology usually works. Even so, a large share of these initiatives ends after the demo. Not with a bang, but with a budget line quietly running out.
Put these cases side by side and a pattern repeats. The pilot started because the technology was available, not because a specific business problem needed solving. From the outset there is no yardstick against which success could be measured.
Three questions to answer before any pilot
Before a line of code is written or a licence is bought, three questions should be answered in writing. They sound obvious. In practice, most initiatives fail because nobody asked them.
- Which decision or process becomes better, faster or more reliable because of this system?
- How will we know in twelve weeks whether it worked, in numbers the business already tracks?
- Who in the business takes ownership of the result if the pilot succeeds, and have they agreed?
The third question is the hard one. A pilot without a named owner in the business is an IT experiment, and IT experiments rarely survive the next budget cycle. If nobody is willing to put the outcome into their own objectives, that is an honest answer to the question of relevance.
A pilot that changes no decision inside the company is not an investment. It is a demonstration.
Scaling is not a technical problem
The second breaking point is the move from pilot to operations. Technically that step is often small. Organisationally it is large: processes have to be adjusted, roles recut, quality assurance established and people enabled. None of this work appears in a pilot budget, yet it accounts for most of the effort.
Planning a pilot without thinking about operations does not remove that cost. It defers it, and it returns at the worst possible moment, once expectations are already high.
What helps instead
I encourage leadership teams to reverse the order. First agree where substantial value actually sits in the business model. Then check whether data, process maturity and capability are sufficient for that case. Only then talk about technology. It takes longer at the start and saves months afterwards.
This sequence has a second effect that is often underestimated. It builds trust. A leadership team that can follow why one use case comes before another will carry the decision — including when it becomes difficult.
And sometimes the result of this work is that a planned use case gets cancelled. That is not a setback. It is one of the most valuable decisions a leadership team can make in this field.