The pathfinder playbook

An operating model on a whiteboard is a hypothesis. It proves out only when work flows through it and you see where it bends. Pathfinders are how you run that test: a small set of live use cases chosen to prove the model, tune it, and build the muscle so your team can run the next one without us in the room.

Every pathfinder has two jobs at once

Each pathfinder delivers value — a genuine use case the business cares about, taken to production, with impact finance validates. This is not a sandbox exercise; it has to earn the credibility to keep going. But each one is also chosen to stress a different part of the operating model, so you find where the machine bends before it carries the full portfolio.

Chase only the value and you get a few nice pilots and a model that was never tested. Test only the model and you get an academic exercise nobody funds. The point is to do both with the same work.

Pick a set that pulls in different directions

Running three use cases of the same shape teaches you almost nothing. Choose two to four that deliberately stress different parts of the model:

• The speed test — a quick, high-feasibility win that stresses intake, scoping, and the path to deploy. Can we move at pace without cutting corners?
• The depth test — a high-value lighthouse that goes all the way, including workflow redesign and the handoff to run. Can the model carry a hard case end to end?
• The data test — a case where the data is messy, siloed, or sensitive, stressing the foundations and the governance gates. Does the machine hold when the data fights back?
• The new-stack test — a generative-AI case, if it's on the roadmap, that stresses the responsible-AI gate and the retrieval setup.

The same logic produces very different sets in a bank, a hospital, or a manufacturer. The archetypes hold; the use cases change.

Move the ownership, not just the work

The part that makes a pathfinder more than a pilot is the ownership slope. Across the set, the work moves from us to you.

We do it. Then we do it together. Then you do it. By the end, your people haven't read about the model — they've run it, with their own hands, on their own use cases, and fixed its rough edges themselves.

On the first pathfinder we run the pod and hold the gates while your people ride along in every role. On the second, your team runs intake and build and we step in only at the hard gates. On the third, you lead it end to end and we shadow, say little, and hand over the pen. The share of the work your people lead should climb visibly across the three — that number matters more for the handover than any single use case's ROI.

Instrument the model as you go

At every gate, run two short retros, not one. The use-case retro asks whether the use case went well. The model retro asks whether the machine worked — did intake move fast, was the gate decision clear, did any handoff lose time, did the data foundations hold. Every friction point is a defect in the model; log it and fix the playbook right then.

By the last pathfinder, the model is no longer the one you drew on the whiteboard. It is the one your own work has shaped. And the test is simple: your team can run the next use case without us. That was the whole point — not to deliver three use cases, but to leave behind a team that can deliver the fortieth.