A discussion on the eleventh of fourteen tenets (or principles) of customer success management, as laid down in Chapter One of the book “Practical Customer Success Management”. The eleventh tenet is “The CSM is a Problem Solver”
The 14 Tenets of Customer Success Series – Tenet 11: The CSM is a problem solver
This short article expands upon the eleventh tenet (or principle) in my “14 Tenets of Customer Success” that are taken from my upcoming book “Practical Customer Success Management: A best practice framework for rapid generation of customer success” which is due for publication summer 2019…
Tenet 11: The CSM is a problem solver
In my book – Practical Customer Success Management: A best practice framework for managers and professionals – I set out 14 tenets (or principles) by which customer success managers can carry out their professional duties. All 14 of these tenets can be found in my LinkedIn article – The 14 Tenets of Customer Success – which can be viewed here:
This eleventh tenet is:
The CSM is a problem solver
Its definition is:
There are many potential barriers to customer success that CSMs may come across. These may relate to very practical problems such as a lack of information or insufficient resources, they may relate more to conflicts of interest and/or opinion between stakeholders, or they may come from outside the project itself such as a change in corporate strategy or a new piece of legislation. Whatever the situation, CSMs need to be good at viewing problems logically and rationally and determining the right course of action to overcome those problems.
Using Root Cause Analysis
The idea of root cause analysis is to determine the real or underlying cause of the problem, so that this underlying issue can be fixed and in so doing the problem can be resolved in a way that reduces the likelihood of its reoccurrence as much as possible.
For example if you have a headache then one possible cure for the headache might be to take a painkiller such as paracetamol or aspirin. This painkiller may well reduce or even entirely remove the feeling of pain that the patient is experiencing, but the underlying cause – the reason why they were getting the headaches in the first place – has not been dealt with. Perhaps this underlying problem will fix itself without any intervention needed, in which case all will be fine. If not however, then when the effects of the pain killer have worn off, the patient will be back again experiencing the same headache as before.
Perhaps the underlying problem or the root cause of the problem is discovered to be dehydration. If this is the case, and if the patient is rehydrated – for example by drinking a glass or two of water – then the chances are that over time the pain will go away without the need for a pain killer, since the root cause of the pain has itself gone away. Of course it is also entirely possible that even if as in this example the underlying problem is addressed, it might take a while for the effects of this fix to be felt. In our example it might take a while even after our patient has drunk the water for all the cells in the patient’s body to rehydrate back to their normal, hydrated state. In this circumstance, it might be a good idea for the patient to both treat the root cause of their problem by taking on liquids and also simultaneously treat the symptoms of pain by taking a pain killer. In this situation the existing discomfort associated with dehydration is treated as well as the underlying issue, so that the patient both feels well in the short term and continues to feel well in the longer term.
The following five steps can be followed by customer success managers to identify the root cause of a problem and resolve it:
Root Cause Analysis Steps
Here are the steps for using root cause analysis:
1. Define the problem and explain its impact
When identifying and defining the problem and the impact it is having, make sure you remain focused on the facts rather than emotions or opinions, and on describing the problem rather than jumping too quickly to solution mode. “The Five Ws” is one good way to define the problem (what, when, where, who, why and how).
An example of a well-defined problem would be:
5.1% of products sold are currently being returned by customers as faulty within the warranty period of 12 months. This level of returns is approximately twice the average for our industry as a whole of 2.6%. This problem is causing customers to be frustrated with our products and losing us an estimated $15m pa in repair and replacement costs combined with lost sales opportunities due to damaged brand reputation, compared with if our returns rate was at the industry average.
If relevant and desirable, you might at this stage provide a stop-gap solution or a “workaround” such as temporary hosting of a mission critical application at a third party datacentre whilst you get to the bottom of the problem that is occurring in your own datacentre, or the diversion of orders to another production line or even another factory whilst you work on getting the problem fixed on this production line.
2. Define the process
As you know from Module 2, there are three aspects of any business capability – people, process and tools. All too often the problem is blamed on people when really it is to do with the process, the tools or the training and support of the people, not the people themselves.
To identify what is happening (Step 1) or to start gathering information about the circumstances in which the problem occurs, the recommendation is for you (or someone) to actually go to the physical place where the problem occurs and either observe it happening or talk to the people who have observed it happening and record the process steps and if possible describe exactly at what stage the problem occurs and how it happens. Talk to as many people who are involved with the process as possible to get a rounded and three dimensional view of what’ happening. It may be useful to create a workflow diagram or simple process map that explains all the steps in the process and shows where the fault occurs.
The concept of physically going to the site of the problem is described as a “gemba walk”. The word “gemba” means “the actual place” in Japanese, and the concept comes from Lean Management best practices that dictate that managers who want to know what’s really happening need to get out of their plush offices, grab a safety helmet (if necessary) and go and take a walk around the shop floor where everything takes place – for example where the cars are assembled, or where the developers create the applications, and so on.
3. Identify possible causes
If the root cause of the problem is known then this step can be omitted and instead the root cause can simply be documented and the CSM can go on to Step 4. Assuming the root cause has not yet been identified, in this step the CSM helps the customer to consider and document what the possible causes of the problem might be. What’s needed is as comprehensive a list as possible, in order to increase the likelihood of the true cause having been identified and documented within that list.
The classic approach is a brainstorming workshop with as many different people as are useful. An idea group size for brainstorming is around 5 to 9 people, since generally speaking this provides sufficient energy and creativity in terms of ideas sharing, provides sufficient different perspectives, and yet remains manageable in terms of ensuring everyone attending gets opportunities for input into the conversation and where necessary consensus opinions can be reached.
To help the group consider all possible causes, it makes sense to break down the overall topic into more manageable categories that allow workshop attendees to focus their minds on just one aspect of the “system” in which the root cause of the problem resides. For example one category to discuss and consider might be “communications”, another might be “process documentation”, another might be “service and maintenance”, and so on. If you as the CSM are not sure what categories would make sense for the particular problem the brainstorming team will be working on, get a subject matter expert (for example the process owner) to help you formulate the list of categories to use.
Once all possible root causes have been discussed, identified and documented, you need the team to help you further by sorting the list of potential root causes to the problem into priority order, with the most likely cause at the top and the least likely at the bottom.
4. Identify and implement countermeasures
In this step you will go through the list of possible causes one by one, starting with the most likely cause. For each cause, you first need to identify one or more countermeasures (ie solutions to the problem) to try out. Sometimes the solution to implement may be obvious (for example if you’ve identified that the cause of the problem is a broken part then replace that part with a new one). At other times there may be multiple possible countermeasures to try. If this is the case then as with the list of potential root causes, you need to prioritize your list of countermeasures and try the best one first. In this instance the “best” countermeasure to try might be the most likely one to work, but you may also need to consider other factors such as cost to implement, time to implement, difficulty to implement and so on. It may sometimes make sense to try a simpler countermeasure (for example one that takes just five minutes and costs nothing) first, even though another countermeasure (one that perhaps would take several days of someone’s time to implement) might be more likely to resolve the problem.
If the necessary countermeasure turns out to take a lot of time to implement (for example perhaps you need to order a spare part, or perhaps you need to get outside expertise to assist with it) then you may want to consider a stop gap or interim workaround at this stage if you have not already done so.
Work through the list of potential solutions one-by-one. Unless you have a real necessity to do so, do not apply more than one countermeasure at a time, else you will not know which solution actually fixed the problem. This will make it harder to fix this or similar problems in the future if you encounter them.
As with any work, make sure you plan any solution implementation, obtain any authority to proceed that might be necessary, assign owners to take on the task and provide them with a deadline for completion and agree with them what “completion” will mean. Also make sure you have identified a way to take measurements to learn if the solution has worked.
5. Test for resolved
Once the solution is in place, test it by taking and then analyzing these measurements to determine if the problem has been fixed. If it has not been fixed, try the next countermeasure on your list. If the problem has been fixed then also check to make sure that the countermeasure has not produced any further problems to the system, and if all is good then document both the problem and the countermeasure for future reference.
Next Week’s Tenet: “The CSM is a pragmatist”
The next article in this series will be on tenet number twelve which is “The CSM is a pragmatist”. It is perfectly reasonable for customers to desire to see a return from their investment in our products/services. But sometimes the customer (or specific stakeholders within the customer organization) may have unrealistic expectations. Perhaps sometimes even our own colleagues may also have ideas that are impractical or unworkable for one reason or another. The CSM needs to remain realistic about what can be achieved within the timeframe, budget and whatever other resource and situational limitations exist.
About the Author
Rick Adams is an independent author, trainer and consultant, specializing in helping technology companies deliver measurable business value for their customers. Adams has over 25 years’ experience of working in the IT industry, including owning his own startup software-as-a-service business which he sold in 2012 to focus on writing, training and consulting. Having delivering training and consultancy to many hundreds of businesses and thousands of technology professionals in over 30 countries across four continents, Adams is now based in the rural west coast of Ireland where he lives with his two dogs Zeus and Terri.
Adams’ recent work includes the development and delivery of a global certification program on customer success management for Cisco Systems Inc. He is currently working on a book titled Practical Customer Success Management: A best practice framework for managers and professionals which will be published by Routledge in the summer of 2019. His current interests includes helping individuals and companies develop best practices in customer success management and in business outcomes focused selling.