Chapter 2
The problem I had was how do I map a business? Unlike a board game such as chess with its turned based moves, when you consider a business it is a living thing. It consists of a network of people, a mass of different activities and reserves of capital including financial, physical, human and social. It consumes, it produces, it grows and it dies. Like all organisms, any business exists within a community of others, an ecosystem. It competes and co-operates for resources and it’s shaped by and shapes its environment. Even within a business, people come and go. The things we do, the things we build and the things that others desire change over time. All firms are in a constant state of flux and the ecosystem it lives within never stands still. What sort of map can cope with that?
I struggled with these concepts for many months, playing around with different ideas of mapping and how to represent this maelstrom. I knew any map had to have those basic elements of being visual, context specific, the position of components relative to an anchor and some means of describing movement. But I had no idea where to start.
It was at this point I thought about mapping what was core for my business and questioning how this changed using some form of mindmap. My reasoning was simple. A business, like all organisms, needs to continuously adapt to changes in order to survive and if we could somehow describe this then maybe that would give us a map? Take for example, the multinational Finnish company Nokia. Originally founded in 1865 as a paper mill, the company has undergone many transformations through various close calls with bankruptcy. From a paper mill to a rubber manufacturer to consumer electronics to a telecommunications giant, this organism has radically evolved. The problem for me was the core for Nokia today was not its core in 1865 but instead an unimaginable flight of fancy at that time. How could I connect the two? When you focus on what is core for a company then the question becomes whether you mean core today, core yesterday or core tomorrow? They are not necessarily the same. I followed this logic down endless rabbit holes getting nowhere fast.
In frustration, I started to ask why do things change? The responses I was given when talking to my peers varied from “progress” to “innovation” to “disruption”. Examples across history were normally cited including the appearance of random innovations that impact the way we operate – from the telephone to electricity to computing. But given the upheaval they cause, the close calls with bankruptcy, the death of former great companies and the need to continuously learn new skills then why would anyone want this? Surely a more sedate, slower rate of change would be more comfortable? So why are things changing?
Alas it seems that we don’t get a choice. In any industrial ecosystem, novel and new things constantly appear as a consequence of the desire for companies and individuals to gain an advantage over others. Those things that are useful will be copied. They will spread until the once novel and new becomes commonplace. Yesterday’s wonders are destined to become today’s discounted special offers. The magic of the first electric light bulb, the first computer and the first telephone are now an expected norm. We no longer marvel at such things but instead we would reel in utter shock if presented with a workplace that did not provide them. Competition and the desire to gain an advantage not only creates change, it spreads it and forces companies to adopt it. Somehow, I had to map this competition itself including the journey from novel to commonplace. But what is that journey and what are the components that I’m going to map?
The more I looked into this, the more complex it became because that journey from novel to commonplace is not the end of the story. These extremes are connected as one enables the other. A historical demonstration of this would be Maudslay’s screw cutting lathe in 1800. The invention of the first screw thread is often cited as 400BC by Archytas of Tarentum (428 BC - 350 BC). Early versions of this and the subsequent nut and bolt designs were custom made by skilled artisans with each nut fitting one bolt and no other. The introduction of Maudslay’s lathe enabled repeated production of uniform nuts and bolts with standard threads. One nut now fitted many bolts. The artisan skill of building the perfect nut and bolt was replaced by more mass produced and interchangeable components. The novel had become commonplace. Whilst those artisans might have lamented the loss of their industry, those humble components also enabled the rapid creation of more complex machinery. Uniform mechanical components enabled the faster building of ships, guns and other devices. It also allowed for the introduction of manufacturing systems that took advantage of these components. In 1803, collaboration between Marc Isambard Brunel and Maudslay led to the principles of modern mass production being introduced at Portsmouth dockyard. The use of block making machinery replaced the craft of custom made pulley blocks, an essential component in the rigging of Naval ships. A total of 45 machines enabled a magnitude of order increase in productivity with highly standardised outputs. This system of manufacture helped changed ship making itself. The practices subsequently spread throughout industries leading to what became known as the Armory Method and later the American System of manufacturing.
Things not only evolved from novel to commonplace enabling new things to appear but they also allowed for new forms of practice and organisation. Throughout our history, it has always been standardisation of components that has enabled creations of greater complexity. We are always standing on the shoulders of past giants, of past innovations, of past wonders that have become commonplace units. Without such well-defined mechanical or electrical components then our world would be a less technologically rich place – no Internet, no generators, no TV, no computers, no light bulbs and no toasters.
Why toasters?
In 2009, the designer Thomas Thwaites exhibited his attempt to build a common household toaster from scratch at the Royal College of Arts. Beginning with mining the raw materials he aimed to create a product that is usually built with common components and sold for a few pounds in the local supermarket. This ambitious project required “copper, to make the pins of the electric plug, the cord, and internal wires. Iron to make the steel grilling apparatus, and the spring to pop up the toast. Nickel to make the heating element. Mica (a mineral a bit like slate) around which the heating element is wound and of course plastic for the plug and cord insulation, and for the all important sleek looking casing”.
After nine months and at a cost of over a thousand pounds, Thomas finally managed to create a sort of toaster. It lasted 5 seconds, the heating element bursting into flames. However, along his journey Thomas had been forced to resort to using all sorts of other complex devices built from similar standard components that he could have used to make his toaster. Everything from microwaves to leaf blowers was involved in achieving his goal. Our society and the wondrous technologies that we can create not only consume but are dependent upon provision of these standard components. Remove this and the wheel of progress grinds very slowly and very expensively.
Back in 2004, Thomas hadn’t attempted this experiment but I was acutely aware that we lived in a world where there’s a constant flow of change, where the novel becomes commonplace and where the commonplace enables the novel. This is the environment that businesses live within. This entire process is driven by competition; the desire to differentiate creates the novel, the desire to keep up with others makes it commonplace. If we define economic progress as the movement of our society to ever more complex technological marvels, then progress is simply a manifestation of this competition. This impacts all organisations. This is what we have to map.
But in all this complexity there was also comfort. I knew my world was built of components and hence it had its own chess pieces. Those pieces changed but there might be a way of describing evolution and the movement from novel to the commonplace. But movement is not enough for a map, I also needed to find the position of these components and that required some form of anchor. Alas, I had no anchor and without it then I was still lost.
The first map
In later chapters I’m going to dive into the details of how this first map was created, how I discovered that anchor and ultimately described the movement of evolution from novel to commonplace. However, for our purposes I’m going to simply show you a map, explain what bits matter and then use it to navigate the strategy cycle. I would dearly love to claim that this map was the result of my towering intellectual might but in reality, as you will later discover, it was more trial and error combined with endless accidents. Figure 6 is what a map of a single line of business should look like. I created my first map in 2005 and it was for an online photo service that I ran. Take a few minutes to read it carefully.
Figure 6 – A Map
The map is visual and context specific i.e. it is unique to that line of business containing the components that influence it at that moment in time. This is not a map of an automotive industry in 2016 or a pharmaceutical company in 2010 but instead an online photo service in 2005. The map has an anchor which is the user and their needs. The position of components in the map are shown relative to that user on a value chain, represented by the y-axis. Each component needs the component below it, however the higher up the map a component is then the more visible it becomes to the user. The lower it is then the less visible it becomes. For example, in that first map the user cares about online photo storage but whilst this needs the provision of underlying components such as compute and power, those components are positioned far from the user and hence are less visible.
I could have described this as a chain of needs but I wanted to emphasize what the user valued. They cared about what was provided to them and not who provided my electricity. Of course, as the provider of the service, I cared about everything - my users’ needs, what compute we used and even what electricity provider we employed. In much the same way, the user cares about the toaster and what it does and not that you lovingly created nickel heating elements by hand rather than using standard components. Though, they will probably care if you try and charge them a thousand pounds for a toaster which bursts into flames at first use.
The components of the map also have a stage of evolution e.g. genesis which represents the novel, custom built, product (including rental) and commodity (including utility). The latter represents the commonplace. This evolution is shown as the x-axis and all the components on the map are moving from left to right driven by supply and demand competition. In other words, the map is not static but fluid and as components evolve they become more commodity like.
In figure 7, I’ve taken the original map above and highlighted the elements that matter. This map has all the basic elements of any map – visual, context specific, position of components (based upon an anchor) and movement. In later chapters as appropriate we will explore each in more detail.
Figure 7 – Basic elements of a map
However, the map also has some advanced features which are not so immediately obvious. There is a flow of risk, information and money between components. The best way to think of this is by use of a military example. You have components such as troops which might occupy different positions on the map but along with movement, you also have communication between the troops. That communication is flow. It’s important not to mix those ideas together because it’s easy to have troops effectively communicating together but at the same time being ineffective by moving in the wrong direction. There can be several reasons for this including the wrong orders are given or there is no common understanding of purpose.
The components can also represent different types of things, the military equivalent of different troops – infantry, tanks and artillery. In these Wardley maps, the common name now given to them due to my inability to find something useful to call them, then these types represent activities, practices, data and knowledge. All of these types of components can move and in our case this means evolve from left to right driven by competition. However, the terms we use to describe the separate stages of evolution are different for each type. In order to keep the map simple, the x-axis of evolution shows the terms for activities alone. The terms that I use today for other types of things are provide in figure 8.
Figure 8 – Types and stages of evolution
Lastly climatic patterns can be shown on the map. I’ve highlighted these more advanced elements onto figure 9.
Figure 9 – Advanced elements of a map.
In the above map, platform is considered to be evolving to a more utility form and inertia exists to the change. Normally, we don’t mark up all of these basic and advanced elements in this way. We simply accept that they are there. However, it’s worth knowing that they exist. The normal way to represent a map is provided in figure 10.
Figure 10 – A standard representation
Now with a simple map such as figure 10, we can start to discuss the landscape. For example, have we represented the user need reasonably and are we taking steps to meet that user need? Maybe we’re missing something such as an unmet need that we haven’t included? Are we treating components in the right way? Are we using a utility for power or are we somehow building our own power station as though it’s a core differentiator visible to the user? If so, why? Have we’ve included all the relevant components on the map or are we missing key critical items? We can also start to discuss our anticipations of change. What happens when platform becomes more of a utility? How does this affect us? What sort of inertia will we face?
Maps are fundamentally a communication and learning tool. In the next chapter we’re going to loop through the strategy cycle in order for me to teach you some of the basic lessons that I learned. However, before we do this, I just want to describe a few steps to help you create your own maps.
Step 1 - Needs
Critical to mapping is the anchor and hence you must first focus on the user need. This requires you to define the scope of what you’re looking at – are we a tea shop, an automotive company, a nation state or a specific system? The trick is to start somewhere. You will often find that in the process of mapping you need to expand or reduce your scope and there is nothing wrong with this. A map for a particular company is part of a wider map for the ecosystem that the company operates within. A map of a particular system within a company is part of the map for the entire company. You can expand and reduce as necessary. It’s worth noting that the user needs of one map are components in another. For example, the user needs for a company producing nuts and bolts become the components used (i.e. nuts and bolts) for a company producing automobiles or bridges.
In our first map the user needs for an electricity provider are simply drawn as a single component far down the value chain of our map and described as power. As a user, we could describe our needs for power as being reliable, utility like, provided in standard forms and accessible. From the perspective of examining an online photo service then a single component is enough. However, that single component will break into an entire map for an electricity provider including different forms of transmission, generation and even spot markets. A single node on one map can be an entire map from another person’s perspective. Equally, the entire map of your business might be a single component for someone else.
Hence start with a scope and define the user needs for that scope. Be careful though because a common trap is not to think of your user needs but instead to start to describe your own needs i.e. your desire to make a profit, to sell a product or be successful. You need to think precisely about what your user needs. If you’re a tea shop then your users may have needs such as a refreshing drink, a convenient location, a comfortable environment, a quick service and a treat like tasty piece of lemon drizzle cake. This in turn requires you to have the capability to satisfy those needs. If you don’t then your plan for world domination of the tea industry might be abruptly halted. At the same time, you should distinguish between the many things that your users want but do not necessarily need. So start with questions such as what does this thing need to do, how will its consumers interact with it and what do they expect from it? There are various techniques to help elucidate this but I’ve found nothing more effective than talking directly to your own users. Creating a user journey for how they interact with what you provide is always a good start.
As you discuss with users, along with the usual list of wants (i.e. I want my cup of tea to make me fabulously witty, slim and handsome) then you might find they have genuine unmet needs or novel needs that they find difficult in describing. These are important. Don’t ignore them just because you don’t provide them at this time. Back in 2005, our user needs for the online photo service included such things as sharing photos online with other users. This required us to have a capability such as the storage of digital photos and a web site to upload and share them with others. These capabilities are your highest level components and the manifestation of your user needs. For us, that included the storage of digital photos, manipulation of images (removal of red-eye, cropping), sharing of images via the web site and printing to physical products from photos to mouse mats. This is shown in figure 11.
Figure 11 – User needs.
Step 2 – Value Chain
Whilst having user needs is a great start, just knowing the needs doesn’t mean the stuff will now build itself. There are other things involved and this is what we call a value chain. It can be simply determined by first asking the question of “what is the user need” and then by asking further questions of “what components do we need in order to build this capability?”
For example, in the case of our online photo service, once the basic user needs were known then we could describe our top level capabilities, our top level components. We could then describe the subcomponents that these visible components themselves would need. The best way I’ve found of doing this, from practice, is to gather a group of people familiar with the business. Huddle together in some room with lots of post-it notes and huge whiteboard, ideally a wall. Now write down the user needs and the top level capabilities required to meet them. These capabilities should be written on the post-it notes and placed on the wall in a fairly random order. Then for each capability, using more post-it notes, the group should start to write down any subcomponents that these top-level components will use. This can include any activity, data, practice or set of knowledge.
For each subcomponent further subcomponents should then be identified until a point is reached that the subcomponents are now outside of the scope of what you’re mapping. Power doesn’t need to be broken down any further if the company consumes it from a utility provider. By way of example, to manipulate online digital photos needs some sort of online digital photo storage component. This in turn needs a web site which in turn needs a platform that in turn needs compute resources, storage resources, an operating system, network, power and so forth. These components will become part of your value chain and any component should only to be written once on your post-it notes. When the group is satisfied that a reasonable set of components for all the needs have been written then draw a single vertical line and mark it as the value chain as shown in figure 12.
Figure 12 – A framework for the value chain.
The top-level components (i.e. your capabilities, what you produce, what is most visible to the user) should be placed near the top of the value chain. Subcomponents should be placed underneath with lines drawn between components to show how they are related. This component needs that component. As you go through this process, you may wish to add or discard components depending upon how relevant you feel they are to drawing a useful picture of the landscape. They can always be added or removed later. In figure 13, I’ve provided a value chain for our online photo service adding in the superfluous term “needs” to emphasize that this is a chain of needs. Obviously, for simplicity, not everything is included e.g. payment. Before you ask, most users do have a need for not being accused of theft, so providing a payment capability is quite useful to both them and your business assuming that you’re not giving everything away freely.
Figure 13 – A value chain
To reiterate, things near the top are more visible and have more value to the user. For example, online image manipulation was placed slightly higher than online photo storage because it was seen as a differentiator with other services that existed in 2005 and hence valued by users. Online photo storage was also a subcomponent of image manipulation. The web site, a necessity for sharing, was placed slightly further down because though it was essential, many websites existed and it was also a subcomponent of online photo storage. Now this last point we could easily argue over but the purpose of doing this in a group is you’ll often get challenge and debates over what components exist and how important they are. This is exactly what you want to happen. In the same way a military commander welcomes challenge on the ground from troops on the position of forces and key features. Don’t ignore the challenge but celebrate it as this will become key to making a better map.
But also, don’t waste time trying to make a perfect value chain in order to build a perfect map. It’s not only impossible, it’s unnecessary. All maps, including geographical maps are imperfect representations of what exists. To draw a perfect geographical map then you would have to use a 1 to 1 scale at which point the map being the size of the landscape it covers is anything but useful. A map of France, the size of France helps no-one.
Step 3 – Map
As I quickly discovered, value chains on their own are reasonably useless for understanding strategic play in an environment. This is because they lack any form of context on how it is changing i.e. they lack movement. If you think back to the example of Nokia, then its value chains have radically altered over time from a paper mill to telecommunications company. In order to understand the environment, we therefore need to capture this aspect of change and combine it with our value chain. The largest problem with creating an understanding of the context in which something operates within is that this process of change and how things evolve cannot be measured over time. As uncomfortable as it is, you have to simply accept that you don't have a crystal ball and hence you have to embrace the uncertainty of future change. Fortunately, there’s a neat trick because whilst evolution cannot be measured over time, the different stages of evolution can be described. So, this is exactly what you need to do. Take your value chain and turn it into a map with an evolution axis. On the wall or in whatever tool you’ve used to create your value chain, now add a horizontal line for evolution. Mark on sections for genesis, custom built, product and commodity as shown in figure 14.
Figure 14 – Adding evolution to your value chain
Figure 14 – Adding evolution to your value chain
Now all the components are likely to be in the wrong stages of evolution. Hence start to move the components of the value chain to their relevant stage. For each component the group should question how evolved it is? In practice the best way to do this is to examine its characteristics and ask: -
• How ubiquitous and well defined is the component?
• Do all my competitors use such a component?
• Is the component available as a product or a utility service?
• Is this something new?
Be warned, this step is often the main cause of arguments in the group. You will regularly come across components that parts of the group feel passionate about. They will declare it as unique despite the fact that all your competitors will have this. There is also the danger that you will describe the component by how you treat it rather than how it should be treated. Even today, in 2016, there are companies that custom build their own CRM (customer relationship management) system despite its near ubiquity and essential use in most industries.
There are many causes for this, some of which are due to inertia and the component being a pet project and in other cases it is because the component is actually multiple subcomponents. In the latter case, you’ll often find that most of the subcomponents are commodity with maybe one or two that are genuinely novel. Break it down into these subcomponents. It is essential for you to challenge the assumptions and that is part of what mapping is all about, exposing the assumptions we make and providing a means to challenge. This is also why working in a group matters because it’s far too easy for an individual to apply their own biases to a map.
If we think of mapping a tea shop, then we might argue that our lemon drizzle cake is home-made and therefore custom built. But in reality, is the provision of a cake in a tea-shop something that is rare and hence relatively novel? Or is the reality that a user expects a tea shop to provide cake and it is commonplace? You might market the cake as home-made but don’t confuse what you market something as with what it is. The tea shop up the road could just as easily buy mass produced cake, add some finishing flourishes to it and describe it as home-made. If it’s cheaper, just as tasty, more consistent and to the user an expected norm for a tea shop then you’ll be at a disadvantage. The same is true of building your own Thomas Thwaites toaster rather than buying a commodity version to provide toast. To help you in the process of challenge, I’ve added a cheat sheet in figure 15 for the characteristics of activities. How this was created will be discussed in later chapters but for now simply using this as a guide. Where arguments continue to rage then look to see if the component is in fact multiple subcomponents.
Figure 15 – The cheat sheet
Don’t worry if some of the terms are confusing in the cheat sheet, just use what you can. Like Chess, mapping is a craft and you will get better with practice. Today, topographical intelligence in business is more about Babylonian clay tablet than ordinance survey maps for industries. The art is very much in the custom built stage of evolution (see the cheat sheet above). You should also aim to complete an entire map of a line of business in a matter of hours though there is nothing wrong with spending longer in your first attempts to get used to the process. I’m afraid there is a big downside here. Mapping, like learning to play chess, is something that only you and your team can do. You will have to follow the path that I took when I was a CEO and learn to map. You can’t outsource mapping to someone else any more than you can outsource learning to play chess to a consultancy. Well, technically you can but you won’t be learning and you’ll just become dependent upon them, constantly asking for your next move. Which, to be honest, is what many of us have done but then if you’re happy with that, stop reading this book and just ask a consultancy for your strategy. If you’re not happy with that then be warned that the amount of value that you will get from mapping increases with the amount of work you put into repeatedly using it.
It’s also worth noting that when adding practices, data and knowledge to your map then you can use the same cheat sheet for each stage of evolution i.e. data that is modelled (see figure 8) should be widespread, commonly understood, essential and believed to be well defined. It shares the same characteristics as commodity activities. Once you have placed the components in their relevant stage to the best of your ability, you now have a map, as per figure 16. Remember that this map was for an online photo service in 2005 and so the composition of components and their position will not be the same as they are today. We expect an awful lot more from an online photo service in 2016. The map is hence fluid and constantly evolving.
Figure 16 – The map.
The next thing to do is to share your map with others in your organization and allow them to challenge you and ideally your group. This is exactly what I did with my colleague James Duncan (who was CIO of the company at the time). With help from James, I refined both the map and the concept, something which I owe him a great deal of thanks for. If there is a co-inventor of mapping, then it would be James. Our robust debates in the boardroom showed me that business and IT are not separate but we could discuss strategic gameplay together around a map. It’s a bit like the Army and the Air Force. They might have different capabilities and strengths but if we use a map to communicate then we can make all of this work together. As I have found subsequently, this process of sharing not only refines the map but spreads ownership of it. You should also use this time to consider any unmet needs, any missing components and ask questions on whether you’re treating things in the right way? It’s often surprising to find how many companies are spending vast resources on building their own metaphorical Thomas Thwaites toasters when a commodity version is readily available.
With a map in hand, we’re now ready to start exploring the strategy cycle and hopefully start learning some useful lessons. Well, at least that’s what I hoped for in 2005. In the next chapter, I intend to show you what I discovered. But before I do, I have a request to make of you. Take a break, read this chapter again, pick a part of your business and have a go at mapping it. Simply follow the steps and use the cheat sheet. Ideally, grab a couple of other people that are deeply familiar with that business to help you and don’t spend too long on it. Keep it to a couple of hours, three to four at most. If within that time, you don’t feel you’re learning more about that business and the mapping isn’t raising questions on user needs and what’s involved then stop. You can recover your lost time by simply not reading any more chapters. Pick the book up, aim for the refuse bin and with a shout of “that was a complete waste” then let it fly. If instead you found the exercise interesting, then let us continue this journey together.
----
Next Chapter in Series : Exploring the map
GitBook link [to be published soon]
