There’s an old saying about assumptions that I probably can’t repeat here. And while it probably does hold true that relying on assumptions makes a “donkey” out of you and me, we still do it!

Many decisions being made by you and your team (and your whole organisation by the way) are based on assumptions.

There is nothing inherently wrong with this. We have many accurate assumptions - sometimes referred to as heuristics - that we use as short-cuts to making timely decisions. And it’s important we do this.

We can’t sit and analyse reams of data for every single decision. (Unlike what Big Big Data tries to tell us.)

However, sometimes our assumptions prove to be wrong for a given set of circumstances. And that’s where our useful tool for making good decisions ends up making us look like a fool.

Enter the assumption map.

The assumption map is a four-by-four matrix (my next post will be about why I love four-by-four matrices so much!) that helps us analyse the assumptions we use, and determine when we might need to dig a little deeper to prove those assumptions.

On the vertical axis (the up down axis if you need to double check your verticals and horizontals more often than your lefts and rights like I do), we have a scale representing the importance of the assumption.

Importance can be measured in any way that is relevant to your particular challenge. It could represent monetary value, reputational impact, progress on a project or any other measure. But it should always revolve around the question “How significant would it be if this assumption was wrong?” (Or to frame it positively, “How significant would it be if this assumption was right?”) The more significant it is, the higher we place the assumption in the matrix.

The horizontal, or left-to-right, axis represents whether an assumption is known or unknown. This axis goes by a lot of names: certainty, evidenced, proven, supported by data, etc. But it comes down to how certain we are than an assumption is accurate, or how much data we have available to prove an assumption. The more “known” or proven an assumption is, the further to the left we place it.

If we follow the positional guidelines mentioned above, our highest risk assumptions will end up in the top right quadrant, titled “leap of faith” in the image. These are the assumptions that need to be tested before you rely on them.

Step-by-step guide to using the assumption map

The assumption map can fit in to many contexts: project management, innovation development, org strategy development, risk assessment, analytics projects, business experiment scoping and so on.

Here’s a step-by-step guide to how I would use the assumption map when scoping a project.

1. Identify and describe your context, be that a project, a problem to solve, a strategy, etc.

2. Ask your team to list all the assumptions they hold about this project. I can be helpful to frame this with a question like “What must be true for us to succeed?”

3. Collaboratively place all the assumptions on the matrix. Two methods work for this: each team member places their assumptions where they think they belong and then the team looks at the matrix holistically and identifies anything they think should be moved. Or if there’s a small number of assumptions, take each assumption one by one, hold it against the vertical axis and have each team member say “up” or “down” and move once for each team member, and then repeat with the horizontal positioning saying “left” or “right”.

4. Once all the assumptions are placed, it can be helpful to have one more round of writing to capture any assumptions that have been missed.

5. Take all the assumptions from the top-right “leap of faith” quadrant and prioritise them. This can be done by their exact position on the quadrant (e.g. the furthest right and highest position is the highest priority), or by a round of dot voting where participants pick the three most important assumptions to test.

6. Starting with the most important assumption, develop a rapid test to determine if the assumption is true (and can be relied on) or is false (and should be mitigated or managed).

Over to you

How have you seen the assumption map used? Or better yet, where could an assumption map have saved your team some pain?