Skip to main content

Data & AI

A proof of concept should answer a decision, not a question

Most stalled POCs were scoped around whether the technology works. The useful ones are scoped around what happens next if it does.

· 3 min read

There is a particular kind of proof of concept that goes well and changes nothing. The technology performs, the team is pleased, the demo is recorded — and six weeks later nobody can say what the organisation decided as a result.

The failure is almost always in the scoping. The POC was designed to answer a technical question: can we retrieve accurately enough, can the pipeline handle the volume, will the model generalise. Those are worth knowing. But no buying committee has ever released budget because a question was answered. They release budget because a decision became obvious.

The fix is unglamorous. Before any work starts, write down the decision the sponsor is trying to make, the criteria that would settle it, and what each party does on the Monday after the result. Get that on one page and get it agreed. If nobody will sign that page, the POC is not ready to start — and that is useful information too.

The second-order effect is that a well-scoped POC is cheaper. When you know precisely which decision you are informing, most of the scope you were about to build turns out to be optional.