The question the other frameworks cannot answer
A structural analysis tells you what a category permits today. A positioning decision tells you how to be understood today. A strategic choice commits capital against today's conditions.
None of them tell you what is about to stop being an advantage.
That gap is why Simon Wardley built mapping. He created the technique in 2005 while CEO of Fotango, having developed the underlying evolutionary framing the year before, and his stated frustration was that tools like SWOT and Five Forces did not show how things change over time. He later ran strategy at Canonical between 2008 and 2010, taking Ubuntu into cloud, and co-authored the Better for Less paper on UK government IT in 2010.
The framework's contribution is a single idea: components in a business move in a predictable direction, and knowing where each one sits on that journey tells you whether to build it, buy it, or leave it alone.
How a map is built
Five steps. The discipline is in the order.
1. Anchor on the user need. Every map starts with what the user is trying to accomplish. Not the product, not the feature. The need.
2. Draw the value chain. List every component required to meet that need, arranged vertically by visibility to the user. User-facing components sit at the top. The infrastructure they depend on sits below. Draw the dependencies as lines.
3. Place each component on the evolution axis. Horizontally, from left to right, through four stages:
Genesis. Novel and uncertain. Nobody has done this before, and it may not work.
Custom-built. Built specifically, by experts, one instance at a time.
Product and rental. Productised, standardised enough to sell to many, differentiated by features.
Commodity and utility. Standardised, widely available, frequently pay-per-use. Nobody differentiates here.
4. Check the dependencies. A component cannot be more evolved than what it depends on. If the map shows that, something is placed wrong.
5. Draw the movement. Everything drifts rightward over time. The question is how fast, and what that implies for anything sitting on top of it.
The output is a picture with a direction of travel, not a snapshot.
The evolution axis is the whole framework
The vertical axis is a value chain, which most teams could produce without a framework. The horizontal axis is where the value is.
Everything moves right. Today's genesis becomes tomorrow's custom build, then a product, then a utility nobody thinks about. Payment processing, hosting, authentication, mapping, transcription — all sat in custom-built territory within recent memory and now sit at commodity.
Three practical consequences.
Build left, buy right. Investing engineering effort in something drifting toward commodity is spending to reach parity. Investing in genesis or custom-built components is where differentiation is available, and where it is also riskiest.
The thing you built your advantage on may be commoditising underneath you. This is the failure the map is best at catching. A business differentiated on a capability that is becoming a purchasable utility is losing its position without anything visible going wrong.
Timing beats selection. Moving into a space too early means funding market education. Too late means competing on price against incumbents with scale. The map is one of very few tools that makes the timing question explicit.
The evidence, stated honestly
Wardley Mapping occupies an unusual position in this series.
It is a documented practitioner method, but with a difference from the others. Wardley published it openly under a Creative Commons licence and has never sold it as a proprietary methodology. There is no vendor track-record study, because there is no vendor — which removes the vendor-claim problem entirely.
It also means there is very little independent evidence of any kind. There is no controlled research on whether teams using maps make better decisions than teams that do not. The Wikipedia entry itself carries citation warnings for relying on primary sources. Adoption in government and enterprise technology is real and documented, but adoption is not validation.
The honest position: the underlying claim — that components commoditise in a consistent direction, and that treating a commoditising component as a differentiator is a mistake — is observably true and easy to test against your own history. The method's specific apparatus has no evidence base beyond practitioner report.
Use it because the core insight holds and the exercise surfaces disagreement. Do not cite it as validated.
What it is genuinely good for
Build versus buy, decided on evidence. The most common practical use. A component at commodity should be bought; effort spent building it produces no advantage. A component at genesis cannot be bought, because it does not exist as a product yet.
Spotting inertia. Organisations resist letting go of things they built. A map shows a custom-built component sitting next to available commodity alternatives, which converts a political argument into a positional one.
Anticipating what competitors will do. Competitors face the same evolution. Components drifting toward utility will be adopted by everyone, which means any advantage there has an expiry date that can be estimated.
Sequencing a roadmap. Two initiatives that both look valuable may have very different timing. The map indicates which is ready and which is waiting on a dependency that has not evolved far enough yet.
Where it strains
Placement is subjective. Two people map the same business differently, particularly on the evolution axis. Wardley's response is that the disagreement is the useful part — the conversation about why a component sits where it does is the exercise. That is a fair answer, but it means the map is not an objective artefact.
Teams systematically overrate their own novelty. Almost every business maps its own core components further left than the market would. Recognising this bias is most of the discipline.
The learning curve is real. Wardley has said it takes roughly three months to learn to map, and he teaches it to groups over three to four weeks of half-day sessions. This is not a framework a leadership team applies well in a single afternoon.
It suits component-heavy businesses best. Businesses built from many technical or operational components map cleanly. A single-product business with a simple supply chain may find the exercise produces little the team did not already know.
It answers what and when, not whether. The map does not say whether the market is worth serving or whether the economics work. Those are different questions.
Diagnostic: is the map doing work?
Six tests.
The map is anchored on a user need, not on the product or the org chart.
Dependencies are drawn, and no component sits more evolved than what it depends on.
At least one component is placed further right than the team is comfortable with.
A build-versus-buy decision changed because of the map.
Movement is marked — the map shows where components are heading, not only where they sit.
Something the business currently treats as differentiating has been identified as commoditising.
Test six is the one that justifies the exercise. A map that confirms everything the team already believed was drawn to be agreeable.
What this produces
A view of which advantages have a shelf life.
That is the specific contribution. Structural analysis bounds what a category permits. Customer research establishes what is underserved. The strategic choice commits. Mapping adds the dimension none of those carry — that the ground is moving, and at different speeds under different parts of the business.
For a leadership team deciding what to build with limited capital, the most expensive available mistake is investing heavily in something that is about to become purchasable. A map makes that visible before the invoice does.
Frequently asked questions
What is a Wardley Map?
A visual representation of the components required to meet a user need, plotted on two axes: visibility to the user, and stage of evolution from genesis through custom-built and product to commodity. Dependencies are drawn explicitly, and components are expected to move rightward over time.
How is Wardley Mapping different from Five Forces?
Five Forces describes the structural conditions of an industry at a point in time. Wardley Mapping describes movement — which components are commoditising and how that changes what is defensible. Wardley created the technique specifically because existing tools did not represent change over time.
How long does it take to learn?
Wardley has indicated roughly three months to become competent, and teaches it over three to four weeks of half-day sessions. A first useful map can be drawn in a day or two, but reading maps well takes practice.
Is Wardley Mapping validated by research?
No. It is published openly rather than sold, so there is no vendor claim to discount, but there is also no independent study of whether it improves decisions. Its core premise about commoditisation is observable and testable against a business's own history.
What is the most common mistake?
Placing your own components too far left. Teams consistently rate their work as more novel than the market considers it, which produces maps that justify building things that could be bought.
Does it work for non-technology businesses?
It works best where a business is assembled from many distinguishable components. Consumer and services businesses can map operational and supply components usefully. A simple single-product business may find the exercise produces limited new information.
Where does mapping sit in the Define sequence?
Alongside structural analysis, before the strategic choice. Structure establishes what the category permits; mapping establishes what is about to change. Together they bound the choice in both space and time.
Sources
Wardley, S., Bits or Pieces? — the mapping technique, created at Fotango in 2005, with the evolutionary framing developed in 2004; published openly under Creative Commons
Wardley, S., strategy work at Canonical, 2008 to 2010; co-author, Better for Less (2010), on UK government IT
Published interviews on the learning curve and teaching format for mapping
Structure your next phase
Zerologic works with leadership teams on build-versus-buy and sequencing decisions — establishing what is worth building before capital commits to it.
Talk to us: partners@zerologic.io · zerologic.io
