Journey Mapping Needs Cynefin

As a default Agile framework Cynefin is an ideal and well-respected approach (source: Dave Snowden and Cognitive Edge) that helps in the management of innovation. However, it seems to lack traction in the CX profession, which is odd considering its usefulness in differentiating between those experiences that require a human touch from those that are more functional and mechanical.

It is my belief that without using such an approach, CX professionals will be left facing down a profoundly functional mindset from their Executive, Agile and Design teams.

The beauty of Cynefin lies, however, not in its support for CX but rather in its rigorous neutrality and application of the scientific method. It accepts all points of view (both functional and psychological) and bases any decision making on what is most relevant to the type of experience to hand.

Let's now look at the main component parts of relevance to CX:

It’s an obvious thing

Common example

A surgeon in an operating theatre counts the number of swabs used in a surgery to ensure none are left behind during the operation. If damage is done from leaving a swab in a patient, then the root cause is obvious. If we do it again then the same result will happen.

Customer experience example

In customer experience, if I phone up a call centre and the person is rude to me on the phone, I will put the phone down and not call again. The root cause to any loss of sale is obvious. If we do it again then the same result will happen.

Likewise, when I mapped the Stena Line customer journey, I noticed that customers would have to enter their mobile phone number into a screen before they could buy a ticket to Dún Laoghaire. The solution to forgetting your phone number is simple, go on to Irish Ferries website and buy your ticket. There’s an obvious root-cause to the loss of sale and the same experience will have the same effect time and again.

Change management example

On the face of it, I can sense (identify number of swabs), categorise (count swabs) and respond. A simple checklist would then be best practice. Fixed constraints would apply (a formal approach of compliance).

However, in the Stena Line example, effecting a change may not be so simple. For instance, the required code may be a complicated item involving changes in sprint plans; the Governance requirements that led to this experience may also be difficult to alter as they exist in the complex space. In this case, the reason for the experience being designed in this way was down to the beliefs of one board member who wanted to develop an SMS marketing list.

It’s a complicated thing

If my car had engine trouble with some investigation the root cause could be identified. If a worn-out part is found to be the cause, then we can say that the failed engine is down to a complicated reason. If it happens again the same result will arise.

Customer experience example

The same thing can arise in ‘the experience the customer has’. We can ingest data and through root-cause analytics define strong predictors of churn. For instance, 4 dropped calls predicts churn (EE). If this happens again the same result (churn) is likely to arise.

In other examples:

When I analysed narrative data from a sample of 1,500 customers in the Delhi circle for Bharti Airtel, I noticed how customers would state that early billing was a predictor of dissatisfaction.

When we reviewed the qualitative data coming back from a usability study, we found that one of the buttons was hidden to the customer, this was an important button for progressing any application and if not fixed would lead to failure.

With complicated experiences the effect is more hidden i.e., we have to perform predictive analytics to define it or we perform deep qualitative research. However, it is still a predictable effect.

Change management example

On the face of it, I can sense (identify number of dropped calls), analyse (conduct regression modelling on churn) and respond. A modelling approach would then be good practice. Governing constraints would apply (which involves the use of experts).

Any fix will involve once again decomposing elements into back of house requirements e.g., ‘code changes’ in the complicated zone (an IT engineer has to do something complicated that exercises their skills); ‘change management opinion’ in the complex space (IT culture has to absorb the customer point of view).

It’s a complex thing

This space differs from the other two.

In the complicated and obvious zones, the effects are replicable and can become known i.e..

· Leaving swabs in patients causes illness

· Asking for mobile phone numbers before ticket purchase causes a loss of sale

· A worn-out car part causes engine failure

· 4 dropped calls causes churn

· Sending out bills too early causes dissatisfaction with the service

· A badly positioned button causes a form to be uncompleted

The difference between obvious and complicated is really one of degree. It takes more effort to find the relationship in the complicated space but nonetheless it is of the same order of replicability.

The complex space is different. It takes a little bit to get so I will explain by analogy:

When travelling by plane I want it to be easy to board. However, an abstract value such as easy to board holds a multitude of problems i.e., it's not so easy to define one consistent root-cause such as we find with linear causation (hidden button prevents use; inability to put in mobile phone number prevents purchase).

The concept of ‘easy to board’ like so many other things in customer experience is what’s called an emergent property. It emerges from the experience as we experience it, in ways that are sometimes difficult to predict.

So, a few years ago I went to board a plane travelling to Sweden. The luggage compartment above my seat was empty so I put my bag in. The person sitting next to me then proceeded to stand up and pull my bag out and put his own bag in its place. Furthermore, he already had a bag in the compartment and was simply using up two spaces for himself. Cue nasty argument.

Now we can see variations of this situation: I could have laughed it off and given my bag to the air staff; he could have said sorry mate, you're right I have two bags, I’ll keep this on the floor; or I enter the plane and the compartment was full and I was none the wiser.

My point, this experience is unlikely to exactly repeat in the same way again, we cannot predict it. So to manage it and other such instances we can only ever be sensitive to such things in the moment as they affect ease of boarding (and levels of happiness)!

We could go on and on with such examples. Novel situations, new variants on an old theme are all around us. Have a go and think about examples for yourself.

I would argue complex situations are the heart and soul of customer experience and to take a systems thinking, mechanical engineering only approach to CX courts disaster.

Change management example

On the face of it, I can probe (see what happens when I do something i.e., run a test, after all who knows what the result will be if I do something novel unless I do it), sense (identify what happens) and respond. A testing approach would represent 'emergent practice' and enabling constraints would apply (involving the use of informal and diverse networks of opinion i.e., co-creation).

Any fix to ease of boarding will of course no doubt require a mix of actions. We could create a learning system (complicated zone); we could build in a voice of employee or customer system that helps alert us to these events (complicated zone); we could go beyond 'build' and ensure that our daily actions reinforce through conversation and awareness these effects (complex zone).

Some may counter that we should in fact systemise these situations (turn a complex thing into a complicated one) but for me this is constraint. So a manager may say, no one can take personal luggage on board as a rule. That resolves one thing but leaves us open to another. What if I had to take medicines on board, I may not want this and purchase tickets from a different airline.

Management implications:

Both obvious and complicated are clearly examples of systems thinking. They deal in fixed closed environments. You can set an end-state (mend my car, complete swab count) and close the gap between where you are now and where you want to be. ROI is predictable since we are not dealing with changeable, moving parts.

Complex situations are different and require sensitivity to the emerging moment. We don’t close the gap between a defined end state and where we are today; instead we access the direction we would like to go, and be sensitive to managing change on the fly and in the moment (ongoingness). Looking for the adjacent possible.

Finally, I end with some practical things you can do in your CX teams:

Create 2 Cynefin boards:

1. Customer Value Cynefin Board

2. Business Value Cynefin Board

Identify the experience in question from the customer’s perspective (such as ‘I can’t buy a ticket without putting in my mobile phone number’) and plot this on the Customer Value Cynefin Board. In the business case, identify customer value (lack of convenience) and business value (loss of revenue).

When you are ready, MOSCOW prioritise the ideas with your co-creation team. Then place the prioritized ideas onto the Business Value Cynefin board and decompose the change elements.

Obvious and complicated actions will be about 50% of your ideas based on prior experience. Of the complex ideas, make sure you engage different processes of change management i.e., small lower energy interventions, co-creation amongst stakeholders, sensemaking and r-intervention. Ideas that shift the direction of travel through being sensitive to what happens today.

If you want to know more about applying Cynefin in customer experience, the implications for measurement, design and the different processes to apply in the complex space drop me a line.

203 views1 comment