Wardley Map

Origin & evolution

Simon Wardley developed Wardley Mapping from around 2005 while serving as CEO at Fotango, a Canon subsidiary building early cloud infrastructure. Wardley found that strategy conversations in the company kept cycling without resolution because nobody had a shared picture of what the competitive terrain looked like or how it would change. He drew on the concept of a value chain, familiar from Porter, and added an evolution axis rooted in Geoffrey Moore's technology adoption ideas, producing a map that placed components in two dimensions, giving each component both a position in the value chain and a position on the evolution axis. Wardley has refined and published the methodology openly since then, most accessibly in his long-running "Wardley Maps" book series on Medium (medium.com/wardleymaps), which remains free and open-source under a Creative Commons licence. The framework has been adopted widely in public-sector digital teams and in platform engineering, where "build vs buy vs consume" decisions⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference → recur constantly. The community at learnwardleymapping.com hosts the book and supporting resources.

How it works in practice

Start at the top of the page with the user need you are trying to serve. Decompose it downward: what does the product need to deliver that, what does each of those things need, and so on, until you reach components that do not decompose further. Place each component on the map.

The vertical position is its proximity to the user: higher components are directly visible to users, lower ones are infrastructure that users never see. The horizontal position is its evolutionary stage.

• Genesis: novel, poorly defined, built by exploration. High uncertainty, high potential differentiation.
• Custom-built: better understood, but implemented from scratch by each team that needs it. Still a source of advantage if it is something others cannot easily replicate.
• Product: available as an off-the-shelf product or service from multiple vendors. Buying is usually faster and cheaper than building.
• Commodity: a utility, undifferentiated, consumed like electricity. Building in this space wastes engineering time on something the market has already solved.

Once the components are placed, look for mismatches. A team building custom infrastructure for something that has been a commodity for years is spending engineering time in the wrong place. A team consuming a packaged product in an area that is still in genesis may be accepting constraints🔒ConstraintStrategyA constraint entityView reference → that a purpose-built approach would avoid.

A worked example. A data analytics platform maps its components. The user-facing dashboard🎛️DashboardData & AnalyticsAn analytics dashboardView reference → is in the product stage: it is differentiated for this product but composed of well-understood patterns. The data pipeline🪣Data PipelineData & AnalyticsAn automated pipeline for data transformationView reference → connecting to customer sources is custom-built: it is not yet commoditised for their specific schema requirements. The underlying cloud compute and object storage are commodities: consuming them from a cloud provider is the correct call. The strategic question the map surfaces is: the custom data pipeline is expensive to maintain and competitors🥊CompetitorMarket IntelligenceA competing product or companyView reference → are building similar ones. When will it commoditise, and should the team accelerate that by open-sourcing it or wait for a vendor to solve it?

When to use it (and when not)

Wardley Mapping earns its keep when the team is making "build vs buy vs consume" decisions and needs a defensible frame. It is also the right tool when strategy conversations keep returning to the same components without resolution: the map externalises the disagreement and gives it coordinates.

It is particularly well suited to platform and infrastructure teams, where the question of which layer to own is the strategic question. And it pairs naturally with any discussion about timing: components on the right edge of the map are about to become utilities, and building custom solutions🔧SolutionDiscoveryA proposed approach to address an opportunityView reference → there is a trap.

It is less useful for early-stage consumer products that have not yet identified their core value chain: without a clear user need at the top of the map, the decomposition step has nothing to anchor to. It is also ill-suited to rapid tactical prioritisation, where RICE or ICE will give an answer faster. Wardley maps are strategy artefacts, not sprint-planning tools.

The most common failure is treating the map as a deliverable. A beautiful map that nobody contests is decoration. The point of the map is to provoke and resolve disagreement about where your components actually sit and what the right moves are. Draw it quickly, put it in front of the team, and argue about it.

In the Unified Product Graph

Wardley Mapping is a quadrant framework in the strategy category. Its two-axis structure maps onto four entity types in the Unified Product Graph:

• User Need at the top of the value chain is a need🫀NeedUserA user need, pain, desire, or constraintView reference → entity, the anchor from which the entire map is decomposed.
• Value Chain components are capability💪CapabilityStrategyAn ability that enables value deliveryView reference → entities, each one representing something the product must be able to do to serve the need above it.
• Evolution Stage attaches to feature⭐FeatureProduct SpecificationA product capability or featureView reference → entities, capturing where a specific component sits on the genesis-to-commodity axis and whether it is moving.
• Movement, the strategic intent to shift a component's position or respond to a competitor's shift, is a competitor🥊CompetitorMarket IntelligenceA competing product or companyView reference → entity when the movement is driven by a market actor, capturing the external force that is pushing a component toward commoditisation.

The quadrant pattern gives each entity a two-dimensional position on the map. In the Unified Product Graph, this means a Wardley Map is not a static image but a set of linked entities where each component carries its own edges to the features⭐FeatureProduct SpecificationA product capability or featureView reference → it enables, the decisions it has informed, and the competitors changing its position.