Wardley Mapping

Core Concepts

Origins: From Art of War to Enterprise Strategy

Wardley Mapping was developed by Simon Wardley at Fotango in 2005, with the evolutionary framing concept taking shape in 2004. Its roots are not purely in business school: Wardley drew heavily on military history and Sun Tzu's Art of War, adapting its five strategic factors — Purpose, Landscape, Climate, Doctrine, and Leadership — as the foundational structure for business strategy.

In Wardley's adaptation, these translate to:

Sun Tzu factor	Business translation
Purpose	Organizational purpose and user needs
Landscape	The value chain and competitive environment
Climate	Market conditions, disruption patterns
Doctrine	Organizational practices and decision-making
Leadership	Strategic direction and alignment

This military framing gives Wardley Mapping its core character: it is a tool for situational awareness before action, not a planning template.

On the analytical side, Wardley Mapping is rooted in Michael Porter's value chain analysis (1985). Porter showed that firms create value through coordinated chains of activities — from inbound logistics through operations, marketing, and after-sales service. Wardley extended this by adding the dimension of component evolution, turning a static snapshot into a dynamic model of how capabilities mature over time.

The Two Axes

A Wardley map is a two-dimensional diagram. Understanding what each axis means is the entry point to everything else.

Y-axis: Visibility (value chain position) The vertical axis represents how visible a component is to the user, from the user need at the top down through the layers of infrastructure that support it. This is directly derived from value chain thinking: the higher a component sits, the closer it is to the end user's experience.

X-axis: Evolution The horizontal axis represents how evolved a component is, moving left to right through four stages:

Fig 1

The evolution model assumes that all components move through these stages over time, becoming increasingly predictable, standardized, and available as commodities. The direction of travel is always left to right — you cannot evolve backwards.

The Four Stages and Their Implications

Each evolutionary stage is not just a description of the component — it is a prescription for how to organize around it.

Genesis — Components here are novel and highly uncertain. Experimentation is the right mode. Teams need autonomy, tolerance for failure, and space to explore. These are the places where competitive differentiation is born.

Custom-built — The concept is proven but no off-the-shelf solution exists. Teams are building capability. The work is skilled and expensive. Strategic advantage is still possible here.

Product — Packaged solutions exist and compete on features. The space is more predictable. The right move is usually to evaluate build-vs-buy carefully, since building custom here is expensive relative to the value it creates.

Commodity/Utility — The capability is ubiquitous, standardized, and available cheaply. Examples: cloud compute, email, DNS. Differentiating here is extremely hard and usually a waste of resources. The right organizational mode is efficiency and reliability, not innovation.

The same activity demands different organizational forms at different evolutionary stages. A team structure optimized for genesis work will fail at running commodity infrastructure — and vice versa.

The Bridge to Organizational Design

Wardley Mapping explicitly connects strategic positioning to organizational design. Components at different stages require different team types:

• Genesis: innovation-focused teams with high autonomy
• Custom-built: capability-building teams with deep craft skills
• Product: optimization teams focused on outcomes and adoption
• Commodity: efficiency teams focused on reliability and cost

This has been formalized in frameworks like Architecture for Flow, which integrates Wardley Mapping with Domain-Driven Design and Team Topologies to design adaptive sociotechnical systems. The insight is structural: misaligning your team model with your component's evolutionary stage is a form of organizational debt.

---

Step-by-Step Procedure

Drawing a Wardley map is an iterative, collaborative act. Here is a repeatable sequence.

Step 1: Identify the user and their needs Start at the top of the Y-axis. Who is the user? What do they need? Write the user need at the top of the map. This anchors everything — every component you add must eventually trace back to a user need.

Step 2: Build the value chain downward For each user need, ask: what capabilities or components must exist for this need to be met? Add them to the map below the user need. Then ask the same question of each new component. Keep going until you reach infrastructure-level components. Draw dependency lines connecting components to the things they depend on.

Step 3: Position each component on the evolution axis For each component, estimate its evolutionary stage: genesis, custom-built, product, or commodity. Use these signals:

