I am occasionally asked how to combine Wardley Maps with Cynefin. They are complementary tools, not a replacement for each other nor something that can be mashed into a "holistic" view (except in the mind of DALL-E which kindly created the image which makes no sense whatsoever). They explore a problem space from different viewpoints and both are useful in their own right and should be used together. To explain I'll use an example.

The following is a very simple map, built with onlinewardleymaps that has a user expressing some thing that they need which is fufilled by some capability to meet the thing the user needs. That capability is represented as a pipeline because, in this case, there are multiple choices to fulfil that need. The choices are products from Competitor 1, Competitor 2 and Competitor 3 (see figure 1).

Figure 1 - A basic map of user with needs and multiple solutions to that need

There are few things to note with the map. 

1) Maps represent a chain of relationships. Normally we describe this as needs as in This needs That. Needs are just a form of relationship and there is no reason why you can't use other language to describe that relationship such as expresses, fufilled or constrained by. If it helps explain the landscape you are looking at to others, don't be afraid to experiment.

2) Maps have logical ANDs. For example, if we explore down the chain of Competitor 3's solution then we find that it contains multiple components i.e. this capability from Competitor 3 needs thing AND needs another thing (see figure 2)

Figure 2 - Maps contain logical ANDs.

3) Maps have perspectives. That is true even within a map. Hence the user of this capability might not be concerned with the components that make up the capability, whereas the provider is. Often, we stop mapping a chain at the point we have no influence or control over. As a rule of thumb it's not a bad idea to explore both up and down the chain (outside of your normal areas of influence) because you will often find that what the user describes as their need is not their actual need, and understanding your supply chain and the risks within it can help mitigate against shocks. Just ask all those manufacturers who have ignored their supply chains and then hit Brexit, COVID and the Ukraine war.

4) Maps have logical ORs. The pipeline in the map above represents a choice. You can choose either the solution from Competitor 1 OR Competitor 2 OR Competitor 3. This is not necessarily an exclusive choice i.e. you could have a bit of Competitor 1 and a bit of Competitor 2. For example, if the pipeline is power then you might use a bit of nuclear and a bit of solar. Nuclear OR solar would be your choices.

5) The components in a pipeline are all independently evolving. The pipeline doesn't say that Competitor 1's solution evolves to become Competitor 2's solution but that the three competitive solutions are at different stages of evolution. Ideally, you would represent the entire pipeline (where the square box is) as the most evolved stage of the entire market. Sometimes you don't, but then you are conveying that the market is far less evolved than it should be, e.g. 100s of CIOs custom building ERP in identical ways, making consultants wealthy when, in reality, the entire space should be a commodity.

6) There may be distinct and shared components. If we explore down the chain of both Competitor 1 and Competitor 3's solutions (I'll provide the map here) then we might find common components as well as unique items. For example, our Competitor 1 solution requires expensive consultants. The reason why I highlight this is to point out that the solutions by the competitors to provide the same capability may be fundamentally different (see figure 3).

Figure 3 - Map of distinct and shared components

If we explore those solutions in more detail (these maps are purposefully trivial), we may find many components involved. Tudor Girba (who runs Feenk) spends his life trying to make systems explainable. To show the problem, I'll switch to a graph format to show one system which provides a set of capabilities. (see figure 4)

Figure 4 - A graph example of a system

In our map, we said we had multiple possible solutions to provide the capability. So, sticking within the graph format, this is an example of multiple systems providing the same capability (see figure 5).

Figure 5 - Graphs of multiple systems providing the same capability

Whilst each system is complicated (having many components operating in a defined and known manner), the "right" solution is still emerging. This means the problem space itself is complex. Within that one pipeline you can have multiple complicated solutions to a complex space which is still emerging. Those are terms from Cynefin, and if you want to know more about that subject then talk with Dave Snowden.

 

The point I want to make is you can't simply transport Cynefin terms onto the evolutionary axis of a map, i.e. you can't substitute custom and product for terms like complex and complicated. It doesn't work like that. Also, when you are mapping, you should keep Cynefin in mind. It's a useful mental framework.

Every time you feel the urge to mash these frameworks into one all-encompassing ubermensch framework then just look at the DALL-E picture provided (from a prompt of mixing Wardley Maps and Cynefin) and stop. They are different but complementary. A diversity of viewpoints is not a bad thing.

Figure 6 - DALL-E's representation of a Wardley Map with Cynefin.

So, how do I know which of those competitor solutions to choose? Well, that's a topic for another post. It's enough to know that you can map multiple options.

Follow ons 

If you want to know about Cynefin, talk to Dave Snowden 

If you need help understanding what systems you have, talk to Tudor Girba

If you want a mapping tool try OnlineWardleyMaps and if you use it, then think about becoming a patron. It is a community tool.

If you want to learn more about mapping, why not join us at Map Camp.