This is a gust post written by Randy Silver

I have a confession to make: on occasion, I’ve had issues getting people to agree on how to work together.  Getting people to agree 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 the way they prioritize issues. I’ve even written a letter to my former self acknowledging these tricky situations and all the different ways I’ve learned over the years to understand others better. 

But even with better understanding, we’re still 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 organize 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.

‍

‍

How I made it: Dragon Mapping

The thing that ties the Opportunity Solutions Tree, Impact Mapping, and Assumptions Mapping together is that they take conversations and lay them out visually - and force you to confront the logic that holds them together. In many cases, it can generate a revelation when things are laid out this way.

While these models worked well for me when working alone or with others who had used the approaches, they failed with people who weren’t familiar with the approach. We spent time debating the terminology and layout instead of discussing the things that mattered.

And there was one more thing missing: the prompt to fill in the next step and make it explicit. That’s something you get when employing things like the 5 Whys.

Instead of worrying about the layout and  terminology, I started with the end point: What are we trying to achieve, and how will we know when we’ve done so? From there, I simply worked backwards in the simplest way possible. It turned out that the approach worked for me, was easy to teach and adopt, and was adaptable to any manner of situations.

In the end, Dragon Mapping is a combination of all of the above techniques - but a deliberately simplified version of them. It’s not a replacement for any, but a starting point. 

I knew I had really hit the nail on the head when I heard from a client about their own use of Dragon Mapping:

“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

When to use Dragon Mapping

Because I created Dragon Mapping to resolve the hard conversations with stakeholders and teams, it’s especially useful when there’s disagreement on what you’re doing, why you’re doing it, or on what to do next. Its power lies in identifying the risks to success and prioritizing how you work to validate anything that is an assumption.I’ve been able to use this approach in a variety of situations:

1. With a founder who had a case of Shiny-Object Syndrome - they saw opportunities everywhere, and would change direction like a magpie. This gave us a structured way to have a conversation about what was truly important; to separate facts from whimsy; and to prioritize without it feeling like they were being restricted.
2. When stakeholders had conflicting ideas on who the ideal customer profile was for a launch: whether the priority was to target a small customer niche and then expand, or to go for the whole market. The disagreement stalled progress for months before we were able to bring them to the table and settle on one priority.
3. In a workshop for a departmental away day, to get teams engaged - talking to one another about the overall strategy, and how they could work together to make it happen.

How to create a Dragon Map 

The intention is that you can start to use Dragon Maps in just a few minutes - possibly in less time than it took you to read this far. When you’re done, you should have something that looks a bit like this:

‍

‍

Let’s look at the steps to get you there.

Start with your overall goals

The top can be the overall Vision, a long-term Goal, an Outcome or Impact, even a short-term Objective - you’ll need to agree on what this is, as well as a measurement of success for it. If you don’t have agreement on these, then there’s a larger issue that needs to be addressed.

Lay out what needs to be done to achieve them

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. It’s OK if you make some false starts and re-organise things as you go - as we learn more, our understanding of the landscape changes. New questions and possibilities will arise.

Analyze fact versus assumption

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). Color-code or otherwise indicate all of the Assumptions.

Take Stock

Remember that Dragon Maps have only one purpose: to ensure that you’re having better conversations. You’re not trying to create a diagram that is entirely fact-based, but to agree on where the risks actually lie and to prioritize how you’re going to work to validate them.

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. That’s because a lack of unknowns means that it’s probably all been done before.

If part of your strategy is based purely on Assumptions, it’s in a high-risk state.This is great for something that you’re in an early stage on, but a bad sign if you’re committing significant resources without any validation. You’ll want to go through some rapid discovery cycles in this area to ensure that you have a reasonable chance of success on the predicted timeline..

In most scenarios, you’ll find an interesting mix of Facts and Assumptions. The interesting thing is that some of the things you thought of as Facts turn out to be Assumptions - and that others have the same reaction to different elements. Recognising this removes some of the underlying tensions that hamper projects, and allows you to work together to prioritize the validation of anything deemed a risk to success.

Note that this is not something that works 100% of the time - nothing does. There’s always a danger that people form emotional connections to some of their assumptions - and where feelings are involved, facts have a harder time in changing their minds. Dragon Mapping is a tool that may help in this scenario, but advanced stakeholder management skills are required.

Create a plan of action

The last step in the process is to ask, “How might we fix this?”  In the past, I’ve used Dot Voting to allow people to prioritize 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.

Getting started with your own Dragon Map

The easiest way is to get started is to make use the template available on both Miro or Mural, or to watch the video walkthrough of an example map.

Let me know how you get on with it or if you need any help.

Random fact: Why is it called Dragon Mapping?

There’s no actual Dragons, and - as per Simon Wardley’s definition* - it’s not actually a map. So Why Dragon Mapping? 

When I started working on this, it was all about Assumptions. But the term Assumptions Mapping (also not a map!) was already taken, and had been used to great effect by David Bland in his work.

In a 1570 map - the Theatrum Orbis - unexplored areas were depicted as having monsters, and inscribed with the phrase ‘Here Be Dragons’. Taking a similar approach, we’re trying to identify the unknowns and risks in any plan, and then to set about a plan for exploration. 

Also: Dragon Mapping is a fun name that’s easy to remember.

*At a MapCamp talk, Simon Wardley (British researcher, former CEO, start-up advisor) explained the difference between a Diagram and a Map. While both have all of the elements laid out in a relationship to one another, only a map has a directional element. Put more simply: where you put things on a Map matters - and if you move them, it fundamentally changes what they mean. On a Diagram, you can move things around the page without it changing their meaning. Ready more about Wardley mapping here.

Conclusion

Dragon Mapping offers a simplified yet powerful approach to resolving disagreements, facilitating productive conversations, and prioritizing actions in various situations. By visually laying out the goals, exploring the necessary conditions for success, and distinguishing between facts and assumptions, Dragon Mapping enables teams and stakeholders to engage in meaningful discussions and identify risks more effectively. This approach, derived from the combination of existing frameworks such as the Opportunity Solution Tree, Impact Mapping, and Assumptions Mapping, provides a starting point for aligning perspectives and fostering collaboration. While it may not work in every scenario, Dragon Mapping has proven to be a valuable tool that promotes better decision-making and guides teams towards successful outcomes. Its ease of use and adaptability make it a valuable addition to any problem-solving toolkit.

And here’s the dirty secret: the artifact that you produce from this hardly matters. The value of Dragon Mapping is purely in the conversation that results from the activity.

‍Interested in working with Randy or one of our other product management coaches? Tell us the challenges you’d like to solve here and we’ll match you with your perfect coach. 

‍A version of this article was originally posted on Randy’s blog here.

‍