At the fictional appointment service Lantern, a roadmap meeting begins with requests for a calendar redesign, text reminders, and a cancellation dashboard. All three are called essential. The stated business goal is to reduce unused appointment slots, but nobody has explained how each request would help.

Impact mapping connects a goal to actors, desired behavior changes, and possible deliverables. Gojko Adzic’s Impact Mapping site presents the questions as why, who, how, and what. Lantern and all its proposals below are hypothetical.

Make the goal concrete before naming features

Lantern defines an unused slot as an available appointment that ends without being used. The team would measure the proportion of such slots over an agreed period, separately from provider cancellations and planned closures.

That definition matters. Reducing late cancellations could help, but cancellations made early enough for another customer to book may be beneficial. A goal that simply says “fewer cancellations” could encourage the wrong behavior.

Why → who → how → what

Why?

Goal

State the business change the work should support.

Who?

Actors

Identify people or groups who can help or obstruct the goal.

How?

Impacts

Describe the changes in actor behavior that matter.

What?

Deliverables

List things you might build or do to support those changes.

The map links deliverables back to behavior and a goal. Each link expresses an assumption to examine, not a guaranteed effect.

Actors can help or obstruct the outcome

Lantern identifies customers who cannot attend, customers willing to take an earlier appointment, reception staff, and service providers. Actors are people or groups whose behavior can affect the goal. They are not a list of software systems.

The customer who cancels is not necessarily the problem. If cancellation is difficult, the system may encourage silence. Reception staff may already refill slots manually. Understanding their work could reveal an existing mechanism worth supporting.

The map should include actors who could block progress as well as those expected to help. A provider who releases availability too late might matter more than another reminder to customers.

Write impacts as behavior changes

Lantern writes three candidate impacts: customers release unwanted appointments earlier, waiting customers accept newly available slots, and staff contact eligible customers promptly.

“Customers receive a reminder” describes delivery of a message. “Customers confirm attendance or release a slot before the refill deadline” describes the behavior the team hopes to change. The distinction makes it possible to ask whether a delivered feature produced the intended effect.

For each impact, note how you would observe it and why it could influence the goal. Earlier cancellations help only if someone can take the released appointment. The two branches may depend on each other.

Put deliverables at the edge of the map

Actor Desired impact Candidate deliverable Important assumption
Booked customer Releases an unwanted slot earlier A clear cancellation link Difficulty canceling contributes to late notice
Waiting customer Accepts a newly available slot An opt-in availability alert Customers can respond in time
Reception staff Refills suitable slots promptly A prioritized contact queue Contact ordering is a meaningful bottleneck

These are hypothetical options, not established findings. Lantern should investigate current cancellation and refill episodes before choosing a solution. A dashboard could be useful, but it belongs on a branch with an explanation rather than at the center of the plan.

A single deliverable can support more than one impact. Several deliverables can support one impact. Keep the map readable enough that the causal reasoning remains visible.

Choose a branch and define a check

Lantern proposes investigating how customers currently cancel. If customers already cancel easily and early, the cancellation-link branch weakens. The team should then examine refill availability rather than polishing the wrong interface.

This is FrameworkWorld’s practical use of the map: choose the most consequential uncertain link, collect evidence, and revise the plan. Record a review point and the evidence that would make you stop. Completing all deliverables is not the success criterion.

For your own session, agree the goal, include people who know the operational work, identify actors, write behavior changes, and only then discuss deliverables. Challenge branches that jump directly from an executive wish to a feature.

What the map cannot settle

Impact mapping does not prove its causal links or establish demand. Metrics can move because of seasonality, policy changes, or different customers. Monitor the goal and the behavior separately, and use an appropriate evaluation design before making strong causal claims.

Use Jobs to Be Done when the team needs better evidence about the circumstances behind customer behavior. Use MoSCoW prioritization when agreeing the scope of a chosen release. The impact map explains why a release might matter before its scope becomes a commitment.

Lantern’s next action is to examine a cancellation-to-refill journey. That investigation can reveal whether the roadmap is solving the problem named in its goal.

Sources and further reading

  • Gojko Adzic, Drawing impact maps, Impact Mapping. The why/who/how/what hierarchy follows this primary explanation; Lantern’s map is invented.