The name of this article is misleading because the book doesn’t actually have a name. It is written as a series of articles – so I’m just choosing to call it “Wardley Mapping”. The images here are taken from the book.

---

I have been slowly going over Simon Wardley’s free book on Medium where he walks us through the problems he faced, which then led to the development of the wardley mapping technique. It’s a long book, but the 6 first six chapters cover the most important parts at a high level and provide a nice closure to the problems and proposed solutions. So I am publishing the highlights from these as a package for those who are just starting out exploring Wardley mapping technique.

For the uninitiated, Wardley Mapping is a technique which plots the user needs and the capabilities a company needs to meet them on the axes of customer-visibility and stages of evolution. Things can be more or less visible to customers (Current location of Uber cars is highly visible, the map data powering this is not), and they may be nascent in nature or highly evolved (Uber’s app is highly customized, the map data powering it is fairly standardized). These two dimensions form the “map” of a business problem, and along with some concepts taken from the military, are the core of a process of using the map to decide the next steps the “general” (the person responsible for making a decision) should take.

Although Simon developed this technique as a CEO of a company and used it to drive the overall strategy, I find it extremely useful as an engineer with a more limited, engineering centric view as well. I have been trying my hand at it, and it allows me to map customer experiences to the capabilities we need throughout the ecosystem at all levels. This was always a feature of architectural discussion for me in the past, but knowledge of wardley maps has made it possible for me to bridge the gap between a product specification and architecture doc a little more formally. I can plot and discuss the entire path from roadmap to frontend needs to backend engineering to infra capabilities more crisply with product managers and other engineers.

The other interesting part for me is that it allows for questioning of claims around capabilities already existing in the organization. E.g. If we claim to have a well established authentication system, then it should necessarily be very cheap for me to start using it. I can start out with an assumption that this is a commodity and then question this if I spend myself spending a lot of time on using this system. It’s a good way to keep teams and systems accountable to their claims.

This is one of those “messy middle” books – one that calls for focus on continuous evaluations and evolution instead of focussing just on the method. There are no “answers” in it as such, but there is definitely a powerful tool for discovering answers for your own situation. Life isn’t simple, so why should strategy be – it is good to see this acknowledged as a first class concept in a business book.

The following are my notes and learnings from the book, which is delightfully accessible to people with all levels of expertise. There is no substitute for reading the original anyway – I absolutely recommend it.

Chapter 1 : On being lost

• All models are wrong but some are useful
• We rarely learn from past experience especially when it belongs to others or when it conflicts with our perception of how things are.
• SunTzu had described five factors that matter in competition between two opponents. Loosely speaking, these are: — Purpose, Landscape, Climate, Doctrine and Leadership.
  • Purpose is your moral imperative, it is the scope of what you are doing and why you are doing it. It is the reason why others follow you.
  • Landscape is a description of the environment that you’re competing in. It includes the position of troops, the features of the landscape and any obstacles in your way.
  • Climate describes the forces that act upon the environment. It is the patterns of the seasons and the rules of the game. These impact the landscape and you don’t get to choose them but you can discover them. It includes your competitors actions.
  • Doctrine is the training of your forces, the standard ways of operating and the techniques that you almost always apply.
  • Leadership is about the strategy that you choose considering your purpose, the landscape, the climate and your capabilities. It is to “the battle at hand”. It is context specific
