An introduction to Wardley 'Value Chain' Mapping

This is about my journey, from a newly-minted yet confused CEO caught like a rabbit staring helpless into the oncoming headlights of change - to being voted one of the most influential people in IT within the UK. It took me a decade to first develop the techniques that I'm going to describe and a further 10 years to gain confidence with them through practice.

[See also: Simon Wardley's 100-day Corporate get fit plan]

Every journey begins with a step, and in our case there were several. I'll use an example throughout, and in this first foray I'm going to map a TV company that is part of a larger media conglomerate. I'll be using an early draft, which took about two hours to develop, including the strategic play from a base understanding of nothing about the TV industry. The reason I've selected this example is because while it explains the process of mapping, anything of commercial value has long since left it and been exploited or discarded.

Step 1. Focus on user needs

Critical to mapping is to first focus on what the user actually wants. There are various techniques for this from writing the press release to creating a user journey. In the case of the TV company, the users wanted to be entertained. There are two routes to satisfying this need; either through a branded online service that delivers the company's programmes or through a content aggregator such as Netflix where the output from many TV companies is combined. Figure 1 below image shows the users' needs.

Step 2. Create the value chain

Once you've determined the high level needs, the next step is to flesh this out with the components required to meet those needs. You do this by creating a chain of needs. I call this a 'value chain' because by meeting the needs of others, you hope to create value. At the top of any value chain should be the visible user need you are trying to serve and below this are the increasingly invisible (to the user) components that are necessary to serve those needs.

Figure 2 below provides a value chain for the TV company. In this diagram both branded and aggregator sites need content. That content needs a distribution mechanism (such as traditional media) but it also has to be created, which requires artistic direction. Naturally, artistic direction needs a creative studio to make the show but it also needs market analysis; for example, what sort of programs do people want to watch? And so the chain continues down to components such as compute and power.

Step 3. Create a map

Value chains on their own are practically useless for understanding an environment because they lack any form of context on how it is changing. If you think of a company such as Nokia, it started out as a paper mill, became a plastics manufacturer and then eventually a telecommunications company. During this time, its value chains radically altered. In order to understand an environment, we need to somehow capture this aspect of change and combine it with our value chain. The biggest problem is that the process of change and how things evolve cannot be measured over time. As uncomfortable as it is, you have to embrace the uncertainty of future change. Fortunately, there's a neat trick because while evolution can't be measured over time, it can be measured over certainty.

So, this is what you need to do. Take your value chain and plot the components along an evolution axis covering genesis, custom built, product (+rental) and commodity (+utility). This is what I've done in Figure 4 below for the TV company.

All the components in the map are evolving from left to right due to supply and demand competition. As they evolve their characteristics change from an uncharted domain (the uncertain, rare and constantly changing) becoming more industrialised (the known, the common, the stable). For example, power supply is something commonplace and well understood. However, creative studios and the art of creating a TV show is less common and less well understood.

Once you have a map, examine it. In Figure 4, the content component of the TV company has an interesting distinction between creation and distribution; for example, there is a pipeline of content creation from commissioned shows to acquired formats along with separate distribution mechanisms such as traditional media and internet broadcast. To make this distinction more visible, you can add a pipeline to the map – see below (Figure 5).

You now have something that you can start to discuss the environment in which a TV company operates.

Step 4. Challenge

Three of the biggest issues within any organisation are bias, communication and duplication. Invariably when someone in a company tells me they want to build something such as a 'rules engine', then it doesn't take long to discover at least half a dozen other projects building rules engines in the same company.

Duplication is rampant in most organisations because there is usually no means of effective communication within groups. Even if you do find another group that's no guarantee they'll want to work together – they tend to believe their rules engine is unique and different from everyone else's. Everyone has bias.

One of the beautiful things about maps is that you can start to build up a portfolio of maps from different parts of the organisation and start to challenge this duplication and bias by sharing. Maps give you the communication mechanism to do this. When you start getting good at this, you can even challenge your own maps against the outside market and other competitors. The way that I normally do this is to start by aggregating maps; an example of which is given below in Figure 6.

When you look at your map not every component will have a duplicate in the organisation. That said, many components will have multiple implementations. For example, if we take our aggregated view as typical of a media conglomerate, then there would be 13 different implementations of the website, five different implementations of a recommendation engine and 18 different implementations of compute in the same organisation. These are all examples of duplication.

Even if you find duplication, then not every group will treat the same component in the same way. For example, in Figure 6 above, the 14 different implementations of the web server will vary from one group believing it should be custom built to a larger group maintaining that it's more of a commodity. This is the issue of bias.

By choosing clusters of points on an aggregated view (the red dots) – you can determine roughly how something should be treated like in our map (the blue dot) – we have market analysis as something relatively novel and best implemented with an early stage product. However, the majority (the cluster shown as red dots) has market analysis as something common, well-defined and best implemented with a commodity or utility like service. The use of the aggregated view can therefore tell us that we're not the only group doing market analysis in the organisation but also that other groups are treating it in a much more effective and commodity-like manner.

1 2 Page 1
Page 1 of 2
7 secrets of successful remote IT teams