Wardley Maps: Situational Awareness for Product Leaders in the AI Era

This is one of RoadmapOne ’s articles on Strategy for Product Leaders .

A Wardley Map is a visual representation of a business’s value chain, with user needs at the top and components plotted on an evolution axis from genesis to custom-built to product to commodity. Developed by Simon Wardley in the mid-2000s, the technique produces situational awareness — it makes the terrain of the strategic decision visible — so that choices about where to invest, what to pioneer, and what to industrialise can be made against a shared map rather than a shared assumption.

Most strategy conversations start from the wrong place. A leadership team gathers, someone produces a flipchart, and the discussion jumps straight to what should we do?—without first establishing where are we? In a war, that would be unthinkable. You would want the map first. Yet in business, the equivalent skill—situational awareness—is so under-practised that most organisations don’t realise it’s the thing they’re missing.

Wardley Maps are the map that strategy has been missing. Developed by Simon Wardley in the mid-2000s during his time running Canonical’s Ubuntu cloud computing work, the technique forces you to draw your business as a visible landscape: user needs at the top, value-chain components cascading down, and an evolution axis from left to right charting how commoditised each component is. Once drawn, the map reveals things that were invisible before—which components are durable moats, which are destined to commoditise, which will be eaten by a substitute, which need to be pioneered and which industrialised. The map doesn’t make the strategic choice for you. It makes the terrain of the choice visible.

The reason Wardley Maps matter more in 2026 than they did in 2016 is that the evolution axis now moves in months rather than years. AI has accelerated the progression from custom to commodity for enormous categories of capability—natural language interfaces, image generation, recommendation systems, code generation, document summarisation. A map drawn two years ago is already out of date. The discipline of mapping is no longer an annual exercise; it is closer to telemetry. The terrain moves, and the squads move with it.

Sign up (free) to map your value chain against squad allocation

What Is a Wardley Map?

A Wardley Map has two axes and a value chain:

• Vertical axis: visibility to the user. User needs sit at the top. Each component below a user need is what’s required to deliver it. The chain cascades downward through increasingly invisible infrastructure.
• Horizontal axis: evolution. Each component is plotted on one of four stages of evolution:
  1. Genesis — the component is novel, experimental, rare, and works inconsistently. Nobody has a standard.
  2. Custom-built — the component is being built bespoke by experts, and only experts can build it. Methods and outputs differ.
  3. Product (+ rental) — the component exists as a product or service you can buy. Methods converge; features become comparable.
  4. Commodity (+ utility) — the component is a utility. You don’t think about how it works, you just consume it. Supplier choice is largely a pricing question.
• Lines between components — the dependencies, showing which higher-up need requires which lower-down capability.

A map of a coffee shop might put “customer wants a cup of tea” at the top. Below that: cup, tea leaves, hot water, kettle, power. The kettle sits as a product—you buy it, you don’t build one. Power sits as a commodity—you consume it from the grid, you don’t generate it. The novel top-level experience (some twee new tea service, say) sits as genesis. Over time, everything drifts rightward. The experience becomes a product. Eventually a commodity. The map makes this drift visible.

That’s the entire technique, and it is deceptively powerful. Once you’ve drawn the map, strategic questions become concrete: which component is currently mismatched with its evolution stage? (Are we custom-building something that has moved to product?) Where are we investing against the grain? (Are we pioneering something that’s already a commodity?) What is the incoming substitute we can’t see yet? (Is a new genesis component about to leapfrog our current product-stage position?)

Why Situational Awareness Is the Underrated Skill

Most strategy fails at diagnosis, not at action. Product teams are usually reasonably good at executing against a chosen direction. What they are bad at is noticing that the direction no longer matches the terrain. The landscape moves; the strategy doesn’t; the team keeps shipping against a map that no longer exists.

Wardley Maps address this by making the terrain the explicit object of analysis. You can argue about what to do all day; what you can’t argue with is a map that shows a critical component drifting from product into commodity. When the component of your value chain that used to differentiate you is now something you can buy from four vendors at a price that drops every quarter, the map tells you so—whether you want to hear it or not.

