The GreenBox team has been heads-down for a few sprints. Subscriptions work. Basic delivery is running. Event Storming gave them shared understanding. Example Mapping drives their stories. BDD catches bugs before they reach production. The team is shipping faster and cleaner than ever.
But on Friday afternoon, Maya pulls up the numbers and stares at them. They hit 214 subscribers at the end of sprint four. That was the target. That was the win. A month later, they’re at 197. The slope is going the wrong direction.
She brings it to the Monday standup. “We hit 214. We celebrated. Now we’re at 197. We’re adding new subscribers, but we’re losing existing ones faster. Churn is eating the growth.”
The room goes quiet. The team has been so focused on building well that nobody noticed the number that actually matters is going backwards.
The feature trap
Tom has been lobbying for a farm analytics dashboard – charts showing yield trends, delivery reliability scores, seasonal forecasting. It’s technically interesting. It’s obviously useful. It feels like the next logical feature.
Priya wants to improve the substitution algorithm. Jas has sketched a redesigned customer homepage. Sam wants an email onboarding sequence for new subscribers.
Everyone has a credible next thing to build. Each one is well-defined – they’d Example Map it beautifully. But none of them address the problem Maya just put on the table: why aren’t they growing?
Sam mentions something else. “Last Tuesday the site was slow for about an hour. Three potential subscribers tried to sign up and got a timeout.” Nobody knew it was slow – Sam’s uptime monitor only checks if the site is up, not if it’s fast. Tom adds a response time check to the monitor. It’s crude – a single number, checked every five minutes – but now they know when the site is slow, not just when it’s down.
This is the feature trap. Teams build what seems obvious, what’s technically exciting, or what the loudest person in the room wants. They ship features that are perfectly good in isolation but don’t actually move the business forward. The board looks healthy. Velocity is great. But the metric that matters – the one that determines whether the company survives – is flat.
What Impact Mapping is
Impact Mapping is a technique created by Gojko Adzic. The core idea is simple: before you decide what to build, work backwards from why you’re building it.
It uses four levels:
- Goal – the measurable business objective you’re trying to achieve. Not a feature. Not a project. A number you can check.
- Actors – the people (or systems) whose behaviour needs to change to reach the goal.
- Impacts – the specific behaviour changes you need from those actors.
- Deliverables – the features or capabilities that could create those behaviour changes.
You can also think of it as Why → Who → How → What.
The structure is a tree. One goal at the root. Actors branch off the goal. Impacts branch off each actor. Deliverables branch off each impact. Every feature on the map can trace a path back to the goal. If it can’t, it doesn’t belong.
(Why?)
(Who?)
(Who?)
(How?)
(How?)
(How?)
(What?)
(What?)
(What?)
(What?)
Running the session
Maya books an hour. The whole team is there: Maya, Tom, Priya, Jas, Sam. Lee joins too – he’s seen enough Impact Mapping sessions to know where teams get stuck.
Lee starts at the root. “What’s the one goal you’re trying to hit right now? Not a feature. A business outcome. Something you can measure.”
Maya doesn’t hesitate. “Stop the bleeding and get to three hundred active subscribers within three months. We hit 214 and we’re already sliding backwards. The board needs to see that the model works before the next funding round.”
Lee writes it on the whiteboard. “Good. That’s specific, measurable, and time-bound. Now – who are the people whose behaviour affects whether you hit that number?”
Identifying actors
The team brainstorms actors. Not every person in the world – just the ones whose behaviour directly affects the goal.
Subscribers – people already paying. Their behaviour matters because if they churn, you’re running to stand still.
Potential subscribers – people who haven’t signed up yet. You need new ones to grow.
Farms – the supply side. If farms can’t reliably deliver, the product falls apart and subscribers leave.
Maya (operations) – Maya herself is an actor, and writing her own name on the board is uncomfortable. The Event Storm already surfaced her as the supply-matching bottleneck. Now the Impact Map puts it more starkly: she’s not just a bottleneck in the process, she’s a risk to the goal. If she’s the constraint, she’s actively preventing the team from reaching 300 subscribers. She’s spending hours each week manually matching supply to demand, and last week it caught up with her. She was still finalising substitutions when the courier arrived, two boxes went out with the wrong contents, and one subscriber cancelled on the spot. If Maya’s manual process doesn’t scale, it doesn’t just cap growth – it actively drives churn.
Four actors. That’s enough to work with.
Mapping impacts
This is where it gets interesting. For each actor, Lee asks: “What behaviour change would help us reach 300 subscribers?”
Not “what feature do they need.” Behaviour change. What should they do differently?
Subscribers:
- Stay subscribed (don’t churn)
- Refer friends
Potential subscribers:
- Discover GreenBox exists
- Trust it enough to try
Farms:
- Commit supply reliably
- Communicate shortfalls early
Maya:
- Spend less time on manual matching
Seven impacts. Each one is a lever that moves the goal. The team is already having better conversations than “what should we build next” because they’re thinking about people and behaviour rather than features.
From impacts to deliverables
Now – and only now – does the team talk about features. For each impact, they ask: “What could we build that would create this behaviour change?”
Lee is strict about this. “Don’t jump to your favourite feature. Start from the impact and work forward. What would actually cause this change?”
They work through each actor in turn.
Subscribers: What would help them stay subscribed? Pause subscription (the obvious one after losing people to inflexibility). Box preview notifications so they know what’s coming. Flexible box sizes so they can adjust. And what would get them to refer friends? A referral programme. Shareable box photos they can post on social media.
Potential subscribers: How do they discover GreenBox? SEO landing pages, local press outreach, social media content. And what would build enough trust to try? Customer reviews, a first-box discount, a money-back guarantee.
Farms: What would help them commit supply reliably? Forward contracts, demand forecasting tools. And communicating shortfalls early? A simple reporting tool, SMS reminders before the deadline.
Maya: What would free up her time on manual matching? Automated supply matching, a substitution rules engine.
Seventeen potential deliverables across four actors. Every single one traces back to a specific behaviour change, which traces back to a specific actor, which traces back to the goal.
The insight that changes everything
Tom looks at the map and goes quiet. His farm analytics dashboard isn’t on it.
He tries to find a place for it. “It could go under farms – help them commit supply reliably?”
Lee pushes back. “Would a dashboard showing yield trends actually change whether a farm commits supply? Or is that information that’s nice to have?”
Maya is honest. “The farms I work with commit supply because I ring them on Tuesday and ask what they’ve got. An analytics dashboard wouldn’t change that behaviour. What would help is if they could just text me when something’s gone wrong – the shortfall reporting tool.”
Tom’s dashboard is interesting software. It’s not goal-critical. The map makes that visible.
Meanwhile, “pause subscription” is sitting on the map under the most important impact of all: keeping existing subscribers. Jas mentions that three subscribers have already cancelled because they were going on holiday and couldn’t skip a week. They didn’t churn because of bad produce or poor delivery. They churned because there was no pause button.
Sam mentions something she noticed while emailing subscribers: “Two of our new sign-ups this month heard about us from a colleague who already subscribes. We didn’t even ask them to spread the word. Imagine if we made that easy.”
Sam pulls up the numbers. They have 197 subscribers – down from 214. They’ve lost 17 in a month. Three of those mentioned inflexibility as the reason – they were going on holiday and couldn’t skip a week. If they could retain even half of those churning subscribers, it would be worth more than acquiring new ones – because retained subscribers also refer friends.
The pause feature is trivially simple to build. A day’s work, maybe two. The farm analytics dashboard Tom was planning would take three weeks.
A day’s work that directly reduces churn versus three weeks on something that doesn’t connect to the goal. The map makes the decision obvious.
What the map tells you
Impact Mapping doesn’t tell you what to build. It tells you what matters. There’s a difference.
The map reveals several things at once:
Where the leverage is. Reducing churn among existing subscribers is higher leverage than acquiring new ones. Every retained subscriber compounds – they stay, they refer, they provide social proof. And re-recruiting a lapsed subscriber is brutally hard. The team already did all the work to get that person to trust GreenBox enough to sign up once. Losing them to something fixable – like the lack of a pause button – wastes all of that effort. The map makes this visible by showing how many deliverables cluster under “stay subscribed.”
What’s missing. Before the session, nobody had suggested a referral programme. It fell out naturally when the team asked “how do we get subscribers to bring us new subscribers?” The map creates space for ideas that wouldn’t surface in a standard backlog grooming session.
What doesn’t connect. Tom’s dashboard. Jas’s homepage redesign (nice, but which impact does it serve?). Features that can’t trace a line back to the goal get exposed.
Where you’re guessing. Some of the deliverables are hypotheses. Will customer reviews actually build enough trust to convert potential subscribers? Maybe. The map makes it explicit that you’re betting on a causal chain: reviews → trust → sign-up. You can test that cheaply before building an elaborate review system.
Prioritising with the map
The map shows what matters. But with seventeen deliverables, the team still needs to decide what to build next. Lee draws a simple two-by-two grid on the whiteboard — impact on the goal on one axis, effort to build on the other.
“Take each deliverable from the map,” Lee says, “and place it on the grid. Don’t agonise about precision – just rough-sort them based on what you know right now.”
The team writes each deliverable on a sticky note and places them. It takes about ten minutes, with some healthy argument about where things land.
The top-left quadrant – high impact, lower effort – is where the gold is. Pause subscription, shortfall reporting, SMS reminders. These are the things that directly move the subscriber number and can be built in days, not weeks.
The top-right – high impact, higher effort – is the next tier. The referral programme and automated supply matching are worth doing, but they need more planning.
Tom notices something. “My farm analytics dashboard isn’t even on the grid.”
“Right,” Lee says. “The grid only has deliverables from the Impact Map. Your dashboard couldn’t trace a line back to the goal, so it didn’t make the map, which means it doesn’t get prioritised. It’s not that it’s a bad idea – it just doesn’t have a place in the conversation right now.”
That’s the power of the process. Tom’s dashboard was never rejected or argued down. It simply didn’t appear, because the map only contains things that connect to the goal. There’s nothing personal about it – the reasoning is visible on the whiteboard for everyone to see.
But it doesn’t quite feel that way to Tom. After the session, he goes back to his desk and quietly closes the design document he’d been working on for the dashboard – the one with the seasonal forecasting charts he’d been excited about. Priya notices. She sends him a message: “The dashboard isn’t dead. It just serves a different goal.” Tom doesn’t respond for an hour. Then: “I know. Thanks.”
The team commits to the top-left quadrant for the next two sprints. Pause subscription first, then the shortfall reporting tool. They’ll revisit the grid after that and see if the numbers have moved.
During sprint planning, Tom notices the board has eight stories “in progress” and only two “done.” Everyone started something, nobody finished anything. Lee looks at the board and asks: “How many stories can your team realistically finish in a week?” Tom: “Two, maybe three.” Lee: “Then why are eight in progress? Start finishing before you start starting.” Tom moves five stories back to “to do.” The sprint velocity doesn’t change, but the flow does – stories start actually finishing instead of slowly accumulating half-done work across every column.
One thing Lee flags: “Don’t expect any single feature to reverse the churn. The pause button reduces cancellations. The shortfall reporting improves supply reliability. When you eventually ship referrals, they’ll accelerate growth. But no one feature is a silver bullet. Getting back to 200 and beyond means multiple levers working together – retention, acquisition, product quality, and word of mouth. The map helps you see all the levers. Don’t fall in love with just one.”
How it fits with the other techniques
Impact Mapping doesn’t replace Event Storming or Example Mapping. It answers a different question.
Event Storming answers: What happens in our domain? It builds shared understanding of the business process.
Example Mapping answers: What exactly does this story mean? It turns vague requirements into concrete, testable examples.
Impact Mapping answers: Why are we building this, and does it actually matter? It connects features to goals.
They work in sequence but serve different purposes. Event Storming gives you the territory. Impact Mapping points you at the right destination. Example Mapping makes sure you don’t get lost on the way there.
When to use Impact Mapping
Quarterly planning. When you’re deciding what the team should focus on for the next quarter, an Impact Map grounds the conversation in outcomes rather than feature wishlists.
Roadmap discussions. When stakeholders are lobbying for competing features, the map gives you a framework for evaluating them. “Which impact does this serve? How does that connect to the goal?”
“What should we build next” arguments. When the team can’t agree on priorities, the map depersonalises the decision. It’s not about whose idea wins – it’s about what connects to the goal.
When the backlog feels disconnected. If your backlog is a long list of items and nobody can explain why half of them are there, an Impact Mapping session will either connect them to a goal or expose them as noise.
When not to use it
Individual story-level decisions. Impact Mapping operates above the feature level – it connects whole capabilities to business goals. For “what does this specific story mean and how do we build it,” use Example Mapping.
When the goal isn’t clear. If leadership can’t articulate a measurable goal, Impact Mapping will just expose that gap (which is useful, but you need to fix the goal problem first).
As a one-off exercise. An Impact Map that gets created once and filed away is worthless. It needs to be a living reference that the team revisits as they learn. Some impacts won’t work. Some deliverables will turn out to be duds. Update the map.
When the fundamental question is “do customers want this at all?” Impact Mapping assumes there’s a market for what you’re building. It helps you prioritise which features move the needle, but it can’t tell you whether anyone wants a curated local produce box in the first place. If GreenBox’s real problem is that the market doesn’t exist – that people in their area prefer supermarket convenience over farm-fresh produce – no amount of pause buttons or referral programmes will fix it. For that, you need to talk to people who chose not to subscribe and ask them why. Discovery techniques map the domain and clarify what to build. They don’t validate whether anyone cares. That’s a different kind of research.
The map is a hypothesis
This is the most important thing to understand about Impact Mapping. The map is not a plan. It’s a set of hypotheses.
“If we build a pause feature, subscribers will churn less” is a hypothesis. “If we add customer reviews, potential subscribers will trust us more” is a hypothesis. The map makes these hypotheses explicit and traceable, which means you can test them.
After the GreenBox team ships the pause feature, they can check: did churn actually decrease? If yes, the hypothesis was right – move on to the next highest-impact item. If no, the hypothesis was wrong – go back to the map and rethink.
This is what separates Impact Mapping from a feature roadmap. A roadmap says “build these things in this order.” An Impact Map says “we believe building these things will cause these behaviour changes, which will move us toward this goal – and we’ll check whether we’re right.”
Back to GreenBox
The session takes about ninety minutes. When it’s done, the map is on the whiteboard, photographed and shared in the team Slack. Tom starts on the pause feature that afternoon. It ships two days later.
The deploy has a bug. Paused subscribers still get charged. Sam gets three angry emails within an hour. Tom tries to roll back but his deploy script only goes forward – there’s no way to swap back to the previous version. He has to fix the bug and deploy again, which takes forty-five minutes. Three subscribers were incorrectly charged $25 each. Maya refunds them personally and apologises. Tom writes the rollback capability that evening. “I never want to be unable to undo a deploy again.” It’s a one-line change to his script – keeping the previous version and being able to swap back. Simple but essential.
Within a fortnight, churn drops noticeably. Two of the subscribers who’d been about to cancel stay on because they can pause over the Easter holidays. One of them tells a friend, who signs up.
It’s a small win. But it’s a connected win – the team can trace a line from the feature they built to the behaviour change they wanted to the goal they’re chasing. That’s the difference between shipping features and making progress.
Maya stops asking “are we building the right things?” She can look at the map and see.
But a new problem is emerging. The Impact Map has generated a prioritised list of deliverables. Each deliverable is breaking down into multiple stories. The pause feature was simple – two days, done. But the referral programme has five stories. The shortfall reporting tool has three. The backlog is growing fast.
And it’s starting to cause real problems. Priya ships the “pause for one week” story, but the “resume after pause” story is three sprints away because Tom is working on referral tracking. From the subscriber’s perspective, they can pause but there’s no way to unpause – that’s a broken experience, not a feature. Meanwhile, Sam has built the shortfall reporting tool for farms, but nobody built the notification that tells Maya a shortfall was reported. The tool exists but it’s disconnected from the workflow.
The team is shipping individual stories that make sense in isolation but don’t add up to a coherent experience for anyone – not the subscriber, not the farmer, not Maya. They need a way to see how everything connects from the user’s perspective, so they can ship things that actually work end to end instead of leaving half-finished journeys everywhere.
That’s User Story Mapping (coming 12 May).