Wardley Mapping: Seeing the Board You've Been Playing Blind

A Wardley map is a two-axis diagram: it plots your value chain — from the user's need down to the infrastructure beneath it — against how evolved each part is, from genesis to commodity. Unlike a SWOT grid or a roadmap, it shows movement: where the competitive terrain is actually drifting.

Quick answer: Wardley mapping plots your value chain (what a user need depends on, top to bottom) against evolution (how commoditized each dependency already is, left to right). Read together, the two axes show which parts of your stack are still worth differentiating on, and which have quietly become utilities you should just be buying.

Most strategy conversations skip this step entirely. A team runs a SWOT workshop, argues about which features to prioritize, or inherits last year's roadmap with a few boxes moved — without ever agreeing on the shape of the terrain underneath. A Wardley map forces that agreement first, then argues about the moves.

What a Wardley Map Actually Shows (And Why Most Strategy Skips It)

A Wardley map is a situational-awareness tool, not a plan: it visualizes your value chain and how commoditized each part of it already is, so build-versus-buy decisions rest on the landscape instead of opinion. Simon Wardley developed the technique after watching good strategic instincts fail for lack of a shared picture of the terrain everyone was standing on.

The framing borrows from Sun Tzu, who argued that good strategy requires situational awareness before it requires cleverness: know the purpose, the landscape, the climate, and only then choose your moves.

Know the terrain before you choose the battle. That's situational awareness in product strategy — and it's the entire premise a Wardley map is built to serve.

Wardley has recounted, in his freely published book Wardley Maps and in numerous conference talks, that the idea took shape while he was running Fotango, a UK software company where his team built one of the earliest cloud platforms, a system called Zimki. He knew commodity computing was coming but struggled to explain why to a board with no shared visual language for "this layer is about to become a utility." Mapping was his answer to that failure.

Most product strategy skips straight to moves. Wardley mapping for product managers is, at its core, the discipline of drawing the landscape first. A map answers three questions a roadmap simply can't:

1. Where does every part of my product sit right now, between novel and utility?
2. Which of those parts are moving, and how fast?
3. Given that movement, where should my differentiation effort go next — not where did it go last year?

That last question is the one multi-quarter planning usually gets wrong. For how mapping sits alongside the rest of a strategy practice, see our complete guide to advanced product strategy.

The Value Chain Axis: From User Need to Invisible Infrastructure

The vertical axis of a Wardley map is visibility. The user's need sits at the top; every layer beneath it is something that need depends on, all the way down to raw infrastructure. You build the chain by repeatedly asking one question: what does this need, in order to exist?

Wardley's own teaching materials often start with something deliberately unglamorous — an online shop that needs a website, which needs a platform to run on, which needs computing power, which needs power itself. Nobody is entertained by that chain. That's the point: the value chain is about dependency, not drama.

The only relationship that belongs on this axis is "needed by." Not "created by." Not "reports to."

This trips up more experienced product people than you'd expect, because two other diagrams look deceptively similar:

• An org chart shows who manages whom — a hierarchy of people, not a hierarchy of need.
• A user journey map shows the sequence of steps a user takes — a timeline, not a dependency stack.

A Wardley map is neither. It's closer to a bill-of-materials for a need, and it starts with the user, not with your product's feature list. Get the anchor wrong — start from your architecture instead of from what the user actually needs — and every position you plot after that measures the wrong thing.

The Evolution Axis: Genesis, Custom-Built, Product, Commodity

The horizontal axis measures evolution: how certain, well-understood, and widely available a component is. Every component sits somewhere on a path through four stages — genesis, custom-built, product (plus rental), and commodity (plus utility) — and its position is driven by ubiquity and certainty, not by the calendar.

Two rules govern movement on this axis:

1. Components only move right. Evolution runs toward commodity and never back toward genesis — Wardley describes it as a one-way door.
2. Competition and demand drive the movement, not your roadmap. A component evolves because many independent actors are building the same thing under commercial pressure, not because you decided to prioritize it.

It's worth distinguishing this from a lookalike framework. Gartner's Hype Cycle also tracks maturity, but it's driven by market expectation on a roughly fixed timeline. Wardley map value chain evolution has no fixed duration — a component can sit in genesis for over a decade, then commoditize within two or three years once a dominant utility provider appears, which is close to what happened to compute once AWS made EC2 widely available.

Clayton Christensen's Innovator's Dilemma explains why incumbents so often miss that shift: they keep investing in sustaining improvements to something the market has already started to commoditize, because that's what their existing customers and resourcing process reward. A Wardley map doesn't replace that theory — it gives you the picture that would have let you see the shift coming, instead of explaining it afterward.

A Concrete Map: Fintech Onboarding, Component by Component

Plot a real value chain and the two axes combine into one picture. Take a fintech onboarding flow: a user need at the top ("open an account and move money in under five minutes"), a chain of dependencies underneath it, and each dependency positioned by how commoditized it already is.

Drawn on real axes, this map has a shape: a small cluster of genesis and custom activity at the very top, thinning into a long, dense tail of product-and-commodity components underneath it. That shape is the strategic message — most of this value chain is no longer a place to compete on engineering effort.

Two decisions fall out of it immediately:

