In 2005, Simon Wardley was the CEO of a London software company called Fotango, and he had no idea whether his own strategy was any good. He could recite the company’s mission, its priorities, and its financials, but when he asked himself a simpler question, “how do I know any of these choices are the right ones,” he had nothing. So he borrowed the one tool that has helped commanders and navigators make decisions under uncertainty for centuries: a map. That experiment became Wardley maps, and the mapping work at Fotango is part of what led Wardley to correctly predict the rise of cloud computing years before Amazon Web Services made it obvious.
Twenty years later the technique is used inside the UK Government Digital Service, taught in engineering leadership programs, and maintained as a free Creative Commons book. It remains one of the few strategy tools that shows you not just where you are, but which direction the ground is moving under you.
Why most strategy tools only have one axis
A SWOT grid, a business model canvas, a two-by-two priority matrix: these are all diagrams, and Wardley draws a sharp distinction between a diagram and a map. A map has an anchor (for Wardley, the user need), position relative to that anchor, and movement. Most strategy artifacts have none of those. You can shuffle the boxes on a SWOT analysis and it means the same thing. Move a component on a Wardley map and you have changed what the map claims about your business.
A Wardley map has two axes that carry real meaning.
The vertical axis is the value chain. At the top sits the visible user need. Below it, in descending order, sit the components required to deliver that need: the things your users see, then the things those things depend on, then the infrastructure underneath all of it. A cup of tea needs hot water, which needs a kettle, which needs power. The higher a component sits, the more visible it is to the person you are serving.
The horizontal axis is evolution, and this is the axis nothing else has. It runs left to right from novel to ubiquitous, and it captures the single most important fact about any component: things do not stay where they are. What starts as a rare, custom, expensive novelty drifts, predictably, toward becoming a cheap, standardized commodity. Compute is the textbook case. It took roughly forty years for computing power to move from a genesis-stage novelty that differentiated a business to something you now rent by the second from any cloud provider. That drift is the thing a map lets you see and a list of features never will.
The four stages every component passes through
Wardley breaks the evolution axis into four stages, and learning to place components across them is most of the skill.
- Genesis. The component is brand new. Nobody has built it before, it is expensive, it fails often, and it is a source of potential advantage precisely because it is rare.
- Custom-built. The thing works often enough that people build bespoke versions of it. Still costly, still uncertain, but no longer a mystery.
- Product (including rental). Multiple vendors sell a recognizable version. Specifications exist. You buy rather than build.
- Commodity (including utility). The component is standardized, cheap, invisible, and assumed. You would no more build your own than generate your own electricity.
The strategic move is not just placing a component but noticing which direction it is heading. Building a custom version of something that is one step away from becoming a commodity is how companies burn engineering budgets on work the market is about to give away for free. I have watched operations teams spend a year hardening an in-house tool that a two-hundred-dollar-a-month SaaS product rendered irrelevant before the internal version shipped. A map would have flagged that component as mid-evolution and made the build, buy, or partner decision obvious a year earlier.
The patterns that do the analytical work
Placing components is step one. The reason Wardley mapping produces insight rather than just a picture is what he calls climatic patterns: economic forces that act on your landscape whether you like them or not. Wardley documents roughly thirty of these, alongside about forty principles of good practice he calls doctrine and around a hundred context-specific gameplays.
A few climatic patterns do most of the heavy lifting for a product manager:
Everything evolves. No component is permanent. The competitive advantage you have today sits on the same conveyor belt as everything else, moving right toward commoditization.
Past success breeds inertia. The more money a component has made you, the harder your organization will fight to keep it exactly as it is, even as the market moves on. Wardley calls this inertia, and on a map it shows up as resistance to a component that clearly wants to shift right. Naming it turns a vague political frustration into a visible, discussable object.
Efficiency enables innovation. When a lower-level component commoditizes, it does not end the game. It creates a platform for new genesis-stage activities built on top of it. Cheap, metered compute did not kill software companies. It created an entire generation of them.
That third pattern is the one Wardley himself rode. Watching infrastructure commoditize at Fotango is what let him anticipate the platform layer that AWS would later own.
Where this earns its keep for a product manager
Frameworks are cheap. The test is whether one changes a decision you were about to make. Wardley maps change three.
Build, buy, or partner. A component’s evolution stage tells you how to source it. Genesis and custom-built components are where you invest your best people, because that is where advantage lives. Product and commodity components are where you buy or rent, because building them yourself is spending scarce engineering time to reinvent something the market already sells. Most roadmap waste I have seen in twenty years of operations work comes from getting this backward: teams lovingly hand-building the commodity plumbing while under-investing in the one genesis component that actually differentiates them.
Prioritization with context. A now-next-later roadmap tells stakeholders when. A map tells them why. When you can show that a component is about to shift from product to commodity, “we should stop investing here” stops being an opinion and becomes a reading of the terrain. That reframing survives the meeting far better than a ranked list does.
Anticipation. Because evolution is directional, a map lets you place bets on where value will sit in two years rather than where it sits today. That is a genuinely different question from the one a feature backlog answers, and it is closer to actual product strategy than most artifacts that carry the word “strategy” in their title.
Pioneers, settlers, and town planners
One idea from the mapping world travels well even for teams that never draw a map. Wardley argues that the three regions of the evolution axis need three different kinds of people, and that using one kind everywhere is a structural mistake.
Pioneers thrive in genesis. They explore the unknown, tolerate failure, and build things that have never existed. Settlers take a pioneer’s rough discovery and turn it into a real, understood product. Town planners industrialize that product into something rock-solid, efficient, and boring in the best sense. Ask a town planner to invent, or a pioneer to run a commodity service at five-nines reliability, and both will be miserable and bad at it. The value chain needs all three, matched to the right stage.
Drawing your first map without overthinking it
You do not need special software to start. A whiteboard and sticky notes work, and Wardley drew the originals by hand. The sequence is deliberately simple:
- Name the user and the need. Put the user at the top and the specific thing they need directly below. Everything hangs off this anchor. Get the user wrong and the whole map is wrong.
- Build the value chain downward. Ask “what does this need to exist” repeatedly, stacking dependencies below each component until you hit infrastructure you take for granted.
- Place each component on the evolution axis. Be honest about how novel or commoditized each one really is. This is the step that generates argument, which is the point. The disagreement is where the strategy conversation actually lives.
- Look for movement and inertia. Which components are drifting right? Which is your organization irrationally attached to? Where is a competitor about to be undercut by commoditization?
When you outgrow sticky notes, the community has built genuinely good free tooling. OnlineWardleyMaps, an open-source, text-to-map editor maintained by Damon Skelhorn, lets you write a map as code and renders it instantly. Mapkeep adds real-time multiplayer for mapping as a group. Both are free, and there is an actively maintained community hub of guides, plugins, and examples if you want to go deeper.
Where Wardley maps fall short
Honesty about limitations is what separates a useful tool from a cult, so a few caveats.
Placement is subjective. Two smart people will put the same component in different evolution stages, and there is no oracle to settle it. Wardley treats this as a feature, the disagreement forces the real discussion, but it does mean a map is an argument, not a proof. Treat anyone who presents a map as objective truth with suspicion.
It rewards facilitation. A map drawn by one person in isolation tends to encode that person’s blind spots. The value shows up when a cross-functional group builds it together and fights over the placements, which takes time and a facilitator who can keep the room out of the weeds.
And it is not a quick-win tool. A business model canvas can be filled out in twenty minutes and still be useful. A meaningful Wardley map of a real business is a few hours of work minimum, and the first ones you draw will be clumsy. That is the normal learning curve, not a sign you are doing it wrong.
None of that undoes the core value. In a discipline crowded with static diagrams that tell you where you are, Wardley maps are still one of the only tools that show you where the ground is going. For a product manager trying to decide what to build now against what the market will hand over for free in two years, that direction of travel is the entire game.
Simon Wardley’s book “Wardley Maps” is available free under a Creative Commons license through his Medium publication. It is the primary source, and it is worth reading in full.