The pathfinder playbook

A pathfinder is a live use case chosen for two reasons at once. It has to produce a result the business will use, with an impact finance is willing to sign off on. It also has to put pressure on a specific part of the operating model, so the parts that do not work are found while the program is still small enough to change them. Two to four of them is usually enough to settle how the model runs.

If the set is picked only on value, the operating model gets its first real test once the portfolio is already large, which is an expensive point to discover that intake is slow or that nobody has the authority to approve a production release.

Choosing the set

Two use cases of the same shape test the same part of the model twice. Pick for coverage instead.

• A fast, high-feasibility case. Intake, scoping, approval, and deployment all get exercised inside a short window, which shows where the process is slow before anything harder depends on it.
• A high-value case that needs the workflow redesigned. This one runs the full distance, including the change work and the handoff into run. It is the case that tells you whether the model can carry something difficult.
• A case where the data is the binding constraint. Access, quality, ownership, or sensitivity is the reason it is hard. It exercises the data work and the governance gates together, which is where most programs find their first real delay.
• A generative-AI case, if generative AI is on the roadmap. Retrieval, evaluation, and the review process for generative systems differ enough from the rest of the portfolio to be worth testing on their own.

Industry changes which use cases fit these descriptions. It does not change the reason for picking one of each.

How ownership transfers

The share of the work your team leads increases across the set, and that is planned into the staffing before the first pathfinder starts rather than decided afterwards.

Before any build begins, name the person on your side who will own the system in production and the team that will carry it after hours. Runbooks, model and data documentation, monitoring thresholds, the retraining trigger and the procedure that follows it, and the access and approval paths all get written while the work is happening, by the people who will use them. Each gate review reports the share of that pathfinder your team led, next to the use case's own numbers.

Ownership has moved when your team has taken a use case through intake, the build, the gate reviews, and its first production incident without us.

Roles transfer at different speeds. Data engineering and analysis usually move first, since those people are already in the business. MLOps and the production support rota take longest, and they are what determines whether your team can carry the third pathfinder on its own.

Reviewing the model at each gate

Run two reviews at every gate. The first covers the use case: whether the value case still holds, how the system performed against the evaluation set, whether the change plan is staffed. The second covers the operating model: how long intake took, whether the gate decision was clear enough to act on, where a handoff lost time, whether the data foundations held, which approvals were slower than the process assumed they would be.

Anything raised in the second review is a change to the playbook, and it should be made while the detail is fresh: the intake form, the gate criteria, the templates, the definition of done at each stage. By the last pathfinder the written playbook matches how the work ran, and each change is recorded against the gate that produced it.