This is also why Wardley himself insists the map is a conversation, not a document. The map has no value sitting on a server. Its value is in the debate that happens when two people disagree about where a component sits on the evolution axis, or whether one component really depends on another, or whether a genesis-stage novelty is actually a substitute for a mature product the team is defending. The map surfaces those disagreements. The conversation is the work.

How to Read a Wardley Map: The Coffee Shop Example

A useful way to internalise the technique is Wardley’s canonical cup-of-tea example, simplified:

User need:               Cup of tea
                              │
                              ▼
Components:        Tea ── Hot water ── Cup
                   │           │         │
                   └── Kettle ─┘         │
                        │                │
                        └── Electricity ─┘

Plot this on the evolution axis:

• Tea — product (you buy branded tea; commodity if we’re honest about supermarket own-brand)
• Cup — commodity (generic ceramic, you don’t specify)
• Kettle — product (many brands, comparable features)
• Hot water — custom-built at the small scale but a commodity at the coffee-shop scale (they have plumbed systems)
• Electricity — commodity (grid supply)

The map reveals where the differentiation lives. Not in the electricity. Not in the cup. Possibly in the tea (if you’re a specialist), or—more plausibly—in the user experience around the tea (the novelty, the presentation, the ritual) which sits higher up in the map and is in genesis or custom. A coffee shop that invests in differentiating its electricity is investing against the grain. A coffee shop that invests in the user-experience layer—which is in genesis—may be pioneering durable differentiation.

Scale this up to a SaaS product, and the same logic applies. Authentication is a commodity now (plug in Auth0, Clerk, or AWS Cognito). Database hosting is a commodity. Standard UI components are commodities. What’s not a commodity—yet—is the specific workflow the product enables for its specific segment. That’s where differentiation lives. A team that’s still building its own auth system is investing against the grain. A team that’s investing all its capacity in its workflow layer is investing with the grain. The map makes the difference explicit.

Pioneers, Settlers, and Town Planners

Wardley’s most operationally useful contribution for product leaders is the PST framing—the three organisational archetypes required to operate across the evolution axis:

• Pioneers build in genesis and early-custom territory. They experiment, prototype, and tolerate high failure rates. Their work is unpredictable, novel, and often throwaway. You need them to find the next category. You cannot measure them on predictability because predictability isn’t what they’re for.
• Settlers take what pioneers have proven and productise it. They turn the chaotic prototype into a repeatable product. They do feature development, customer onboarding, and pattern extraction. They thrive when there’s enough ambiguity to design around but enough clarity to ship against.
• Town Planners industrialise products into commodities and utilities. They optimise for efficiency, reliability, scale, and cost. They thrive on repeatability and operational excellence. They are terrible at ambiguity and excellent at everything downstream of it.

The critical insight: these are different people doing different work, and one does not substitute for another. Pioneers shipped as settlers produce unreliable products nobody trusts. Settlers given pioneer work produce polished versions of the wrong thing. Town planners forced to pioneer produce beautifully-operationalised implementations of something nobody wants. A mature product organisation has all three types, deployed against components in the appropriate evolution stage.

This is where the framework connects to capacity planning . A squad building toward genesis-stage components should be staffed with Pioneers and measured on pattern discovery, not velocity. A squad productising a proven capability should be staffed with Settlers and measured on adoption and retention. A squad running a commoditised utility should be staffed with Town Planners and measured on efficiency, reliability, and cost. The same squad should not be doing all three types of work at once—that’s the anti-pattern Wardley spends a career warning about.

Sign up (free) to allocate squads by Pioneer, Settler, Town Planner

The AI-Era Reframe: Evolution Moves in Months

In 2016, the evolution axis was measured in years. A component moving from custom-built to product might take three to five years. From product to commodity, another three to five.

In 2026, the same progression happens in a fraction of the time. AI-assisted engineering has collapsed the time-to-product for enormous categories:

• Natural language interfaces went from custom to product in under three years.
• Image generation went from genesis to commodity in four years.
• Code generation went from genesis to product in eighteen months.
• Document summarisation, entity extraction, recommendations—all commoditised rapidly.

