Innovation Decide

Wardley Mapping

Wardley mapping maps a value chain by how evolved each component is, from genesis to commodity, so a shift can be seen before it arrives.

The questionWhat does the user need, which components deliver it, and how evolved is each one?

Matrix · Simon Wardley, 2005

1
Genesis Novel, uncertain, poorly understood
2
Custom-built Bespoke, still being learned
3
Product (+ rental) Repeatable, sold by several suppliers
4
Commodity (+ utility) Standard, high-volume, interchangeable

Schematic of the evolution axis only, not a full map.

When to use it

A team is deciding what to build, buy, rent, or outsource, and each person is picturing a different stack.
A client depends on a technology or practice that is moving from custom-built to a product, and the question is when to stop building it.
People in product, operations, and finance describe the same system differently and talk past each other.
A competitor's move looks irrational, and you want to see what it would look like if it were responding to a shift the client has not noticed.

When to avoid it

There are a few days and no appetite for learning the notation. The learning curve is steep, and a simple value-chain sketch or a Business Model Canvas may be enough.
The open question is what customers need. A map starts from a need you already have, so use the Value Proposition Canvas or customer research to find it.
The future is uncertain enough that you need several plausible paths and not one direction of travel. Use Scenario Planning.
The group will treat the map as a fact, or will spend the whole session disputing where one component sits.

Overview

A Wardley map draws what a user needs and the chain of components that deliver it, then places each component by how evolved it is, from novel and uncertain to standard and bought as a utility. A team can then argue about where to build, buy, rent, or stop, using one shared picture instead of several private ones.

The vertical axis is how visible a component is to the user, and the horizontal axis is evolution, not time. Placement is a judgment, and two people can reasonably place the same component differently. Settling that with evidence is much of the value. A map is a claim to be tested. The notation takes a few sessions to learn, so budget for that before promising a client a result.

The elements of a map

User and need

The anchor at the top. Name the user, which may be a customer, a regulator, or an internal team, and what they need. Everything below is on the map because the need requires it.

Value chain

The vertical axis. Components are linked by dependency, so each one needs the ones beneath it. The higher a component sits, the more visible it is to the user. Infrastructure the user never sees sits near the bottom.

Evolution

The horizontal axis, in four stages. Genesis is novel, uncertain, and poorly understood. Custom-built is bespoke and still being learned. Product or rental is repeatable, defined, and sold by several suppliers. Commodity or utility is standard, high-volume, and interchangeable. The axis is not time. Placement is a judgment about how the component is actually obtained and traded in the market.

Climatic patterns

Wardley's name for forces that act whatever any one company does. The main one is that components move along the evolution axis as supply and demand compete. These are the reason a map can show what is likely to change.

Doctrine

General practices Wardley considers sound in any context, such as focusing on user needs, using a shared language, and challenging assumptions. Doctrine applies before any specific move.

Gameplay

Moves chosen for a particular context after the map is drawn. Examples are building something custom to hold an edge, buying a standard component, or releasing a component openly to speed its move toward commodity.

What it is not

A roadmap or a timeline. The horizontal axis is evolution, not time, and a position implies direction and not a date.
A fact about the business. A map is a view the team has committed to for the sake of argument, and two competent people can place the same component differently. The disagreement is often the most useful output.
An architecture or process diagram. Position carries meaning, and a line between two components means dependency, not data flow or sequence.

The steps

Name one user and one need

Be specific. A map for a whole company becomes unreadable. Pick one user and one need, such as the customer receiving a parcel on the promised date. Output: the anchor at the top of the page.
Draw the chain beneath the need

List the components the need depends on, then ask what each of those depends on, until you reach plain infrastructure. Draw the dependencies as lines, and place components higher or lower by how visible they are to the user.
Place each component on the evolution axis

Ask how the component is obtained today. Is there an off-the-shelf version, a rented utility, or only custom work? Use the number of suppliers, whether prices can be compared, and how much people still argue about how to build it. Mark placements that rest on argument and not on evidence.
Look for movement and for mismatches

Find components that are about to shift right, places where the organization builds custom what the market now sells, and places where it relies on something it assumes is stable. Output: a short list of questions raised by the map.
Choose a move and test the map

Pick one or two moves, such as buy, rent, build, or open. State which placement each move depends on and what would show that the placement is wrong. Show the map to someone outside the room before acting on it.

In practice

The CTO and the head of operations of a delivery company were each sure that the order-routing engine was a differentiator, for different reasons. The consultant had them map one need first: the customer gets the parcel on the promised date. The routing engine went in as custom-built, but only after an argument. The head of operations pointed out that two vendors now sold something similar, which put it closer to a product.

The map also showed what nobody had been discussing. The company ran its own servers and built its own address-matching service, and both sat further to the right than the team had assumed, with several suppliers selling each. The team asked three vendors to run sample data through their address matching, and decided to rent the servers and the address matching, and keep the routing engine in-house for another year while they watched the vendors.

What you leave with

A map for one user need, with dependencies drawn and every placement marked as evidenced or argued.
A list of mismatches: components built custom where a product exists, or relied on as stable while they are shifting.
Two or three candidate moves, each tied to the placement that justifies it.
The placements the team disagreed on, each with a way to settle it.

Failure points

Starting from the company, not the user

The team draws its own org chart or systems and calls it a map. Without a user need at the top, there is no basis for deciding which components matter.

Placement by pride

Components the team is proud of get placed in genesis or custom-built because that sounds distinctive. Ask how the component is bought and sold, not how the team feels about it.

A map too large to read

Sixty components, no shared reading, and a session that ends with a poster. Start with one need and a dozen components, and expand only where a decision requires it.

Nothing is done with it

The workshop ends when the drawing looks finished. Without a move, a stated dependence on a placement, and a test, the map has not been used.

Reading position as a date

A component's place on the axis tells you its direction of travel. The team then budgets as though commodity arrives in two years. The patterns do not provide timing.

The failures above are usually Framing: the wrong problem was chosen before this framework was applied.

Origin

Simon Wardley says he first noticed the evolution pattern in 2004, drew his first map at Fotango in 2005, and refined the technique at Canonical from about 2008. By his own account, he confirmed the evolution pattern in 2007 by plotting how widespread and how certain a large number of activities were. He wrote the technique up as chapters on Medium from 2016, and the chapters were collected into a book, Wardley Maps. The material is published under a Creative Commons Attribution-ShareAlike 4.0 license, so you may use and adapt it with credit, and must share adaptations on the same terms. The evidence for the evolution pattern comes largely from Wardley's own analysis, so read the stages as a useful model and not as a measured law.