Impact Mapping: From Stakeholder Requests to Testable Outcomes

Planning sessions can move into scope before the group agrees on the change it expects to see. The Product Owner then leaves with a list that looks actionable but provides little basis for deciding what belongs or what evidence would change the choice.

Impact mapping puts the reasoning on the wall. With one agreed goal, the group traces actors and behavior changes before considering candidate deliverables. A familiar solution can then be examined alongside the assumption it is meant to test.

The four layers of an impact map

Impact mapping, developed by Gojko Adžić, connects four layers:

1. Goal: the outcome the group agrees to pursue.
2. Actors: people, groups, or systems that can influence it.
3. Impacts: observable behavior changes that could contribute to the goal.
4. Candidate deliverables: things the group might build, change, or enable in support of an impact.

The sequence places the stakeholder request among the candidate deliverables and links it to a behavior hypothesis the group can investigate. A goal also needs enough precision to guide a choice: “increase the completion rate for online purchases that reach delivery selection from 42% to 50% by the end of Q2” lets the group test whether a branch belongs.

Set up the decision conversation

Agree why the outcome needs attention now. Decide when the group will review progress and which evidence it will use. If several outcomes are competing for attention, map one and record the others for a separate conversation.

Bring together people who can explain the customer’s experience and the constraints that shape the decision. They also need to understand what the outcome changes for the business. The Product Owner can facilitate, but should not be expected to supply every actor or hypothesis alone. Keep assumptions and unanswered questions beside the relevant branch, then hold one constraint throughout the discussion: describe the behavior change before discussing a solution.

Move from a request to an outcome hypothesis

A sales stakeholder asks for a delivery-cost estimator in checkout, suspecting that customers abandon purchases when delivery costs appear late. The request assumes earlier visibility could improve checkout completion, but that suspicion needs testing. It is a candidate response, not yet a Product Backlog decision.

Place the request beneath the outcome it is meant to influence. In this case, customers may continue with a purchase after seeing delivery costs early enough to decide. That behavior could contribute to more completed purchases, giving the group a causal path to examine.

The path remains uncertain. Funnel evidence and related support contacts can show whether earlier visibility deserves a small test. If it does, the Product Owner can bring a response into Product Backlog refinement and consider its order in relation to the Product Goal. If the evidence points to a delivery-policy or service issue, the next decision may sit outside the Product Backlog.

Example: applying the delivery-cost scenario

The same delivery-cost scenario now becomes a concrete example. An online retailer sees a marked drop in completed purchases after customers reach delivery selection. A sales stakeholder asks for a delivery-cost estimator in checkout because customers may be leaving when the total cost appears later than expected. The sponsor and Product Owner use the following illustrative goal for the next quarter:

Increase the completion rate for online purchases that reach delivery selection from 42% to 50% by the end of Q2.

The checkout estimator requested by the stakeholder is one candidate in the first branch; the table also preserves an earlier product-page cost range as an alternative response. Earlier visibility may help if the surprise comes from timing. It will not address a price that customers already consider too high, and it cannot create delivery options the retailer does not offer. The group therefore checks where customers leave, compares destinations and order values, and reads the related support contacts before deciding what to pursue.

Suppose the evidence shows that customers in one market complete purchases more often when they see a reliable cost range on the product page. The Product Owner can bring that response into Product Backlog refinement and decide where it belongs in relation to the Product Goal. If the evidence instead shows that the delivery price or available option causes abandonment, the group can take a delivery-policy or service decision without adding an estimator to the Product Backlog.

Carry the map into Product Backlog choices

The map retains the reasoning between an outcome and a possible action. Product Backlog refinement makes work transparent and orders it in relation to the Product Goal. A candidate may inform Product Backlog work once it is understood. Some candidates point to a service change instead, and the group drops branches that learning has overtaken. Product Backlog Examples for Better Ordering shows how relevant options can be expressed and ordered.

The same distinction shapes inspection. Evidence-Based Management can help the group inspect whether the outcome is moving and whether a branch still deserves attention. Evidence-Based Management (EBM) for Product Owners: Guide and Examples explains how to bring evidence into that conversation without treating a metric as the decision itself.

Mistakes that weaken the decision

Starting with a requested solution. Return to the outcome, the actor, and the behavior that the request is supposed to support.

Treating feature adoption as a behavior change. “Customers use the new dashboard” describes a response. Identify what the customer would do differently in their work and why that action could affect the outcome.

Treating the map as a commitment. The map informs the next choice. Use what it reveals to decide whether something needs investigation before Product Backlog refinement or ordering.

Bring the pattern into the next conversation

Bring one outcome into the session and leave with a next decision the group can question. Change the map when evidence invalidates an assumption or changes where the group needs to look next. More Product Owner resources can support the next part of that work.

Next step

The Professional Scrum Product Owner course is relevant if you want to practice connecting Product Backlog choices to product outcomes. For groups preparing a live product decision, coaching can help prepare and facilitate the conversation.