One of the most common difficulties mapping adepts report is the lack of confidence in component identification. Very often, Simon’s statements ‘All maps are wrong, some are useful’ and ‘practice, practice, practice’ are not enough, especially if you are learning on your own, using publicly available resources.

This post is essentially my attempt where I try to dump and organise everything I have learned so far about the component identification process, and I do hope some of you will find it useful, at least a bit.

This post is a CC-BY-SA wiki page. Feel free to edit, use it or include it into anything you wish. Language, vocabulary and grammar corrections are welcome, too.If you need to discuss something, you may use Map Camp Slack Channel.

Subjectivity

dreamstime_xxl_125596529.jpg2393×1595 2.56 MB

Look at the picture above. What components can you identify (and how many of them)? Most of you will probably say - 5 chairs, 2 tables, 2 bottles, etc. That is a natural approach, as we, humans, tend to use physical borders to identify components, even if there is no borders in the first place.

The picture below shows how our expectations shape what components can we see. While the white triangle is not drawn, you have no problems with finding it and pointing out the triangle boundaries.

Humans recognise physical borders even there where there is no objective reasons to do so. Image licenced under CC-BY-SA, original work available here

Now, if we get back to the picture #1, our expectations plays a vital role in how we do identify those components, because we can quite easily say that on the picture we can see:

• dining furniture for two couples
• an arrangement of furniture in a coffee shop
• a large number of colorful pixels

The latter might be surprising, and sound smart-assy, but it proves the point that the purpose of our analysis determines which components are important for us. Two persons looking at a given context with different goals will identify different components, as what is meaningful in one situation, might not be meaningful in other.

Convergence

Certain freedom in component identification means that no approach is wrong. You can continue as you please, and the only criterium becomes “Is it useful?”, which can be translated as “Does it allow you to solve your problem?”. It does, if you have captured all the important components, and you know you have done so if:

• you have presented your thinking to domain experts, and they agree with you that your thinking is correct
• it allows you to predict what will happen in your environment

Naturally, checking with industry experts is usually cheaper than testing a model in reality, so that should be your preferred approach. The caveat here is that each first attempt to identify components results a graphical representation of what you think about the problem, and not in a magic insight in how things work. Which basically means that in order to “properly” identify components, you should:

1. Do the initial work.
2. Investigate all the assumptions.
3. Consult with others.
4. Test with reality.

And, probably, you will find out that at each step there is a refinement to be done, or you may have to start from scratch again. The message here would be:

Do not try to be right from the very beginning. The journey and discovery process matters more than the output.

Symbolism

If I say “snow”, you probably will think about this white thing that falls down from the sky in the winter. I will assume that you understand “snow” in the same way as I do, albeit we have different experiences, feelings and images in mind related to that concept.

The issue here is that “the snow” is just a symbol, and it is no different from “fall down from the sky”. The latter is an abstract symbol that carries a message (experience) we can relate our own observations to.

“The map is not the territory” means actually that the model we assemble out of components is exactly just a model. Symbols do not reflect the true nature of the reality, so it is always an approximation. Simon calls this a property of the language.

Recent discoveries in neuroscience show that we use the same part of the brain to navigate in our environment and to think; we store thoughts and experiences as if they were physical objects (internal map), so the hypothesis is that our thinking process is in fact a navigation exercise between everything we have experienced.

The reason why I am mentioning this is that to build a useful model, you have to use different perspectives (set of experiences) in hope you will get a model closer to the reality.

Also, uncertain, abstract components do not have clear borders. Look for example at the history of science. At some time, computer science was a part of math. Earlier, there was no geography, biology and other fields, just philosophy.

That shows that, sometimes, symbols have very undefined meaning attached to them, and it takes time, and effort to make the meaning more precise - sometimes even industry experts do not know what is a given thing, and often, naming it brings it to life.

I just cannot stress it enough - if you name an experience, or a set of your experiences, you create a component. If others will find your name useful, it will spread, and over time, the name will become a mental shortcut to the experiences.

One more thing to remember is that once you name a thing, you stop analysing the experiences to reduce cognitive effort. You substitute a set of complicated relations with a symbol, which allows for cutting-off analysis at some points.

When you do your analysis, it is important to be aware of this thing. Each concept you use, each component you identify, is a potential end of the analysis. But you might be wanting to dig in into component specifics, as there might be some important things for you there. So choosing the cut-off points should be a very conscious process (if not the most conscious one in the whole process).

Forms of capital

Understanding how symbols work allows us to identify non-physical components with greater ease. If you can name a set of experiences (or data, or practices), you form a component.

In business, you can use money to acquire any component (you exchange money for knowledge/data/practices/etc), or in other words, you buy things. The reverse process is not always possible - while you can easily buy things, selling your components might be difficult. Some knowledge (or experience) is quite difficult to monetise, especially if it is less efficient than alternatives.

That insight is a basis for some form of inertia analysis - the conversion money-asset-money is not always as easy as traditional accounting methods would say.

Steps

Therefore, a distilled version of all I have written above would be:

1. Start with the purpose. Purpose determines what is important and what is not. Suitability for purpose determines the quality of your analysis. There is no objective, context-free quality measurement of your analysis.
2. Identify what you think is important in your context. It js all about your thinking. You may find gaps, unconscious assumptions and cuttoff points, which serve as a good investigation plan.
3. Have your work challenged. What you have created in previous points, is just your understanding of the reality. Make it more fidel by talking to field (or component) experts.
4. Test the model. Does it really help you to meet your goals? Is it accurate enough? Refine and improve it if not.

Hi Daniel,
Pertinent comments. My experience is that Wardley Maps needs someone with experience to work. Being a newby in any domain will make it difficult to use the tool properly. It will make it even more difficult to create credibility. Having said this, the Wardley Map is far more useful than so many marketing/strategy BS graphs out there. If we go back to the premise that the map is a map, then there are multiple ways to cross the map. Some may even involve taking an illogical or unexpected path to beat the competition. So in the end you have to sell your own competency/experience/relevancy first then use the map as a visual guide to help those that don’t see the path.
M

This goes above everything else. No consultants!

Sometimes, indeed. But if you map with a group of people, you learn from each other. Map is a communication tool.

People are sometimes unaware of the domains they “control”. A map can make the domains visual. Abstract it enough and you can discuss: we have “costly” X vs “more costly” custom build X, let’s use the less costly (as X is identical). Use what level of abstraction and language you need to get the message across. Domain experts will give you lots of details on both Xs, start with them, have them explain ( maby the custom building was because the domain expert was unaware of an available alternative product? ). If the termination of custom X is not suggested by the person/team building custom X themselves, maby abstract it for use with management to push for progress(termination). So use correct abstraction level of maps and other people’s competency/experience/relevancy that validates the details in those maps. What the person mapping needs is being able to map(practice I guess) aka getting people to communicate.

I don’t know just some random ideas from me… but it reflects what I read out of what Daniel is writing. I would personally use mapping if starting something I had no clue about. New job new responsibilities etc