A hard truth of decision-making is that complete information will never be available. We use tools, techniques, shorthands, and experience-laden aphorisms to fill in the gaps, but they remain inadequate in addressing uncertainty.
Our individual coping mechanisms are bespoke, strange, and inconsistent. We struggle with self-contradiction over time. Decisions made tomorrow will unfold differently than those made today, even with no change in the available information or perceived circumstances.
These individual problems compound inside organizations, which is where most of us do our work. Thanks to markets that assume a status quo of strategic ignorance, we can mostly get by if we at least do the wrong things together. But that requires cooperation, and cooperation demands shared understanding.
The cultivation of shared understanding only comes about when we can communicate. We are, however, very, very bad at communicating.
If that doesn’t ring true, consider how often a group of people will begin a conversation about problems by first discussing their individual solutions. Each person uses different assumptions, knows a different vocabulary, and has different motivations. Nobody is communicating from the standpoint of a shared understanding of the problem. The conversation stays in the realm of each person’s favorite solution and rarely gets to the important stuff behind it.
On the rare occasions when we do create common understanding, that knowledge almost immediately fades. It doesn’t take very long at all for new decisions to be made without any reference or awareness of that prior understanding — almost like permanent institutional long-term memory loss.
Make no mistake, this is a terrifyingly normal circumstance. Finding ways to prevent or at least limit the damage is our imperative. That’s where Wardley Mapping comes in.
The short version
Wardley Mapping is all about building a shareable visualization of context and intention. It affords the articulation of a detailed strategy while remaining intuitive and compact. A Wardley Map placeholds a point-in-time understanding, making past common knowledge accessible for use in present and future consideration.
Here’s how it works.
Every organization operates within a landscape that represents the context for its decisions. To build a Wardley Map, we express that landscape as a value chain — a series of interdependent activities required to meet user needs. We also categorize the elements of the value chain according to their stage of evolution under supply and demand competition. The result is a single, dense graphic describing our assumptions and intentions that anyone can learn to read.
Use mapping to quickly and proactively analyze strategies and solution sets. Every step of the mapping process reveals new insights that enable better decisions. You’ll avoid costly mistakes and minimize the chance of missing something important.
Basic use helps with organizational fitness, such as knowing what to build, buy, and outsource. Deeper exploration increases the probability of stumbling upon something novel. In general, I view it as a standard practice to diminish risk.
How to map
Mapping is a continual process, with an infinite level of potential iteration and detail. Don’t stress about getting your first map perfect, because you can always make improvements as you discover new information. Start small.
Step 1: What is your purpose?
As a product manager, analyst, executive or anyone else responsible for outcomes, the first thing to do is articulate your purpose. What is that core principle that prompts you to do this work? What do you hope to achieve, and why?
- What is your purpose?
- Why do others follow you?
- What is the higher reason for doing this work?
Step 2: What is the scope?
Next, describe the scope of the map. A reasonable scope can be an individual problem, a product, a business, or an entire industry. Articulating the scope helps you stay focused as you build the map. Remember, start small.
- What critical work are you doing right now?
- What elements of your work need to be better understood?
- What are the individual problems that need to be solved?
Step 3: Who are your users?
Any purposefully created thing has “users.” In this context, whoever finds your organization’s work valuable is a user. For instance, a work of art has an audience, and a ridesharing service has drivers and passengers. Remember whom your work serves.
- Who are your users?
- Who is expecting something from you?
- Who is asking for help?
- Who is missing from the picture?
Step 4: What are their needs?
One of the fundamental principles of Wardley Mapping is a focus on user needs. Once you know who your users are, becoming familiar with their needs can guide you toward doing the right work, intuitively. Ask yourself, “Is this work aligned with our users’ needs?”
- What are your users’ needs, and why do they have those needs?
- What’s their first interaction with you? Why did they come to you?
- What happens next?
- What happens last?
- Are there any unmet needs not listed?
Step 5: What is the value chain?
Understanding user needs is only part of the picture. The constant pressure to responsibly allocate resources (time, effort, funding) means you must prioritize the right work. The Value Chain can help you make those determinations.
To create a value chain, examine your users’ needs and then list all the activities that need to happen in order for their needs to be met. These will be your “first order” activities.
Now list any other activities that need to happen in order for your first order activities to be fulfilled, underneath. This will result in a layer of “second order” activities. This process can be continued to whatever level of granularity and depth is needed, but remember, start simple.
In order to keep track of which activities are subordinate and how they relate to each other, draw lines connecting the subordinate activities to their superior activities. In other words, identify the dependencies.
Note that when any of these dependencies break down, the effect cascades up the chain and can prevent the fulfillment of user needs. Identifying these dependencies means that they can be monitored and managed. At the same time, any work that doesn’t fit into a value chain is at risk for being waste. Observing dependencies and avoiding wasted effort are effective ways to diminish risk.
- What are all the activities that need to happen in order to meet user needs?
- What are the dependencies? Which activities depend on which other activities?
- Is a dependency missing or unmanaged?
Step 6: How evolved is each component in the value chain?
Each dependency in your value chain has evolved through the forces of supply and demand competition. During this evolution, its characteristics have changed as well. In fact, each dependency exists on a spectrum that spans from the new, uncertain and failure-prone to the old, boring and reliable.
A component’s placement on the spectrum of component evolution indicates the most economical way to approach it: Outsource, buy, or build? The fact of the matter is that most organizations will approach each component in a way that matches their own internal bias. In other words, if you like building things, you’ll probably attempt to build it. If you like buying, you’ll probably attempt to buy. And if you like outsourcing, you’ll definitely attempt to outsource. This is expensive and wasteful, when components can instead be treated in an individually appropriate way.
A more evolved component can be outsourced and treated like a building block, while a less evolved component usually needs to be built from scratch or given other investment (money, time and energy). The real danger is in mistreating a more evolved component by building it from scratch.
To illustrate the point, consider Thomas Thwaites’s toaster.
Outsourcing highly evolved components is a critical aspect of building cost-effective solutions. Since you have limited resources, it makes sense to save those resources for the components that actually need special treatment. Don’t reinvent someone else’s wheel!
For each dependency in the value chain, you can use the evolutionary characteristics cheat sheet to determine where the component belongs: Genesis, Custom, Product, or Commodity. For example, you might ask what the market is like for a component. If the market is undefined, then the component is probably in Genesis. A growing market, however, might suggest it’s in Product (+rental). Place each component along the horizontal axis (Evolution) according to your determination.
When you’re starting out, don’t worry too much about placing users and needs. If it helps, by all means do it, but there’s no hard rule.
- How evolved is each component?
- How does the market view or treat it?
Step 7: Now what?
By orienting around your users’ needs and the dependencies involved in fulfilling them, and how to treat those individual dependencies, you can now perform a quick gap analysis:
- Are there any components the wider industry considers “Commodity” that you haven’t outsourced?
- Are there any components the wider industry considers “Product” for which you haven’t purchased an off-the-shelf product?
- Are you managing any components the hard way (e.g., building when you can buy)? And if so, why? There might be a good reason (or there might not). Find out!
- Which components have you decided to focus on and invest heavily in? Are you focused on a few areas, or are you spread over many?
There’s much more that’s possible, and Simon’s book may be a great next step in your learning journey.
If this article helped you, or even if you just have more questions, I would love to hear from you!