Hey there 👋,

Welcome to the Empowered Leader Newsletter Article #2:

How To Solve Any Problem - In Business, In Consulting Cases, And Even In Life

September 19, 2022

You can read this article online here

In my introductions to people, I generally start by sharing my work superpower, which is: “solving any problem” that is put in front of me. When I first joined a start-up as the Chief Product and Strategy Officer, on day ONE of starting, the CEO said to me “JC, the CMO hasn’t shown up for work for a month, I need you to help out the marketing team.” This was a pattern over the subsequent 6 years and I worked on solving marketing problems, tech problems, operations problems and of course, people problems.

This article summarises my thoughts on how to solve problems, primarily at work, but can be applied to life and consulting cases as well.

What problems are we talking about?

According to the Oxford Dictionary, a problem is

noun: a matter or situation regarded as unwelcome or harmful needs to be dealt with and overcome.

In business, we are constantly faced with problems. Some of the problems I have solved in my previous start-up have been:

• How do we build a database of 1 million customers?
• How do we improve the conversion rates of our application form?
• How do we improve the reliability of our core platform?
• How do we drive down our marketing Cost Per Acquisition (CPA)?

In life, there are also problems to solve, and here are some that have come up in my life:

• Do I buy or rent a house?
• Do I take out a loan for my car?
• Do I take that extra holiday?

Do we need to solve every problem?

While we face problems almost every day, we don’t need to solve every single problem that arises. Often when I am faced with a problem, there are three questions that I ask:

• What is the size of the problem? (ie. how many instances have we seen?)
• What is $ cost of the problem? (ie. what is the dollar impact of this problem)
• What is the importance of the problem? (ie. will solving this problem bring us closer to our goals and objectives?)

The objective of these questions is to understand the materiality of the problem. The first two questions determine the urgency, and the last one is the importance. And can be put into a 2x2 matrix of Urgency vs Importance (also known as an Eisenhower Matrix).

I use this matrix in many areas, but in the context of problem-solving, this is how it breaks down:

• Urgent and Important

• Urgent = High frequency and high $ cost impact
• Important = Solving this problem will help to achieve or deliver a key objective.
• Outcome = Make this problem a high priority and drop everything to fix this. You shouldn’t have more than 1 of these to deal with on a daily basis (or even weekly).

• Urgent but not Important

• Urgent = High frequency and high $ cost impact
• Not Important = This problem may be a distraction or may solve a minor objective.
• Outcome = The question to ask here is whether you can reschedule this (sometimes you just need to let some fires burn), or delegate this to someone else.

• Not Urgent and Important

• Not urgent = Low frequency and low $ cost. These problems are low in materiality.
• Important = Solving this problem will help to achieve or deliver a key objective.
• Outcome = These type of tasks should be scheduled in to be solved. Sometimes if you don’t solve these problems they build up to become priority 1 problems later or they become road-blocks to you achieving your key priorities.

• Not Urgent and Not Important

• Outcome = Thes problems are distractions, avoid them if possible.

How do we understand the root cause of problems?

Often times, when a problem arises, it is usually a symptom of another issue. In order to stop more of these problems from arising, it is often important to understand the root cause of the problem, otherwise, we will keep just solving the symptoms instead of solving the root cause and not seeing those types of problems arise again.

The technique that I use is the “5-whys”. The way this technique works is that I keep asking “why” at least 5 times in order to dig deeper to understand what the source of the problem is until I am comfortable that I understand the problem and the root cause.

For example:

• Problem: Our call abandonment is extremely high. (Call abandonment occurs when a customer calls our call centre and then doesn’t wait till an operator answers the call)
• Why?
• Problem: There aren’t enough people for the number of calls.
• Why?
• Problem: Most people were on their lunch break at those times.
• Why?
• Problem: There was no visibility of when other teams were going on their lunch breaks.
• Why?
• Problem: No one was co-ordinating across the teams.
• Why?
• Solution: Setup a common roster to ensure there is sufficient coverage (team members) during lunch breaks to meet the demand (number of calls).

In this case, we needed only 4 “whys”, before we got to the root cause, and sometimes you may even need more. In some cases, the problem may also be complex and the “whys” may be due to multiple factors.

How do we think about what needs to be solved?

Once we understand the root cause, how do we think about solving the problem? Like anything else in life, there may be multiple reasons why the problem is occurring, and our job as leaders is to identify the solutions that will go the furthest in solving the problem.

The tool that I like most, in this case, is the Issue Tree. An issue tree is a way to visualise a problem and break it down into component parts that can be prioritised and solved one by one or work delegated.

At the highest level, this is what an issue tree looks like visually.

It is made up of:

• Main problem or hypothesis (a hypothesis is a proposition based on limited evidence, to be proven or disproven through the gathering of more data).
• Issues contributing to the problem.
• Sub-issues contributing to each of the issues.

These issues above have to be MECE. This is a term that you will hear a lot in consulting and means mutually exclusive, collectively exhaustive. The Collectively exhaustive part means that all the issues, in this case, have to cover every angle that contributes to the main problem.

For example, in the case of the call abandonment issue, there could be 3 main issues to the problem:

1. Lack of resources to answer the calls
2. Unpredictable demand
3. Technology issues

The three issues above cover all the possible angles to solving the problem.

The mutually exclusive part means that each of the issues shouldn’t overlap. This is where it gets tricky, but is a good discipline. For example, using the same call abandonment problem, if the issue list looked like this:

1. Lack of resources to answer the calls.
2. Unpredictable demand.
3. Technology issues.
4. Team members spend too much time on calls.

Issue number 4 above is actually a sub-issue of #1 above, and a part of it actually contributes to a lack of resources. This part is the trickiest, and getting the levels right and ensuring that each issue is mutually exclusive is a skill that you will get better at over time.

Once you have the issue tree drawn up and agreed upon, it is important to understand the priority of each issue. This is where you start to gather data for each issue, which then allows you to prioritise which one to start on. Sometimes, in an interview case study or in real life, you may not have the time to gather much data and you may have to make “educated guesses” based on hypotheses or on experience.

Where do we start?

OK, so now you understand the root cause of your problem, you have prioritised the problem and have visually mapped out all the issues driving this problem. Where do you start?

While there is no one 100% right way to solve problems, this is the approach that I have taken to solve a multitude of problems over the last 20 years.

If we think about a problem as a big block, it can be as overwhelming as trying to climb Mount Everest. So, therefore, the exercise of breaking a problem down into component parts (like an issue tree) helps us to “chunk down” the problem into smaller pieces. As the saying goes, “a journey of a thousand miles begins with a single step”.

And if I were to think about where to start first, I generally start at the highest level with the objective of understanding all the issues that are contributing to the problem. I would then prioritise each of the issues and then solve each issue from end to end, and then keep moving on to the next prioritised issue. In between, I would be testing, measuring, and learning after each week or after each issue was solved to see if I was heading in the right direction.

‍