• There is not one but two questions of why in chess. I have the why of purpose such as the desire to win the game but I also have the why of movement as in “why this move over that?”
• There existed two very different forms of why that mattered — purpose and movement
• We had no map of the environment, no visual means of describing the battle at hand and hence no understanding of our context. Without maps, I didn’t seem to have any effective mechanism of learning from one encounter to the next or even a mechanism of effective communication
• What is it that made maps useful? The first, and most obvious thing, is that they are visual.
• The second thing to note with a map is it is context specific i.e. the battle at hand.
• …six absolute basic elements for any map which are visual representation, context specific, position of components relative to some form of anchor and movement of those components.
• If I can’t separate out what is context specific, then how do I determine what is Doctrine i.e. universally applicable from that which is leadership i.e. context specific?
• First, the process of strategy is not a linear process but an iterative cycle. The climate may affect your purpose, the environment may affect your strategy and your actions may affect all. Second, acting is essential to learning. Lastly your purpose isn’t fixed, it changes as your landscape changes and as you act. There is no “core”, it’s all transitional.
• In order to understand the process of air combat, John Boyd developed the [OODA loop. This is a cycle of observe the environment, orient around it, decide and then act

Chapter-2 : Finding a path

• All firms are in a constant state of flux and the ecosystem it lives within never stands still.
• Why do things change? 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.
• Throughout our history, it has always been standardisation of components that has enabled creations of greater complexity.
• The desire to differentiate creates the novel, the desire to keep up with others makes it commonplace.
• The map has an anchor which is the user (in this case a public customer though other types of users exist) 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.
• The components of the map also have a stage of evolution.
  • Genesis. This represents the unique, the very rare, the uncertain, the constantly changing and the newly discovered.
  • Custom built. This represents the very uncommon and that which we are still learning about. It is individually made and tailored for a specific environment
  • Product (including rental). This represents the increasingly common, the manufactured through a repeatable process, the more defined, the better understood.
  • Commodity (including utility). This represents scale and volume operations of production, the highly standardised, the defined, the fixed, the undifferentiated, the fit for a specific known purpose and repetition, repetition and more repetition.
• 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.
• There is a flow of risk, information and money between components
• The components can also represent different types of things. These types represent activities, practices, data and knowledge.
• Step 1 — User 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
  • a common trap is not to think of your user’s 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
  • These capabilities are your highest level components and the manifestation of your user needs
• Step 2 — Value Chain
  • …a value chain 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?”
  • Gather a group of people familiar with the business and huddle in some room with lots of post-it notes and a huge whiteboard
  • On the post-it notes write down the user needs and the top level capabilities required to meet them.
  • 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
  • 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 e.g. this component needs that component
• Step 3 — Map
  • 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
  • The largest problem with creating an understanding of the context in which something operates is that this process of change and how things evolve cannot be measured over time
  • whilst evolution cannot be measured over time, the different stages of evolution can be described
  • add a horizontal line for evolution. Mark on sections for genesis, custom built, product and commodity
  • 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
    • 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
  • You can’t outsource mapping to someone else any more than you can outsource learning to play chess to a consultancy.

Chapter 3 – Exploring the map

• Climatic patterns are those things which change the map regardless of your actions.
• This can include common economic patterns or competitor actions.
• Climatic pattern: Everything evolves
• Climatic pattern: Characteristics change
• Climatic pattern: No one size fits all
  • With any business you need to encourage coherence, co-ordination, efficiency and stability when dealing with the industrialised domain. However, the exploration and discovery of new capabilities in the uncharted domain requires you to abandon these erstwhile virtues for experimentation. Any structure whether a company or a team needs to manage both of these polar opposites.
  • Any significant system will have components at different stages of evolution. At any one moment in time, there is no single method that will fit all.
  • Invariably there are endless attempts to create a new magic one size fits all method by trying to make a single approach all encompassing or marrying together different stages e.g. lean six sigma or agile lean or prince agile
• Climatic pattern: Efficiency enables innovation
  • The story of [[Evolution]] is complicated by the issue that components not only evolve but enable new higher order systems to appear.
  • As a component evolves to a more standard, good enough commodity then to a consumer any improvement becomes increasingly hidden.
• Climatic pattern: Higher order systems create new sources of worth
  • the story of evolution doesn’t simply stop at efficiency and the consequential enablement in building higher order systems. It also has an impact on value
  • An idea is something with social value and it is the implementation of that idea as a new act which can create economic value when that act is useful. This process of transformation from social to economic value is known as commodification
  • At the same time that the differential benefit of a component declines, it also becomes more of a necessity and a cost of doing business. This is the process of commoditization
  • This creates a situation where the unit value of something maybe declining but the total revenue generated is increasing due to volume.
• The uncharted domainx is associated with high production costs, high levels of uncertainty but potentially very high future opportunity.
• The transitional domain is associated with reducing uncertainty, declining production costs, increasing volumes and highest profitability. However, whilst the environment has become more predictable, the future opportunity is also in decline
• The industrialised domain is associated with high certainty, high levels of predictability, high volumes, low production costs and low unit margin (Red Ocean)
• Climatic pattern: No choice on evolution
  • There exists a secondary impact of the Red Queen phenomenon which is it limits one organisation (or in biology one organism) from taking over the entire environment in a runaway process
• Climatic pattern: Past success breeds inertia

Chapter 4 – Doctrine

• Doctrine are the basic universal principles that are applicable to all industries regardless of the landscape and its context.
• Doctrine: Focus on user need
  • When you look at a map, each component represents a store of capital (whether physical, financial or otherwise). The lines between components represent capital flows from one component to another.
  • Discussion and data collection are a key part of determining user needs and so talk with them and talk with experts in the field.
  • There are two important areas where the users and the experts are usually wrong in describing their own needs.
    • The first area is when a component is moving between stages of evolution
    • The second area to note is that of the uncharted domain. These needs are both rare and highly uncertain and this means you’re going to have to gamble
• Doctrine: Use a common language
  • Instead of using multiple different ways of explaining the same thing between different functions of the company then try to use one e.g. a map.
  • [My Note] – This is very similar to the concept of “Ubiquitous Language” from Domain Driven design in a software engineering concept
• Doctrine: Be transparent
• Doctrine: Challenge assumptions
• Doctrine: Remove duplication and bias
  • You should not only share maps, you should collate them in an effort to remove duplication and bias i.e. rebuilding the same thing or custom building that which is already a commodity.
  • the same component being on different maps is fine except when we’re saying it’s a different instance of that component
  • I find useful in helping to highlight this problem is to create a profile diagram. I simply collate maps together, identifying commonly described components and then place them onto the profile. This gives me an idea of both duplication and bias
• Doctrine: Use appropriate methods
  • The issue with outsourcing isn’t that the concept is wrong but instead that we have a tendency to outsource entire systems for which we do not understand the landscape.
  • The problem was not that a highly structured process with detailed specification was correctly applied to industrialised components but that the same technique was also incorrectly applied to components that were by their very nature uncertain and changing.
  • it’s important to challenge any bias your company may have in your maps
  • there are a wide range of excuses that are deployed for not breaking up entire systems into components and then applying more appropriate methods.
    • “we need better experts and specification”
    • “it’s too complex, splitting into parts will make it unmanageable”
    • “It will cause chaos”
    • The truth is usually more of a desire to have “one throat to choke”
    • “You’ll end up with hundreds of experimental startups”
    • “complexity in managing interfaces”
• Doctrine: Think small 
  • In order to apply appropriate methods then you need to think small. You can’t treat the entire system as one thing but you need to break it into components.
  • teams should be given autonomy in their space and this can be achieved by the team providing well defined interfaces for others to consume along with defined boundaries often described through some form of fitness function i.e. the team has a goal around a specific area with defined metrics for delivery
• Doctrine: Think aptitude and attitude
  • Pioneers are brilliant people. They are able to explore the never before discovered concepts, the uncharted land
  • Settlers are brilliant people. They can turn the half-baked thing into something useful for a larger audience. They build trust.
  • Town Planners are brilliant people. They are able to take something and industrialise it taking advantage of economies of scale.
  • you need to populate the cells with different types of people — pioneers, settlers and town planners.
  • It’s really important to understand that pioneers build and operate the novel.
  • Don’t fall into the trap that Pioneers build new stuff and hand it off to someone else to run or operate.
• Doctrine: Design for constant evolution
  • We need to somehow mimic that constant state of evolution in the outside world but within a company. The solution is to introduce a mechanism of theft which means new teams need to form and steal the work of earlier teams i.e. the settlers steal from the pioneers and productise the work. This forces the pioneers to move on.
  • if a cell sees something they can take tactical advantage of in their space (remember they have an overview of the entire business through the map) then they should exploit it.
  • Maps are a useful way to kick-start this process. They also give purpose to each cell as they know how their work fits into the overall picture.
  • The cells can grow in size but ultimately you should aim to subdivide into smaller cells and maps can help achieve this.
  • You will however increasingly have to structure the monitoring and communication between cells using a hierarchy and yes, that means you need a hierarchy on top of a cell based structure
  • the structure causes three separate cultures to flourish. This is somewhat counter to general thinking because the culture results from the structure and not the other way around. It also means you don’t have a single company culture but multiple
• Doctrine are a set of beliefs over which you have choice. They are something which you apply to an organisation unlike climatic patterns which will apply to you regardless of your choice.

Chapter 5 : The play and a decision to act

• There exists two different forms of why in business — the why of purpose (i.e. win the game) and the why of movement (i.e. move this piece over that)
• One significant problem around making a choice usually stems from past success and the comfort it brings.
• Context specific play: Accelerators, decelerators and constraints
  • the evolution of a component can be accelerated by an open approach, whether open source or open data.
  • the evolution of a component can be slowed down through the use of fear, uncertainty and doubt when crossing an inertia barrier or through the use of patents to ring-fence a technology.
  • the evolution of a component can be affected by constraints in underlying components
  • the very act of open sourcing, if a strong enough community could be created would drive a once magical wonder to becoming a commodity. Open source seemed to accelerate competition for whatever activity it was applied to.
• Context specific play: Innovate, Leverage and Commoditise
  • Take an existing product that is relatively well defined and commonplace and turn it into an industrialised utility
  • Then encourage and enable other companies to innovate by building on top of your utility
  • These companies building on top of your utility are your “outside” pioneers or what we commonly call an “ecosystem”.
  • Your “outside” ecosystem is in fact your future sensing engine.
  • This translates to an increasing appearance of being highly efficient as we industrialise components to commodity forms with economies of scale but also highly customer focused due to leveraging meta data to find patterns others want. Finally, others will come to view us as highly innovative through the innovation of others.
• The decision to act can impact the very purpose of your company — the strategy cycle is not only iterative, it’s a cycle
• Gameplay is context specific. You need to understand the landscape before you use it. The purpose of gameplay is once you determine the possible “wheres” that you could attack (which requires you to understand landscape and anticipate change from common economic patterns) then you look at what actions you can take to create the most advantageous situation.

Chapter 6 : Getting Started

• understanding your landscape, the context that you’re competing in and having a modicum of situational awareness is not a luxury for strategy, it is at the very core of it. Inspiring vision statements, well trained forces, a strong culture and good technology will not save you if you fail to understand the landscape, the position of forces and their size and capabilities.
• there are some basic practices that an MMORPG will teach you
  • The importance of situational awareness
  • The importance of aptitude
  • The importance of collaboration
  • The importance of preparation
• business strategy is normally a tyranny of action — how, what and when — as opposed to awareness — where and why.
• abundant communication mechanisms rather than efficient communication can itself become a problem without good situational awareness as new players constantly ask “where should we go” as they run around in a daze
• There also tends to be an element of political conflict between the business units and the shared services and in the worst cases the shared services function can be viewed as a hindrance.
• we need to separate out the delivery of shared services from the identification of what is common.
• the best way to achieve this is not to remove budget from the business units (often a political bone of contention) but instead to introduce a co-ordination function. The role of the co-ordination function is to encourage compliance to policy (doctrine) often via a spend control mechanism and to enable sharing between the business units
• If it’s important enough for you to create a shared and common service, then there either exists an outside market opportunity or you’re just rebuilding what already exists in the market.
• With your shared services group, then you should aim to populate it with small cells of town planners providing industrialised components. Your business units will tend to become dominated by cells of pioneers and settlers providing custom to product and rental services.
• start with a small co-ordination team of highly skilled people helping other business units create, share maps and learn from them
• You will probably find that some business units start to offer their own home grown capabilities as common components to other business units. Don’t discourage these emergent behaviours
• You can always migrate those components to a shared services group at a later date.
• Recommended books:
  • Sun Tzu, the art of Warfare (Robert Ames translation)
  • Science, Strategy and War by Frans P.B. Osinga
  • Atlas of Military Strategy 1618–1878 by David Chandler.
  • The Simplicity Cycle by Dan Ward
  • Accidental Empires by Robert X. Cringely
  • Hierarchy Theory, The Challenge of Complex Systems by Howard H. Pattee
  • The Evolution of Technology by George Basalla
  • Thinking in Promises by Mark Burgess
  • Diffusion of Innovations, Everett Rogers.
  • Customer driven IT by David Moschella
  • Digitizing Government by Alan Brown, Jerry Fishenden and Mark Thompson
  • Learn or Die by Edward D.Hess
  • The Oxford Handbook of Innovation by Jan Fagerberg, David Mowery and Richard Nelson
  • The Starfish and the Spider, Ori Brafman and Rod Beckstrom
  • Does IT matter? by Nicholas Carr
  • Technological revolutions and financial capital, Carlota Perez
  • The Entrepreneurial State by Marriana Mazzucato
  • Topographical Intelligence and the American Civil War, Daniel D. Nettesheim.
  • The Intelligent Investor by Benjamin Graham
  • Cybernetics by Norbert Wiener
  • Systems Thinking by Jamshid Gharajedahi
  • The Age of Discontinuity by Peter F. Drucker
  • The Red Queen, William P. Barnett

Read Next : Review and highlights from “Thinking in Systems” , a fantastic primer to systems and systems thinking.