Wardley Mapping is a strategic framework that helps you understand your environment, identify opportunities, and make better decisions by visualizing the evolution of your value chain.
You don't need a map for everything. If you are crossing a familiar room, you don't need a map. But if you are navigating a new city or coordinating a large army, a map is essential.
When two people strongly disagree on a direction (e.g., "Rewrite in Rust" vs "Stay in Node"), it's often because they have different mental models of the landscape. Mapping externalizes these models so you can attack the map, not the person.
Every project faces resource limits. A map reveals if you are accidentally building a "Commodity" (waste) or outsourcing your "Genesis" (giving away your competitive advantage).
In software, we often don't know where to start refactoring. Mapping the user needs down to the database reveals natural "seams" in the domain that are safer boundaries for microservices than technical layers.
You are the Anchor. Your skills are components. Are you investing time learning a skill that is becoming a commodity (and thus losing value)? Or are you positioning yourself in a Genesis space?
Before drawing a map, Wardley emphasizes checking your "Doctrine" - the universal principles that every organization should follow regardless of context.
If you aren't doing these, mapping will be difficult. Start here.
Before you place a single anchor, you must answer one question: "Why am I mapping this?"A map without a specific purpose is an infinite canvas of noise. You cannot map "The Business" — you can only map a specific problem space within it.
This bounds the landscape. It tells you what is relevant and what is noise.
User needs must be concrete enough to be actionable, but abstract enough to be stable.
If you aren't sure if your user need is at the right level, use the "Why?" test. Keep asking "Why does the user need this?" until you hit a strategic goal, then step back down one level to find the concrete need.
Every map starts with an anchor. In business, this is usually the User. The user has specific Needs that must be met.
Without clear users and needs, any subsequent mapping or strategy is baseless. In Domain-Driven Design, this mirrors the exploration of the Problem Space - we must understand the core business value and the stakeholders (Actors) we serve before designing the Solution Space.
When you have multiple stakeholders (e.g., Employer & Employee in a B2B2C model), you often need multiple anchors. Since both are users, both belong at the top (Visibility 1.0).
To satisfy a user need, you need a chain of components. This is your Value Chain. It represents the supply chain of dependencies - physical, technological, data, or practices.
The person or organization with the need (e.g., "Photo Enthusiast").
What they want to achieve (e.g., "Share memories").
How you reach and interact with users (e.g., Website, App, Store).
What you offer to meet the need.
What you need to deliver value (e.g., "Image Processing").
What you need to operate (e.g., "Compute", "Power").
The vertical position represents visibility. However, "visibility" is always relative to the Anchor (the User).
This distinction is critical: Users only perceive value in what is visible to them. The underlying components are essential costs of doing business that enable that value.
The horizontal axis represents Evolution. This is the most critical aspect of Wardley Mapping. All components evolve from left to right driven by supply and demand competition.
The unique, the novel, the constantly changing.
Learning and diverging. We're figuring it out.
Converging on a standard. It works and we sell it.
Industrialized, standardized, expected.
Being replaced. Still running, but sunset is imminent.
The five stages above (Genesis, Custom, Product, Commodity, Deprecated) are helpful labels, but evolution is actually a continuous scale from 0 to 1. Components don't jump between stages - they slide gradually as the market matures. Knowing where within a stage a component sits helps you predict what's coming next.
The component just entered this stage. It has the characteristics, but barely.
Example: A "Product" that just launched. Few customers, many bugs, features still shifting.
The textbook definition. Stable within its category.
Example: A mature "Product" with clear features, growing market, active competition.
About to transition. Shows signs of the next stage.
Example: A "Product" becoming standardized. Price wars, little differentiation—almost a utility.
Competition. As more players enter a market, best practices emerge, prices drop, and features standardize. This competitive pressure pushes components rightward on the axis - from novel to expected.
Prediction. A component at the far right of "Product" is in the Disruption Zone - it's about to become a commodity. If you're investing heavily here, a utility provider (like AWS) may commoditize it before you profit.
Different stages require different methods. You shouldn't use Six Sigma on Genesis (it kills innovation), and you shouldn't use Agile for Commodity (it introduces unnecessary variation).
Understanding the stage tells you what to do with a component. Ask these questions to guide your strategy:
This is where differentiation happens. Invest in Innovation here to create future value.
Focus on Learning and rapid iteration. Reduce cost of change to find the right product fit.
Focus on Optimization and feature differentiation. Win the market share war.
Focus on Cost & Scale. If you are building this yourself, you are likely wasting money. Buy it.
Focus on Migration & Wind-down. Plan the transition, manage technical debt, and reallocate resources.
Beginners often ask: "I wrote this code from scratch yesterday, so it's Genesis, right?"
If you build your own "User Login" system today, you are building a Custom implementation of a Commodity activity. The map shows the market reality (Commodity). The fact that you built it yourself represents Strategic Debt (the gap between where it is and where it should be).
Why do we want things to become commodities? It sounds boring.
Standardized electricity (Commodity) enabled the electric motor. The motor enabled industrial automation. Cloud Compute enabled AI.
Rule: You cannot innovate effectively if your foundations are breaking. You need stable commodities to build new magic on top.
| Characteristics | Genesis | Custom Built | Product | Commodity | Deprecated |
|---|---|---|---|---|---|
| Ubiquity | Rare | Growing | Common | Essential | Declining |
| Certainty | Uncertain | Learning | Converging | Known / Accepted | Obsolete |
| Failure | High / Expected | Moderate | Low / Disliked | None / Surprised | Expected (EOL) |
| Market | Undefined | Forming | Growing | Mature | Sunsetting |
While the five stages of evolution (I-V) are universal, the labels change depending on what you are mapping. Choosing the right "Type" reveals different insights. A single concept (e.g., "Search") can be mapped in multiple ways.
| Type | Stage I | Stage II | Stage III | Stage IV | Stage V |
|---|---|---|---|---|---|
| Activity | Genesis | Custom Built | Product (+Rental) | Commodity (+Utility) | Legacy (+Sunset) |
| Practice | Novel | Emerging | Good | Best | Obsolete |
| Data | Unmodeled | Divergent | Convergent | Modeled | Archived |
| Knowledge | Concept | Hypothesis | Theory | Accepted | Superseded |
"We do X."
Use this for software systems, features, or user interactions.
Example: "Search Function", "Login", "Compute".
"We have X."
Use when the value is in the information itself, not the code.
Example: "User Profiles", "Geospatial Data", "Product Catalog".
"How we work."
Use for methodologies or ways of working.
Example: "CI/CD", "Code Review", "Agile", "Testing".
"What we know."
Use for intellectual property or proprietary algorithms.
Example: "Search Ranking Algorithm", "Customer Insights".
In our application, we map Evolution stages to Bounded Context Classifications.
Competitive advantage. Build in-house. Strategy: build.
Necessary but not differentiating. Buy if possible. Strategy: buy.
Commodity utility. Outsource entirely. Strategy: outsource.
As components evolve, the aptitudes and attitudes required to manage them change. Wardley identifies three main cultural types necessary for a healthy organization:
Teams should be small enough to be fed by two pizzas (Amazon's model). However, fitting the team type to the evolution stage is just as critical as size.
Explorers who thrive in uncertainty. They discover new territory and make the impossible possible.
Builders who take rough prototypes and turn them into products. They create trust, repeatability, and scale.
Industrialists who create the utilities and platforms everyone relies on. They optimize for efficiency and reliability.
Once you have a map, you can start playing the game. Strategic plays are context-dependent moves you can make to manipulate the landscape, accelerate evolution, or defend your position.
The best way to learn mapping is to map something you know intimately: Yourself. Let's apply the Wardley Mapping process to your own career path to decide what to learn, what to leverage, and what to let go.
Who is the user? In this case, it's Future You (or perhaps your family). What do they need?
How do you satisfy "Security"? You need Marketable Skills. How do you satisfy "Fulfillment"? You might need Creative Expression. Break these down further into specific technologies or activities.
Place your skills where they belong. Be honest!
Wardley Mapping is provided under CC BY-SA 4.0 (Creative Commons Attribution-ShareAlike). The concepts are open for the community to use and evolve.