• Stop differentiating on identity verification and AML screening. Buy them as commodity services, and put the reclaimed engineering time into the onboarding experience itself, which is where the map says novelty still lives.
• Watch the core ledger closely. It's mid-drift. The build-versus-rent call that made sense three years ago is not automatically the right call this year — and increasingly, the risk-scoring layer feeding it is AI-driven, which raises its own model-governance questions worth planning for early (our guide to responsible AI practice covers that terrain in more depth).

If you want more reps at reading a company's structure this way before you map your own product, our teardown case studies guide walks through this kind of component-level breakdown applied to real, public products.

The Climatic Pattern That Rewrites Your Roadmap: Everything Evolves

Wardley calls the forces you can't control, only plan around, climate. The single most important climatic pattern is that everything evolves — every component drifts toward commodity as competition and demand increase, whether you plan for it or not. A multi-quarter roadmap that ignores this is planning against a board that will have already moved by the time it ships.

Climate, in Wardley's vocabulary, means the rules of the environment you don't get a vote on — only a choice of how well you anticipate them.

Why Components Drift, and Why Teams Fight It Anyway

Evolution rarely stalls because a team failed to notice it. It stalls because of inertia: the team that built a custom KYC engine when it was genuinely novel now has headcount, pride, and a promotion history riding on it. Buying the commodity alternative feels like admitting the work no longer matters, even after the market has clearly moved on.

This is the same resource-allocation dynamic Christensen describes in incumbents who keep over-serving existing demand instead of responding to a disruptive, commoditizing shift. A map doesn't remove the politics. It does make the drift undeniable, which is usually the harder half of the argument.

A few other climatic patterns worth knowing, drawn from Wardley's own catalogue of roughly thirty:

• Efficiency enables innovation. Commoditizing the boring, well-understood layers frees capital and attention for genesis-stage bets further up the chain.
• Higher-order systems spawn new genesis activity. A new utility — commodity cloud compute, for instance — creates the conditions for an entirely new wave of genesis-stage products built on top of it.
• No component evolves in isolation. Identity verification turning into an API changes the economics of everything built above it, whether or not anyone updates the roadmap to reflect that.

Turning Drift Into Quarterly Planning Decisions

The habit: re-plot the map every planning cycle, and ask what moved since the last one. Treat "we're still building this ourselves" as a decision to re-justify, not a default that survives on inertia.

This is also where the map should talk to your OKR cycle. An objective to "own our KYC decisioning" made sense when that layer was custom-built. The same objective, two evolution-stages later, is a resourcing mistake your quarterly review should catch — our guide to advanced OKRs covers how to build that kind of re-justification directly into the review cadence.

None of this changes how a single sprint runs. The map operates one altitude above delivery cadence: it decides what's worth building at all, while your agile delivery practice still decides how the work gets done once that call is made.

Where the Map Fits in Your Strategy Stack — and Where Prodinja Comes In

A Wardley map is the situational layer of a strategy stack: it shows where things stand and which way they're moving. Vision explains why it matters, OKRs track whether a specific bet is working, and delivery handles how the work gets built. Skipping the map is the most common gap of the four.

Teams routinely write a compelling vision and hold rigorous OKR reviews anchored to a landscape nobody on the team actually checked.

Getting the top row right matters as much as getting the rest of the stack right — a vision statement is only as good as the terrain it's describing, which is the other half of the equation our guide to writing a product vision people actually repeat covers.

From a Static Map to an Explorable System

A Wardley map is deliberately flat, which is exactly what makes it fast to draw and easy to argue over on a whiteboard. But a chain like the fintech one above is really a live system: the KYC layer feeds risk scores into the ledger, the ledger feeds compliance reporting, and compliance reporting constrains what the onboarding experience is allowed to promise a user in the first place.

Once the map is plotted, it's worth diagramming what those dependencies actually do to each other. That's the gap Prodinja's Systems Engineering canvas is built for.

After you've sketched the value chain and evolution positions, the canvas lets you carry that same picture further:

• Lay the components out as a dependency graph, not just a flat two-axis sketch.
• Trace the feedback loops running between them — how a ledger change echoes back into compliance reporting, say.
• See where a change to one node, like swapping a custom KYC engine for a commodity API, ripples through the rest of the system.

It turns a snapshot of the terrain into a model you can keep exploring as that terrain moves.

None of this replaces judgment. A map only shows you the ground. What you build on the high ground is still a call only you can make, one planning cycle at a time.

Key Takeaways

• A Wardley map plots two independent things — the value chain (visibility, top to bottom) and evolution (genesis to commodity, left to right) — and it's the combination a SWOT grid or a roadmap can't show you.
• Always anchor the map on a real user need, not your feature list or your org chart; the only valid vertical relationship is "needed by."
• Evolution moves in one direction, driven by supply, demand, and competition — not by your roadmap and not by the calendar, which is what separates it from tools like the Gartner Hype Cycle.
• In the fintech onboarding example, most of the value chain — identity verification, AML screening, ledger infrastructure, compute, payment rails — is already product or commodity; the genuinely novel layer left is the onboarding experience itself.
• Inertia, not ignorance, is usually why teams keep investing engineering effort in components the market already commoditized.
• Re-plot the map every planning cycle and let it inform your OKRs and your build-versus-buy calls, not just an annual strategy offsite.
• The map tells you where to look; Prodinja's Systems Engineering canvas can help you diagram what those dependencies actually do to each other once you start pulling on one thread.