Imagine a driving school that works like this: the instructor gets behind the wheel, does one lap of the practice ground, climbs out and announces: “Works. The car drives.” You are standing next to it, you have not steered a single metre yourself, and you do not have a licence afterwards either. But at least it is now proven that driving a car is technically possible.
Sounds absurd? That is exactly how a surprising number of data and AI initiatives start.
In the last post we turned a wall full of sticky notes into use case streams: clusters of related use cases that share their implementation prerequisites. That leaves two questions on the table. Which stream drives first? And what does the very first driving lesson look like? Both are today’s topic, and on the second one I have a clear recommendation: a proof of value (PoV), and deliberately not a proof of concept.
Which stream drives first? Prioritise until it becomes binding
This is where sound method parts ways with wishful thinking, and the mechanism matters more than any scoring formula.
During use case analysis, the value is captured in a structured way: what effect arises, at what order of magnitude, how will it be measured? And not estimated by the consultant, but assessed by the business leaders themselves, each for their own use cases. In concrete terms: the head of sales puts a number on what customer value scoring is worth to them, and the head of accounting on what automated document checking saves. Everyone assesses what they will later be held to. That is the real trick of this requirements engineering and prioritisation process: it creates commitment. Anyone who has quantified the benefit of their own use case can hardly claim later that the project was forced on them. Ownership is created during assessment, not at kickoff.
The business does not have to shoulder the cost side alone: the effort for the use cases themselves and the allocated cost of the enablers (platform, data connections, governance) are contributed by the consulting partner or the implementing data team. Together that gives every use case an honest benefit-cost pair, and the map turns into an ROI-sorted portfolio. Usually that produces a staggered start: one or two streams immediately, the rest in later horizons, once the foundation holds.
Practice ground or road: the difference between PoC and PoV
So where do the starting streams begin? This is where the driving school comes back. A proof of concept is the instructor’s lap of the practice ground. It answers the question: “is this technically possible?” The answer today is almost always yes. Whether a language model can extract invoice line items or find contract clauses is rarely the interesting question in 2026; others have long since proven that.
A proof of value asks two harder questions: “does this create measurable value here?” And: “can we run it ourselves afterwards?” That is the difference between proving that cars drive and proving that you drive — in real traffic, on your roads, towards your destination. Budgets, trust and ultimately the whole data and AI journey hang on these two questions.
The three goals of a good proof of value
A good PoV takes one or two prioritised use cases from the starting streams and pursues three goals at once.
Prove value. The use case goes into production and is measured against hard figures, for instance checking time per document down from minutes to seconds, error rate down, additional revenue per segment up. Not a demo video, but daily operations. A half-finished model saves exactly zero euros.
Build capabilities so they can be reused. Platform components, data products and standards are built so that the second and third use case can sit on top of them: the factory is created alongside, not afterwards.
Enablement: anchoring the capability in-house. For me the most underrated part, and the reason the driving lesson fits so well. Driving school cars have dual pedals: at the beginning the instructor brakes with you, at the end you drive alone. A PoV after which the service provider leaves and takes the knowledge with them was, by contrast, expensively rented competence, a chauffeur on hire. A good PoV works in tandem from day one: joint implementation, pairing, training, a clean handover. At the end there is a team with a licence, and a partner who concentrates on the next hard routes instead of chauffeuring the easy ones.
And now the asterisks: when a PoC is allowed after all
So that this does not turn into dogma: there are cases in which a proof of concept is worth its money. Namely wherever the technical question is genuinely open: a use case at the edge of what is feasible, a data source nobody knows will hold up in quality, a degree of autonomy at which the AI is meant to decide on its own for the first time instead of merely suggesting. Then “does this work?” is an honest question, and it is best answered small and fast, before you build a PoV on top of it.
And a PoV has prerequisites too. It needs real data access instead of an export file from the week before last, a process owner with time, and metrics defined before the start. Anyone who only starts measuring after the project ends up measuring whatever happens to look good.
The practice ground proves the car
The point of the driving school story is simple in the end: nobody doubts that cars drive. The question is whether you arrive where you want to go, and whether you are the one behind the wheel afterwards. That is exactly what a proof of value proves: measurable value in daily operations, built on capabilities that stay in-house.
The practice ground proves the car. The driving lesson proves you.