Why use a map
Maps help you see where to differentiate, where to standardize, and where to invest or reduce effort. They make strategic assumptions visible and debatable — which is often more valuable than the map itself.
After mapping, ask: what is becoming commodity, where are we over-investing, and where should we differentiate?
How to read this map
A Wardley Map shows what you need to deliver value, how visible each component is to the user, and how mature each one is.
Y axis (vertical): Visibility. Top = the user can see or feel it directly. Bottom = foundational infrastructure, invisible to them.
X axis (horizontal): Evolution. Left = novel and uncertain. Right = standardized commodity. Components tend to evolve rightward over time, but at different speeds and with resistance (inertia).
Lines show dependencies — a component depends on the components below it. Read from top (user-facing) down to supporting components.
Position is relative to the user and the context. The same component can appear in different positions in different maps.
A map is a snapshot of a system at a moment in time. As components evolve, the map should change.
This map is a communication and learning tool, not a perfect representation. Treat it as a shared thinking aid, not a diagram of truth.
What is a component
A node can represent a capability, system, practice, dataset, or body of knowledge — anything that delivers or enables value.
The right level of abstraction depends on context. "Payments" might be one node in a high-level map, and expand into ten components in a deeper one. There is no universal correct granularity.
A single node can always become its own full map. Start at the level that is useful for the conversation you are having.
How to build a map
1. Start with user needs — not internal goals. Ask: what outcome does the user actually need? Place it near the top. Maps are built from the outside in.
2. Add visible capabilities — what must exist for that need to be met? Place them below the user need and connect them.
3. Add supporting components — what do those capabilities depend on? Keep going down the value chain.
4. Place horizontally by evolution — how well understood and standardized is each component? Novel and uncertain = left. Utility = right.
5. Connect dependencies — use the ⊕ handle on any node to draw a line to what it depends on.
Common mistakes
- Starting from internal goals instead of user needs. "Increase revenue" is not a user need.
- Treating wants as needs. A user may want a feature but the underlying need is something deeper.
- Putting everything too high on the map. Only what the user directly perceives belongs near the top.
- Treating commodity components as differentiators. If it's standardized, it's table stakes — not a moat.
- Trying to make a perfect map. A useful rough map beats a precise one no one reads.
- Mapping too much detail too early. Start simple and refine where the detail actually changes decisions.
- Forgetting that one node can expand. Any complex component can become its own sub-map.
What colors mean in this tool
Colors here are a categorization aid specific to this tool — they are not part of the core Wardley framework. The real axes are value chain position (Y) and evolution (X).
User / Demand
Machine
Fleet / Data
Market / Supply
Custom
Use them to group related components or flag ownership. Don't over-invest in getting them "right."
The → arrow on a node means it is expected to evolve rightward — likely to become more standardized over time. Inertia may resist this shift.