Part one: RUN (Combine)

The central argument of the WEF report is that:

Here, the WEF is describing the Componentisation Effect [2] — the idea that complex systems run on hierarchies of sub-components. We see this in every business value chain. Components (controllable assets we provide or consume) that were once new to the world, evolved to become the reliable, efficient platforms on which new, higher-order systems are built. Think electricity, which was once a thing of wonder, which begat computers, which begat LLMs, which are begetting AI agents today.

The WEF uses the evolution axis from Wardley Mapping to identify the components stable enough to build the future on. These technologies have evolved from the novel and uncertain to the widespread and reliable, moving from Genesis through Custom-built and Product to Commodity.

The strategic implication of this is clear: build new sources of value on top of evolved components, rather than carrying the cost and uncertainty of continually reinventing the wheel.

Yet, the WEF mistakenly calls the ‘evolution axis’ in Wardley Mapping a ‘measurement of maturity’. Maturity refers to a product’s lifecycle: how established, feature-complete or ‘finished’ a product is. Evolution is concerned with supply and demand competition — how this drives components from novel and uncertain to widespread and reliable. It measures how markets understand an activity.

Confusing ‘evolution’ and ‘maturity’ leads to muddled strategic thinking, such as McKinsey, who, in 2009, claimed that cloud computing was an immature product not yet viable for large enterprises.[3] Investments in cloud, they argued, were following a “familiar IT hype pattern” diverting “attention from technologies that can actually deliver sizeable benefits”.[4] Of course, they were wrong.

Anyone with a Wardley Map of the landscape back then would have seen a very different picture — one showing ‘cloud’ as the next evolutionary stage of a widely understood activity (computing).

With EC2, Amazon offered CFOs a way to switch fixed computing costs to variable costs, paying only for what they used. CFOs didn’t need to understand the technology to see the value. CIOs were also relieved of their biggest headache: investing in spare capacity to deal with sudden surges in demand.

Decision-makers understood they could run cloud as a reliable, efficient sub-component in their value chain and redirect resources to build new sources of value on top of it (the componentisation effect). And those new sources of value would eventually disrupt entire industries (e.g. mobile-only banks, ride-hailing apps, on-demand streaming). Evolution and maturity measure different things.

The WEF also advises organisations to get a common language — “both technical and operational” — to reduce friction across stakeholders as they try to answer three essential questions:

1. Which underlying systems should we build on top of?
2. Which new value-creating activities should we develop?
3. How do we get these different components working together?

Despite Wardley Mapping being a shared visual language, the WEF report fails to include a single map to guide readers in answering these questions. Let’s address this gap with a map of a real case:

Our client, an investment company, had a problem: one of their portfolio companies (a tech startup) was burning through capital and would soon be out of runway.

With a small team, we took an hour to map it out. On the (anonymised) Wardley Map below we’ve added a value chain (vertical axis) showing components visible to end users (at the top) and those less visible (towards the bottom). Can you see the startup's problem?

They were custom-building their entire technology stack! It makes sense to build components higher up the value chain, since these are visible to end users and matter to them. But it makes less sense to custom-build components lower down the value chain that users can’t see and won’t care about.

Re-inventing the wheel is a widespread problem in innovative organisations. What looks good on a CV (“I created an alternative to a market-leading technology”) doesn’t look good on the organisation’s bottom line as it carries all the cost of development, but earns no revenue from it.

With a map, problems — and solutions — become clearer.

The CEO announced that any technology that could be sourced using commercially available products or services would be. Anyone who thought they should keep custom-building something that didn't differentiate them would have to provide a compelling reason (no-one did).

Engineering talent was then redirected to developing the company’s solution (top left), or invited to leave (some did). This extended the startup’s runway, while refocusing efforts on the product that differentiated them, accelerating its evolution in the market.

Mapping out the problem helped the team see which methods they should use where (see fig.4): outsourcing commoditised components on the right, buying commercially off the shelf products in the middle, and only building the novel themselves on the left.

An existential problem that had plagued the company for months was resolved in hours.

This is how Wardley Mapping quickly helps decision-makers answer the first of our three essential questions: which underlying systems should we build on top of?

We run our value chains on commoditised components that are impossible to differentiate on and, rather than competing with providers, we use their products to build higher-order systems on top of them — new value-creating activities that disrupt the status quo.


We explore next how to choose what to disrupt.