The implication: a Wardley Map drawn in 2024 is already partially obsolete. Components that were custom two years ago are now product or commodity. Teams that are still building custom versions of capabilities that have commoditised are burning capacity against the grain. The squad that three years ago was pioneering their document-summarisation capability is now running a commoditised utility—the appropriate staffing, measurement, and capacity allocation have all changed, and most organisations haven’t noticed.

The practical consequence is that mapping cadence has to accelerate. An annual offsite-style Wardley-mapping exercise produces a snapshot that’s stale before the ink dries. The discipline needs to be continuous—a quarterly re-map at minimum, a rolling conversation among senior engineering and product leaders about which components have moved, which substitutes are emerging, and where the team is still investing as if the map hadn’t changed. Treat mapping as telemetry, not as an annual artefact.

Wardley Maps, Playing to Win, and 7 Powers

Three strategy frameworks, three complementary questions.

• Playing to Win asks: where will we play and how will we win? The map of choices.
• 7 Powers asks: which specific structural Power will protect our position from competitive copy? The taxonomy of durable moats.
• Wardley Maps ask: what does the terrain look like, and where is it moving? The situational awareness layer.

A product leader who uses all three in combination has something like a complete strategic toolkit. Wardley Maps show the terrain. Playing to Win forces coherent choices about where in that terrain to play and how to win. 7 Powers stress-tests the How-to-Win by asking whether it rests on a durable Power. Rumelt’s kernel forces the team to name the specific challenge each choice engages. The frameworks interlock. None substitutes for the others.

Mapping Connects to the Roadmap

The Wardley Map is strategy at the terrain level. The roadmap grid in RoadmapOne is strategy at the allocation level. The connection point is PST:

• Pioneer squads operate on components in genesis or early custom. They are Transform work in RGT terms . Their OKRs should measure learning and pattern discovery, not feature throughput.
• Settler squads operate on components in product stage. They are Grow work. Their OKRs measure adoption, retention, and competitive positioning.
• Town Planner squads operate on components in commodity stage. They are Run work. Their OKRs measure reliability, cost, and efficiency.

When every squad in the capacity grid is tagged against the evolution stage of the component it works on, a leadership view becomes possible: is our capacity allocated correctly across the PST types given the current map? A product team with 80% of its capacity on Town Planner work and 5% on Pioneer work is running an organisation optimised for the past. A team with 80% Pioneer and 5% Town Planner is an organisation that cannot keep the lights on. Neither is healthy. The right mix is determined by the map and by the organisation’s strategic phase (Three Horizons is the natural temporal overlay here).

The objective tagging framework in our tagging directory is the mechanism for making this visible inside the roadmap. Tag each Objective by evolution stage. Tag each squad by PST type. The analytic question are we appropriately resourcing the right kind of work against the current terrain? becomes answerable without a multi-week audit.

Common Mapping Mistakes

Mapping as a one-off. A Wardley Map’s value is in the cadence. Organisations that map once and treat the map as strategy produce a snapshot of a moving target. Re-map quarterly; run it as telemetry, not as a document.

Letting the map replace the conversation. The map has no value without the debate about where components sit. If the map is produced by one person in isolation, it represents one person’s view of the terrain, which isn’t useful. The team has to argue about it. The argument is the work.

Treating genesis as better than commodity. Genesis is not better than commodity. A commodity is a commodity precisely because it has been industrialised—that’s a good outcome, not a failure. The map tells you where each component is, not which is superior. The strategic question is whether the organisation is investing in the right stage, not whether it should move everything to genesis.

Ignoring substitutes. The map shows your current value chain. It does not automatically show substitute value chains that could render entire components obsolete. Add a substitute analysis: which component, if replaced by a genesis-stage alternative, would eat the entire chain above it? This is where incumbents get killed—they defend products that a substitute has made irrelevant.

Over-mapping. A map with 80 components is a spreadsheet, not a map. Keep it to the strategically meaningful components—usually 15-25—at a level of granularity where differentiation or substitution actually matters. Finer-grained mapping is for engineering, not strategy.

FAQ

What is Wardley Mapping used for?

Wardley mapping is used to produce situational awareness — a shared visual representation of where the organisation’s value chain currently sits and where each component is evolving to. It’s used to identify which components are drifting from product to commodity (and should be industrialised), which are genesis-stage and need pioneering, where substitutes might emerge, and where capacity is being invested against the grain. The map is a conversation tool; its value is in the debate it provokes about the evolving terrain.

