The Project Roadmap

The Roadmap section of the canvas is where the plan lives. Like everything else in the canvas, the plan is sketched lightly at the start and hardens as the project runs. The discipline this chapter teaches is how to plan a project without over-planning it — how to specify enough that the project can be evaluated and either expanded or shut down, and no more.

Three things make up the roadmap: the pilot phase, the graduation criteria, and the KPIs. Each is a deliberate working answer that the team commits to before the pilot starts. Each is meant to be revised as evidence comes in. None of them should require more than a paragraph or two on the canvas.

The pilot phase

The pilot is the first concrete thing that happens. It is the test instrument designed to surface whether the project should continue, change shape, or end. Pilots in this framework have three properties.

They are narrow. The pilot is not a small version of the full deployment. It is a deliberately scoped test of the riskiest assumptions in the project. If the project is a customer support automation, the pilot might cover three categories of ticket, five agents, and four weeks — not “all support tickets, full deployment, three months.” The narrower the scope, the faster the evidence comes back, and the less collateral damage if the pilot reveals problems.

They are time-bounded. The bound is short — short enough that the strategic landscape will not have shifted by the time the pilot ends, short enough that the team cannot afford to over-plan it, long enough to surface the pattern of usage rather than just an early novelty bump.

They are small in scale. A pilot’s purpose is evidence, not coverage. A pilot population of ten users producing rich qualitative feedback is more useful than a pilot population of two hundred producing a smear of statistically inconclusive data. Small populations also mean the team can have actual conversations with the people using the thing — which turns out to be the most valuable feedback channel a pilot has.

The signal that someone is over-planning a pilot is when the conversation about the pilot has gone on longer than the pilot was supposed to last. At that point the pilot has already failed at its primary job, which was to produce evidence quickly.

A lightly sketched pilot might read: Three categories of ticket, five agents, four weeks; weekly check-ins with the agents on what’s working and what isn’t; team meets at the end of week 2 to decide whether to adjust scope. That is enough to start.

Graduation criteria

The graduation criteria are the answer to “what would make us expand this, and what would make us kill it?” They are the most important and most often skipped element of the roadmap.

A project without graduation criteria will not be killed cleanly even if it should be. After the pilot ends, everyone in the room can rationalize whatever the result was — the pilot ran, things happened, some of those things were good, others were not, and the project keeps drifting forward because nobody can say with conviction that it shouldn’t. Set the criteria up front and the conversation changes shape. The result either clears the bar or it doesn’t, and the rationalization window closes.

Three possible outcomes get specified in advance. Expand — the pilot cleared the bar, scale it to the next ring of users or workflows. Continue — the pilot did not clear the bar but did not fail; run another iteration with specific adjustments. Shut down — the pilot did not produce evidence the project will work, and the team is taking the lesson and stopping.

The criteria should be specific and observable. Not “this should make customer support better.” Something like: Resolution time on the three pilot ticket categories drops by at least 15% on average, with no degradation in resolution quality as judged by the team lead, and at least three of the five agents say they would want to keep using this. That is testable. Either the pilot’s evidence clears it or it doesn’t.

The hard part is not writing the criteria. It is writing them honestly enough that they could fail. A team that writes graduation criteria carefully shaped to be unfailable has produced a document, not a test. The test of good criteria is whether the team would shut the project down if the criteria were not met. If the answer is “we’d probably keep going anyway,” the criteria are not real and the roadmap is performing rigor rather than practicing it.

Killing a project cleanly, with documented evidence, is a successful outcome of this framework. It is not a failure to be quietly buried. The Project Layer’s job is to produce evidence about what advances the strategy and what doesn’t, and “this didn’t work” is a perfectly valid output.

KPIs that evolve

Most AI initiatives are over-measured early and under-measured late. The framework reverses both halves of that.

Early in a pilot, the right KPIs are experiential. Did this feel useful? What was awkward? What did it get wrong? Did people end up using it when nobody was watching? These are qualitative metrics, easily dismissed as “soft,” and they are the most important measurements a young pilot has. A pilot that posts decent quantitative numbers but feels broken to the people using it has measured the wrong thing. The experiential signals are what tell you whether the operational ones will mean anything.

Later in a project, after the pilot has settled into a stable pattern of usage, the KPIs harden into operational metrics. Throughput, accuracy, time saved, error rates, cost reduction, conversion lift. These are the numbers that eventually decide whether the project survives review by people outside the team. They are appropriate at the later stage, when the workflow has stabilized and the sample sizes are large enough to mean something.

The mistake is jumping straight to operational KPIs in early pilots. They are too noisy with small samples. They are confounded by the fact that the workflow is being learned for the first time. They are disconnected from whether the thing is actually useful. A team that pre-commits to operational KPIs in week one will end up reporting numbers that look meaningful and aren’t, and the pilot will be evaluated on the wrong evidence.

The light sketch on the canvas: a small set of experiential questions to track in the early weeks, and a small set of operational metrics that will become the focus once the pilot stabilizes. Early: do agents reach for the tool when nobody is watching, where do they override it, what do they say is awkward. Later: average resolution time, accuracy as judged by the team lead, agent override rate. The transition between the two happens gradually, not on a fixed date.

The roadmap is what makes a project killable

The point of the roadmap is not to predict the project’s future. It is to make the project legible enough that the right call can be made at the right moment. A pilot phase small enough to read. Graduation criteria that turn the result into a decision. KPIs that measure the right thing at the right stage.

A project with a real roadmap can be killed cleanly when it should be killed, expanded confidently when it should be expanded, and adjusted with evidence when it should be adjusted. A project without one drifts indefinitely — present in every status update, absent from every meaningful conversation — until someone with enough seniority and exhaustion finally puts it out of its misery.

The next chapter takes up the third and final section of the canvas: risk.