• Is it well-understood and widely available? — Commodity.
• Are vendors selling packaged versions? — Product.
• Are you building it because no one else has? — Custom-built.
• Is the idea itself barely formed? — Genesis.

Place each component at its estimated position on the X-axis.

Step 4: Read the map for tension and misalignment Look for components that are in the wrong evolutionary stage for how you are treating them. Common patterns:

• Treating a commodity as custom-built (over-investing in undifferentiated work)
• Treating a genesis component as a product (under-resourcing exploration)
• Team structure that does not match component evolution stage

Step 5: Identify strategic moves Use the map to generate questions and options:

• Which components are ready to shift to a commodity provider?
• Where is genuine competitive differentiation possible?
• What team restructuring is implied by the component landscape?

---

Worked Example

Scenario: You are a staff engineer at a mid-sized SaaS company. The platform handles user authentication, a custom analytics pipeline, a machine-learning-based recommendation engine (just launched, internally built), and cloud infrastructure. You have been asked to advise on team structure and investment priorities.

Step 1: User and need User: end customer. Need: personalized product recommendations with reliable access.

Step 2: Value chain The recommendation feature depends on: the ML recommendation engine, the analytics pipeline (which feeds it training data), user authentication (needed for personalization), and cloud infrastructure (compute, storage, networking).

Step 3: Evolution positioning

Component	Stage	Reasoning
Cloud compute/storage	Commodity	AWS/GCP/Azure exist; undifferentiated
User authentication	Product/Commodity	Auth0, Cognito, Okta all available; mature SaaS market
Analytics pipeline	Custom-built	Bespoke to your data schema and ML needs; no off-the-shelf fit
ML recommendation engine	Genesis	Just launched; novel to your domain; highly uncertain

Step 4: Tensions

• If your platform team is treating authentication as a custom problem (building it in-house, assigning senior engineers), you are over-investing in a product/commodity. Consider adopting a managed identity provider.
• The recommendation engine needs a team mode aligned to genesis: small, autonomous, high tolerance for failure. If it is being managed like a product feature (roadmap, fixed sprints, SLA), it will underperform.
• The analytics pipeline is in a valid custom-built stage — it is genuinely differentiating. It warrants skilled engineers and continued investment.

Step 5: Strategic moves

• Migrate authentication to a commodity provider. Redeploy the engineers to the analytics pipeline or the recommendation engine.
• Give the ML team an explicit innovation mandate: separate it from your product delivery process.
• Plan for the analytics pipeline to eventually move toward a product or commodity stage — the tooling landscape (Databricks, dbt, etc.) is maturing fast.

---

Boundary Conditions

What Wardley Mapping cannot do

Wardley Mapping describes how components evolve from genesis to commodity but cannot predict which new components will emerge in the genesis stage. It is descriptive of evolution patterns, not predictive of emergence.

This is a fundamental constraint. The methodology can tell you where your known components sit and how they are likely to develop. It cannot tell you what disruptions will introduce entirely new components into your value chain. Large language models did not appear on any organization's Wardley map before they existed.

Practically, this means:

• Use Wardley maps to reason about your existing landscape and near-term evolution.
• Do not mistake a map for a forecast.
• Maintain separate practices for environmental scanning and weak-signal detection that operate outside your existing value chain.

Where the method gets difficult

Positioning is subjective. There is no algorithm for placing a component on the evolution axis. Teams frequently disagree — which is often the most valuable part of the exercise, but also a source of frustration if treated as a precision tool.

Maps age quickly. A map drawn six months ago may misrepresent the current state of a fast-moving component. Treat maps as living artifacts requiring regular review, not definitive documents.

The method is optimized for technology and business strategy contexts. Its origins in UK enterprise software consulting shaped its vocabulary. Applications in domains with different value chain structures (e.g., hardware manufacturing, public sector services) require adaptation.

The evolution axis assumes one direction. The model treats commoditization as inevitable and one-way. In practice, there are cases where a commodity component gets re-differentiated by a new approach (see: the rebundling of infrastructure by cloud providers). The model handles this poorly.