How do you make a Wardley Map?

Start with user needs at the top. Below each need, list the components required to deliver it and the dependencies between them. Then position each component on the evolution axis (genesis → custom → product → commodity), based on how standardised and commoditised it currently is. Iterate with a second person — the argument about where each component sits is the whole point. A good first map takes 60-90 minutes; useful maps emerge through two or three iterations, not one.

What is the Wardley Map doctrine?

Wardley’s “doctrine” is a set of universal principles applicable regardless of the specific map — practices every organisation should adopt. Examples include focus on user needs, be transparent, remove bias and duplication, use appropriate methods per evolution stage (agile for genesis, lean for product, Six Sigma for commodity), and manage inertia. Doctrine is distinct from strategy in Wardley’s framing: doctrine is universal, strategy is context-specific.

What is a Wardley Map?

A Wardley Map is a visual representation of a business’s value chain plotted against an evolution axis. User needs sit at the top, value-chain components cascade downward, and each component is positioned on the horizontal axis according to its evolution stage: genesis (novel), custom-built (bespoke), product (buyable), or commodity (utility). The map produces situational awareness — a view of where the landscape is and where it’s moving — that most strategy frameworks assume but don’t produce.

What are the four stages of Wardley Maps?

The four evolution stages are: (1) Genesis — novel, experimental, rare; (2) Custom-built — bespoke, expert-dependent; (3) Product (or rental) — comparable products available to buy; (4) Commodity (or utility) — a standard utility like electricity. Every component drifts rightward over time. The map’s strategic value comes from seeing where each component currently sits and anticipating where it will move next.

What is the Pioneers, Settlers, Town Planners model?

Pioneers build novel components in genesis and early custom stages — they experiment and tolerate failure. Settlers take what pioneers have proven and productise it for broader use. Town Planners industrialise products into commodities and utilities, optimising for efficiency and scale. The three archetypes represent different skills and temperaments, and mature organisations deploy all three against components in the appropriate stage of evolution. The framing maps cleanly to squad-level roadmap allocation.

How often should I redraw a Wardley Map?

Historically annually — but in the AI era, quarterly at minimum. Evolution has accelerated sharply across software categories: capabilities that took three-to-five years to go from custom to commodity now take twelve-to-eighteen months. A map drawn eighteen months ago is already partially out of date. Treat mapping as continuous telemetry, not as an annual offsite artefact.

How is a Wardley Map different from other strategy frameworks?

Most strategy frameworks (Playing to Win , 7 Powers , Porter’s Five Forces ) assume you already have situational awareness and then ask what choices to make. Wardley Maps produce the situational awareness itself. Use the map first to establish where you are; then use the choice-framework of your preference to decide what to do about it. They are complementary, not alternatives.

Can I use Wardley Maps for product management?

Yes — arguably more usefully than for any other discipline. Plot your product’s value chain, identify which components are genesis/custom/product/commodity, stage appropriate Pioneer/Settler/Town Planner squads against each, and connect the allocation to the capacity grid in RoadmapOne . The map surfaces where the team is investing against the grain — spending Pioneers on commoditised components, or Town Planners on novel ones — and drives a corrective capacity conversation.

Conclusion

Wardley Maps are the map strategy has been missing, and the reason they matter more in 2026 than they did in 2016 is that the terrain now moves faster than the mapping cadence most organisations are used to. AI has accelerated every component’s progression toward commodity. Organisations still treating mapping as an annual exercise are running their strategy off a snapshot that’s already obsolete. The discipline has to become continuous.

For product leaders, the map connects directly to squad allocation through the Pioneer/Settler/Town Planner framing. Tag each squad by PST type. Tag each component on the map by evolution stage. Review the allocation quarterly and ask the honest question: is our capacity allocated against the current terrain, or against the terrain we wish we still had? That conversation, run against a coherent strategic cascade and a diagnostic kernel , is what mature product leadership looks like. The map doesn’t make the decision. The map makes the decision possible.

Sign up (free) to tag squads by evolution and PST type