Use Impact Mapping to Prioritize Product Features

A feature list rarely explains why one idea deserves attention before another. A dashboard, an email reminder, and a new onboarding screen may all sound useful, yet serve different goals. Scoring them together can create a tidy ranking without resolving that disagreement.

Impact mapping helps a team connect feature choices to a business goal through changes in people's behavior. Use it before committing to a ranked backlog, especially when stakeholders keep adding solutions without agreeing on the problem those solutions should solve.

Use the four levels correctly

Gojko Adzic's impact mapping guidance structures the conversation around a goal, actors, impacts, and deliverables. Actors are people or groups who can affect the outcome. Impacts describe how their behavior needs to change. Deliverables are things the organization could provide to support that change.

The distinction matters. “Build an onboarding checklist” is a deliverable. “New administrators complete the first setup without assistance” is a behavior change. “Increase successful activation” is a goal that still needs a measurable definition. Mixing these levels makes the map look complete while leaving the reasoning unclear.

For a broader introduction, see the impact mapping overview. Here, the focus is narrower: using the map to choose between competing feature proposals.

Frame one goal and its boundaries

Bring the product decision-maker, someone who understands users, and someone who understands delivery constraints. Write one goal with a target population, an observable outcome, and a time horizon. Add the current baseline if you have reliable data. If you do not, make establishing it an explicit task rather than inserting a guessed number.

For example, a hypothetical scheduling product wants more new team administrators to complete a real booking during their first week. The team defines “real” to exclude test bookings and specifies the customer segment it can observe. It also sets guardrails: avoid increasing support load sharply and do not pressure users into unwanted notifications.

Do not put “launch a dashboard” in the center. That preselects the solution. If the sponsor insists on a particular deliverable, ask what result would make it worth building. Sometimes that question exposes a fixed contractual requirement; such work should be distinguished from optional outcome-driven bets.

Map actors before solutions

List people who can help or obstruct the goal. For the scheduling product, new administrators configure availability, invitees accept bookings, and support agents help users recover from setup problems. “The database” is not an actor in this sense, although data constraints may affect delivery.

For each actor, write a specific behavior that would support the goal. Prefer “publish an available time slot” to “be more engaged.” Ask how you would recognize the change in an observation, conversation, or product event.

Start from known user difficulties where possible. The customer feedback synthesis process can organize supporting observations, but keep unresolved assumptions marked. An attractive branch is a hypothesis about cause and effect, not a demonstrated result.

Worked example: four requests, different reasons

The scheduling team has requests for an analytics dashboard, guided setup, invitation reminders, and a support macro. Instead of scoring the features immediately, it maps the behavior each is supposed to influence.

The dashboard may be valuable, but the team cannot yet explain its contribution to this goal. It moves to a separate opportunity list. That is not a judgment that analytics is unimportant; it is a decision to avoid mixing retention work with an activation problem.

The map also reveals that guided setup and a short setup call are alternative ways to explore the same behavior. They should not automatically become two committed backlog items.

Prioritize branches before deliverables

Discuss which behavior change appears most important to the goal and which has the strongest supporting evidence. Then consider the uncertainty, effort, and reversibility of possible interventions. Avoid giving every branch the same attention merely because it occupies the same amount of space on the board.

Suppose support conversations repeatedly describe administrators unable to interpret availability settings. The team could first observe a few setup sessions and test clearer examples. If invitees never reach the booking page, simplifying that page may solve the wrong problem. The sequence depends on the evidence, not on which feature is easiest to estimate.

Do not turn rough scores into a precision contest. A score can summarize a discussion, but the explanation should survive without the number. Write the selected branch and the main reason beside it: “Investigate availability setup because it prevents administrators from sharing any booking link.”

Choose a small deliverable that can test the reasoning

For the chosen branch, look for the smallest intervention that can teach you whether the proposed behavior change is plausible. That could be a prototype, a manually delivered service, clearer instructions, or a limited product change. It is not always a new feature.

In the scheduling example, the team tests an example availability pattern with new administrators. It watches whether they can create a suitable slot and explain what invitees will see. The team also checks whether the resulting link leads to real bookings. Completing setup alone would not establish the final goal.

Write what would make the team continue, revise, or abandon this option. If the intervention helps only users with a simple workweek, keep that limitation visible. Do not relabel partial evidence as universal success.

Keep the map and the backlog distinct

The map contains alternatives and causal reasoning; the backlog contains work the team is considering or preparing to deliver. Copying every leaf into the backlog turns options into implied commitments. Transfer only the selected work, and retain a link to the behavior it is intended to support.

Start with the impact mapping template or open Boardmix and draw four levels on a blank canvas. For the scheduling example, connect the first-week booking goal to new administrators, then to publishing a usable booking link. Branch into example availability, guided setup, and a short setup call. Mark the availability example “Explore first” and leave the other options uncommitted. Put the unrelated analytics request in a separate area so it stays visible without becoming part of this goal.

When results arrive, revisit the connection between deliverable and behavior before expanding the feature. If a simpler invitation solves the problem, the map gives you a reason not to build the reminder system. Choosing less work can be the most useful result of the prioritization session.