I received the Impact Mapping book as a gift from my company, Telstra Purple. It’s been in my long reading backlog for a while, but I finally got around to reading it on the weekend and found it a great and easy read while being full of gems. A lot of the concepts resonated with me, especially because I already knew about the concept, but I still picked up a few ideas. Here are the golden nuggets I wrote down as I was reading the book:

• For all software projects (and most other endeavours), focus on a shared understanding of four key questions with stakeholders:
  • Why [are we doing this?]. This is your goal.
  • Who [can influence the outcome?]. These are your actors.
  • How [can they influence the outcome?]. These are your impacts.
  • What [can we do to support or reduce the outcomes?]. These are your deliverables.

  In that order. Always start with the why, but all of them are key. Without any one of them, you’ll end up building the wrong thing.

• If you’re lost on arriving at a good why, keep asking it until you get to the money (i.e. someone’s boat 😉).

• Finding good questions is more important and difficult than finding good answers.

• The critical component is neither the cause, nor the effect, but rather the validity of the assumption that links them.

• You should do your best so people on the ground and doing the work understand the why. This results in superior solutions. In reality, these people are rarely privy to the information and it mostly exists in the back of senior stakeholders’ minds. Just knowing the how and what is not enough for teams to make the best decisions.

• Environments that focus only on the whats are usually the worst, bums-on-seats places to work at.

• Impact mapping makes it easy to identify solutions looking for a problem. i.e., “We need to do microservices/blockchain/k8s/etc.”

• Who, how and what map nicely to the common user story template clauses of “As a [who], I want [what], so that [how]”. Use this frame of thinking to stop writing user stories like “As a system, I want a customer report” or “As a trader, I want a trading system, so that I can trade”!

• Goals and impacts should be SMART. Beware of “vanity” metrics which are the result of a psychological tendency to measure what’s easily measured and makes people feel good, rather than what can inform good decisions.

• Don’t mistake metrics for goals.

• If you achieve your goal with a different scope than planned, have you succeeded? if the answer is no, then you don’t have the right metrics.

• The what forms your detailed backlog. The aim in delivery should always be to focus on items connected to the most impactful hows and whos and finding the shortest path to the why, not to implement all backlog items. Achieving goals is what matters, not delivering the highest number of features.

• Similarly, going to market and shipping software should not be the goal. The goal should be to make a measurable impact after that happens.

• The initial vision should not be set in stone. We live in a rapidly changing world, especially when it comes to software. The vision should be a living artefact, like most other inputs that feed into software development. Don’t do Water-Scrum-fall!

• What the user/customer wants to get done is much more important than their ideas on how to do it. They are not the technology/solution experts.

• Many teams fail to engage business people because they ask them to focus on prioritising the whats (individual backlog items), while business people are much better engaged and make better decisions when discussing priorities on whos and hows. Prioritising actors and impacts is much more important than prioritising user stories.

• If you follow agile and iterative processes without connecting them to measurables and the overall goal, it’s like saying:

  “We don’t know exactly where we’ll go, but small steps ensure we don’t fall down.”

  So you might end up in a totally irrelevant place, successfully!

There are many online mind mapping tools you can use to create impact maps. MindMup is a good one.

Have you used impact mapping before? Do you think I’ve missed something important? Has reading this post piqued your interest to learn more about it? I’m interested to know your thoughts in the comments section below 👇.