2026-10-28
October 28, 2026
Most program plans decompose a goal straight into features, skipping the only question that matters: who has to act differently for the goal to be met?
Look at the last program plan you inherited. Somewhere near the top is a goal, usually a number. Somewhere near the bottom is a list of deliverables. The part in the middle, the account of which people or systems will behave differently once those deliverables ship, is almost always missing. It lives in the sponsor's head, or in a kickoff deck nobody opens again.
That missing middle is where programs go to die quietly. The migration ships on schedule and nobody adopts the new platform. The internal tool launches and the teams it was built for keep using their spreadsheets. The AI assistant is rolled out to every engineer and the cycle-time chart does not move. In each case delivery succeeded and the program failed, because a deliverable is only a bet that someone will change what they do.
Gojko Adzic named this gap in Impact Mapping (2012). His technique forces a four-question chain: why are we doing this, who can help or hinder it, how should their behavior change, and only then, what should we build. In 2026 the chain matters more, not less. When an agent can draft the deliverable in an afternoon, the scarce thing is no longer producing the feature. It is knowing which behavior change to bet on, and being able to tell afterward whether you got it.
Discovery for a program is not a research phase. It is the discipline of keeping the plan connected to the people whose behavior decides whether it works. Adzic's impact map is the cheapest tool I know for that, because it is a single page, built in a room, that makes the connection visible.
The structure is four levels. At the center sits the goal, which should state the problem and not the solution, and which should be measurable and time-bound. Next come the actors: everyone who can produce the outcome or block it, including users, but also the platform team whose approval you need, the on-call engineers who will inherit the system, the finance partner who controls the budget line. Then the impacts: how each actor's behavior must change, stated as a verb phrase. "Service teams provision through the new pipeline instead of filing tickets." "Directors cite the new dashboard in planning instead of building their own." Last, the deliverables: the features, migrations, and trainings that might cause those impacts.
The ordering is the point. Most teams build the map in reverse: they start from the backlog and reverse-engineer a goal that justifies it. Adzic's guidance is explicit that the deliverables are the last question, and that the map should treat them as assumptions rather than commitments. Once a deliverable sits on a branch under a specific impact, you can ask the question that exposes weak plans: if we ship this, what exactly will person X do differently on Monday morning, and how would we know?
Three things happen when a program does this honestly. First, you discover that some branches have no actor attached. A feature that no named person has a reason to use is a candidate for deletion, and you can say so without anyone's pet project being the target, because the map is the argument. Second, you find actors you forgot. The most common is the "inheriting" actor, the team that will operate the thing after the program disbands. Their impact, "stop paging us for this class of failure," is often more important than the user-facing one and almost never appears in the plan. Third, you get a natural cut line. Impacts can be ranked by how much of the goal they carry, and deliverables inherit that rank. Scope decisions stop being negotiations about features and become decisions about which behavior change is worth paying for.
Pair the map with David J. Bland's assumption mapping, which Strategyzer describes as a grid of importance against evidence. Every impact on your map is an assumption, namely that this actor will change this behavior if given this deliverable. Plot them. The ones in the top-right, important to the goal and unsupported by evidence, are where discovery effort belongs first: a week of interviews, a prototype in front of five teams, a fake-door test. The rest can proceed on the normal delivery track. This gives a program manager something rare, a defensible answer to "why are we still doing research when the deadline is fixed": because three of the impacts carrying 70 percent of the goal have no evidence behind them.
There is an AI-era wrinkle worth naming. Mik Kersten's Output to Outcome (IT Revolution, 2026) argues that as AI removes knowledge output as the main constraint on production, productivity depends on organizational structure and on managing measurable outcomes rather than outputs. An impact map is a small, practical instance of that shift. If you can generate ten plausible deliverables per impact for free, the map's value is in making you choose among them by evidence, and in forcing the outcome to be stated before the output exists.
The failure modes are well known, and Adzic's own guidance flags them. Don't invite twenty people; five or six with real decision-making power is the working range. Don't critique ideas while the group is still diverging. Don't start from the existing feature list and use the map to bless it. And don't dive into detail early: spend the first session on goal and actors, because a bad goal poisons every branch below it.
One last discipline separates a map that gets used from a map that gets filed. Put the impacts, not the deliverables, in your status report. "Four of seven teams now provision through the pipeline" is a program status. "Pipeline v2 shipped" is a delivery status. Executives and CTOs can act on the first. The second only tells them the team was busy.
Try this week. Pick one in-flight program and write its goal at the center of a page. Name every actor, including the team that inherits the system. For each of your top five deliverables, write the single sentence "After this ships, [actor] will [do X] instead of [Y]." Any deliverable where you cannot fill that sentence in is your first scope conversation.
What it is. A one-page planning map that links a business goal to the actors who influence it, the behavior changes (impacts) you need from them, and the deliverables that might cause those changes. It comes from Gojko Adzic's book Impact Mapping: Making a Big Impact with Software Products and Projects.
When to use it. At program kickoff, when a roadmap is mostly a feature list, or when a program is shipping on time and not moving its metric. It suits medium-term, iterative planning where you can review assumptions at the end of each cycle.
How to run it:
When NOT to use it. When the work is fixed-scope compliance or maintenance with no behavior to change, or when the goal is not yet agreed; a map built on a contested goal just relocates the argument.
Example impact: Not "build the new deploy dashboard" but "release managers stop assembling the weekly go/no-go by hand."
Output to Outcome: An Operating Model for the Age of AI — Mik Kersten (IT Revolution, 2026) argues that with AI removing knowledge output as the bottleneck, leaders must manage measurable outcomes rather than outputs. The excerpt is a useful frame for any impact-mapping conversation with a skeptical sponsor.
How assumptions mapping can focus your teams on running experiments that matter — David J. Bland (Strategyzer, 2020). The importance-versus-evidence grid is the natural companion to an impact map; test the important, unsupported assumptions first. Dated, but the technique has not aged.
What is Impact Mapping? — A compact walkthrough of the four levels and the common facilitation mistakes (too many people, people without decision power, starting from the feature list). Good to forward before you run your first session.
"All models are wrong, but some are useful."
— George E. P. Box
Don't miss what's next. Subscribe to Critical Path: