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 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 three. 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 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 would Example Map 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. 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 wants. The board looks healthy. Velocity is great. But the metric that matters is flat.
What Impact Mapping is
Impact Mapping is a technique created by Gojko Adzic. The core idea: before you decide what to build, work backwards from why you’re building it.
Four levels:
- Goal – the measurable business objective. Not a feature. A number you can check.
- Actors – the people whose behaviour needs to change to reach the goal.
- Impacts – the specific behaviour changes you need from those actors.
- Deliverables – the features that could create those behaviour changes.
Why → Who → How → What.
The structure is a tree. One goal at the root. Every feature 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 plus Lee.
Lee starts at the root. “What’s the one goal? Not a feature. A business outcome you can measure.”
Maya doesn’t hesitate. “Stop the bleeding and get to three hundred active subscribers within three months. The board needs to see the model works before the next funding round.”
“Good. Now – who are the people whose behaviour affects whether you hit that number?”
Identifying actors
Subscribers – people already paying. If they churn, you’re running to stand still.
Potential subscribers – people who haven’t signed up yet.
Farms – the supply side. If farms can’t reliably deliver, the product falls apart and subscribers leave.
Maya (operations) – 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. 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 wrong, and one subscriber cancelled on the spot.
Mapping impacts
For each actor, Lee asks: “What behaviour change would help us reach 300 subscribers?”
Not “what feature do they need.” Behaviour change.
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.
From impacts to deliverables
Now – and only now – does the team talk about features.
Subscribers → Stay subscribed: Pause subscription. Box preview notifications. Flexible box sizes. Subscribers → Refer friends: Referral programme. Shareable box photos.
Potential subscribers → Discover Greenbox: SEO landing pages, local press outreach, social media content. Potential subscribers → Trust enough to try: Customer reviews, first-box discount, money-back guarantee.
Farms → Commit supply reliably: Forward contracts, demand forecasting tools. Farms → Communicate shortfalls early: Shortfall reporting tool, SMS deadline reminders.
Maya → Less time on manual matching: Automated supply matching, substitution rules engine.
Seventeen deliverables across four actors. Every single one traces back to a specific behaviour change, 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?”
Maya is honest. “The farms I work with commit supply because I ring them on Tuesday and ask what they’ve got. A dashboard wouldn’t change that. What would help is if they could just text me when something’s gone wrong.”
Tom’s dashboard is interesting software. It’s not goal-critical. The map makes that visible.
Meanwhile, “pause subscription” is under the most important impact: 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. They churned because there was no pause button.
Sam pulls up the numbers. They’ve lost 17 subscribers in a month. Three mentioned inflexibility. If they could retain even half the churning subscribers, it would be worth more than acquiring new ones – because retained subscribers also refer friends.
The pause feature is a day’s work, maybe two. Tom’s dashboard would take three weeks. The map makes the decision obvious.
Prioritising with the map
Lee draws a two-by-two grid – impact on the goal versus effort to build.
Tom notices something. “My dashboard isn’t even on the grid.”
“The grid only has deliverables from the Impact Map,” Lee says. “Your dashboard couldn’t trace a line back to the goal.”
Tom’s dashboard was never rejected or argued down. It simply didn’t appear. There’s nothing personal about it – the reasoning is visible on the whiteboard.
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 – 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 shortfall reporting.
When to use Impact Mapping
- Quarterly planning – when deciding what the team should focus on next, an Impact Map grounds the conversation in outcomes rather than feature wishlists.
- Roadmap discussions – when stakeholders lobby for competing features, the map provides a framework: “Which impact does this serve?”
- When the backlog feels disconnected – if nobody can explain why half the items are there, Impact Mapping 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. For “what does this specific story mean,” use Example Mapping.
- When the goal isn’t clear. Impact Mapping will just expose that gap – useful, but fix the goal first.
- As a one-off exercise. A map created once and filed away is worthless. Revisit it as you learn. Some hypotheses won’t work. Update the map.
Back to Greenbox
The session takes about ninety minutes. 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. Tom writes the rollback capability that evening. “I never want to be unable to undo a deploy again.” It’s a one-line change – keeping the previous version and being able to swap back. Simple but essential.
Within a fortnight, churn drops noticeably. Two subscribers who’d been about to cancel stay on because they can pause over the Easter holidays. One 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 to the behaviour change to the goal. That’s the difference between shipping features and making progress. The map is a set of hypotheses, and this one checked out. Ship the pause button, churn drops. Hypothesis confirmed. Move to the next.
But a new problem is emerging. The Impact Map has generated a prioritised list of deliverables, and each one is breaking 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 causing real problems. Priya ships “pause for one week,” but “resume after pause” 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 – 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. 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.
They need a way to see the whole – to lay out the user journey end to end, so they stop shipping puzzle pieces that don’t connect.
The next chapter, User Story Mapping: Seeing the Whole, publishes around 18 April.