Dragon Mapping: an introduction
TL;DR:
Dragon Mapping is a framework for having hard conversations with stakeholders and teams. Especially useful where there’s disagreement on what you’re doing, why you’re doing it, prioritisation, and what success looks like. You should be able to get people using this in 10 minutes or less.
A Dragon Mapping template is now available on Miro and Mural.
A testimonial:
I recently used Dragon Mapping to break a logjam at leadership level. Using this approach allowed us to illustrate the parts of our strategy that are built on facts - and the part that is basically BS until proven by evidence.
A big win was to visualize in a concrete way to the C-Level team the sheer amount of non-facts, highlighted with red flag emojis vs facts… and to show that at our leadership discussions and offsites, we make a lot of decisions about stuff we basically pull out of our asses, rather than based on gathered evidence and data. This was quite impactful, given that one of the company values is to ‘Love Data’!
-Abdo Wahba, Chief Product Officer at Offerista Group
Background
I have a confession to make: on occasion, I’ve had issues getting people to agree on how to work together. This usually boils down to a lack of genuine understanding between people who have different perceptions of the issues at hand. It gets further complicated by varying motivations and they way that they prioritise the issues.
So we’re left with a problem: people aren’t coming together to work in a productive way on actually solving the issues, which leads to tension, inefficiency and - when it goes really wrong - strife.
We can try to resolve this, either 1:1 in conversations or in groups (yay, workshops!). But words alone rarely do the trick, as they can be misinterpreted and parties can walk away from the conversation without a shared understanding,
There are a variety of tools, frameworks and canvases that help to organise the conversation to generate a shared understanding. I’m partial to Teresa Torres’ Opportunity Solutions Tree, but I know others who like Impact Mapping or Assumptions Mapping. I’ve been able to use each of these on my own or with other Product Managers, and they’re really good at enforcing a rigorous examination of the situation.
Unfortunately, I’ve never once successfully used any of these approaches with a stakeholder. The room gets stuck on issues of terminology, endlessly discussing whether something is an Impact or an Outcome, or something else about how to use the process. The barrier to entry for someone new to these approaches gets in the way of engaging them in the discussion we actually need to have.
I needed something simpler. Something I could use to engage people- individuals or groups - quickly, and get them actively working on solving the issues we have within just a few minutes. So I did what any good Product person does: I stole from the best and iterated. That’s where Dragon Mapping comes from.
Here’s how to get started:
The Dragon Mapping framework. This is all you need. (Really!)
Start at the top -
The top can be the overall Vision, a long-term Goal, an Outcome or Impact, even a short-term Objective. Then ask a deceptively simple question: For this to happen, what must be true? Write down everything, then ask it again, for each answer. Keep repeating as needed - much like the 5 Whys.
Analyse -
Then go back to each thing and discuss if this is a Fact (something that is known and proven, or at least agreed by everyone) or an Assumption (something that is unknown, unproven, or the subject of disagreement). Colour-code or otherwise indicate all of the Assumptions.Take Stock
Step back and take a look at what you’ve produced. What does it tell you?If everything is a Fact, you’re not taking any risks. This is great for something that’s purely in an execution stage, but problematic if you’re trying to achieve anything new in the market.
If part of your strategy is based purely on Assumptions, it’s in a high-risk state.
More likely, you’ll have a mix of Facts and Assumptions. This is normal, but it’s likely that some things that have been identified as the latter were initially understood to be the former. These are where tension often stems from.
Plan of action
How might we fix this? In the past, I’ve used Dot Voting to allow people to prioritise which Assumptions we need to validate. These can be handled by discovery & research activities, experiments, design sprints, or whatever approach is appropriate to your circumstances.
Here’s the dirty secret: the artefact that you produce from this hardly matters. The value of Dragon Mapping is purely in the conversation that results from the activity.
Why is this a map?
As per Simon Wardley, if the position of an item relative to everything else is important, it’s map. Everything else is a diagram.
By that definition, Dragon Mapping isn’t a map. Things can be moved about as needed, without consequence, so long as it furthers a shared understanding and constructive conversation. In rare cases, it may actually function as a map - but this may only happen by accident.
It also doesn’t have any actual dragons.