Wardley Mapping for Strategic Decisions

Most strategy conversations in tech go something like this: someone draws boxes on a whiteboard, connects them with arrows, and everyone nods along without agreeing on what any of it means. Wardley Maps try to fix that by giving you two axes that actually tell you something.

The idea comes from Simon Wardley, who spent years at Canonical (the Ubuntu company) trying to figure out why so many strategic decisions felt like guesswork. His answer was that people kept making choices about technology and build-vs-buy without understanding where each component sat in its lifecycle.

What a Wardley Map actually is

A Wardley Map is a graph. The vertical axis represents the value chain — things your user cares about sit at the top, and their dependencies stack below. The horizontal axis represents evolution, moving left to right from something brand new (genesis) to something everyone takes for granted (commodity).

So if you're building a web application, "user need" sits at the top. Below that, your custom application logic. Below that, maybe a compute platform. Below that, electricity. The further down and to the right something sits, the less you should be thinking about it — it's already solved.

The four stages of evolution

Every component moves through four stages over time:

Genesis: novel, uncertain, and poorly understood. Nobody really knows how to build it well yet. Research projects live here.
Custom-built: better understood but still requires specific expertise. Most companies build their own version because off-the-shelf options don't exist or don't fit.
Product: good enough that vendors sell packaged versions. You pick from a handful of options and configure them.
Commodity/utility: so well understood that it's a metered service. You pay by usage and don't think about the internals. Think electricity or cloud compute.

The thing Wardley keeps hammering on is that people treat components in stage 2 like they're in stage 4, or vice versa. You outsource something that still needs custom thinking, or you hand-build something that AWS already sells for fractions of a cent.

Why the map helps

Drawing the map forces a few useful conversations. You have to agree on what the user actually needs (harder than it sounds). You have to list the dependencies and figure out which ones are further along the evolution curve than you assumed.

It also makes build-vs-buy discussions less abstract. If a component sits in the commodity zone and you're maintaining a custom version, that's a red flag. If it's still in genesis and you're trying to outsource it, that's also a red flag.

Teams tend to treat all components with the same management approach. But genesis-stage work needs experimentation and tolerance for failure, while commodity-stage work needs efficiency and cost control. Wardley calls this "doctrine" — matching your approach to the evolutionary stage.

Climatic patterns

Wardley identifies a set of patterns that tend to repeat regardless of industry. Components move from left to right over time — they evolve toward commodity. This is not optional; it happens whether you want it to or not. The speed varies, but the direction doesn't.

Another pattern: when a component becomes a commodity, it enables a new wave of genesis-stage innovation on top of it. Cloud compute becoming a utility made it possible for tiny teams to build things that previously required a data center. Wardley calls this "componentization."

Common mistakes

A few things go wrong when people first try mapping:

Confusing the map with a system architecture diagram. The evolution axis is what makes it a Wardley Map. Without it, you just have a dependency graph.
Arguing about exact positions. The point is relative positioning and movement over time, not pinpoint accuracy. If two people disagree about whether something is mid-product or early-commodity, that disagreement itself is useful.
Drawing the map once and filing it away. Maps are meant to change as your understanding changes. A six-month-old map is probably wrong in a few places.

Getting started

The simplest way to start is to pick a single user need and map its value chain. List every component that supports it, then try to place each one on the evolution axis. Don't worry about getting it perfect. The conversation you have while placing things is usually more valuable than the finished map.

Wardley has published his entire book for free online, which is worth reading if this kind of thinking appeals to you. The first few chapters cover the core ideas; the rest goes deep into gameplay and competitive strategy.

Source