#54: Problem Solving – Solving the right way

Last week, I talked about the different types of questions and had ended with reasons on why it is important to ask good questions. I had ended with a discussion on what is perhaps the most important reason: ‘getting to the right problem to solve’. Not that you need a whole lot of convincing on that one. Generations of philosophers across cultures have discussed and debated on the importance of asking questions – something that we, as problem solvers, should be doing a whole lot more in organizations. Let’s now think about how to make sure that your teams are actually going about solving problems

Making sure the problem is being solved the right way

There’s lots of stuff out there on this topic – I don’t want to get too repetitive here. However, I will offer up four key design tenets that I like to follow to ensure that the teams are effective in the problem-solving process:

1. Slow down in the early stages so that you can use the front-loading to focus on the right problem. If you want to dig more on this, look no further than Daniel Kahnemann’s Thinking Fast, Thinking Slow

2. Try to put multi-disciplinary teams together so that your solutions are enriched by outside-in perspectives and you have a shot at avoiding the expertise trap. ‘Range’ by David Epstein is a fascinating study of how this is increasingly becoming important across industries

3. Watch out for biases – it is obviously impossible to completely get rid of all biases, but being aware of them is a good start. And the most common one, by far, is the ‘we have seen it before’ bias: and if nothing else, 2020 will have taught us how to steer away from this bias.  

4. Follow a structured approach – this one is obvious, yet not appreciated as much as it should. Problem solving has always been treated as an art – the narrative of the super-smart problem solver who swoops in as the hero to single-handedly solve the problem is pervasive across organizations. What we need instead, is a structured approach – the good news is that there are several methods that have been designed in the recent past. Pick one, run with it and customize for your organization

And to these, I would like to add a 5^th – moving ‘Upstream’.

Going ‘Upstream’ to solve problems

The idea here is intuitively obvious, yet hard to execute: instead of just trying to solve the immediate (downstream) problem, try to go to the root cause (upstream) and focus on solving for that. For example, trying to identify the customers who are at the highest risk of churn (say, non-renewal of subscription) is an important question to answer – but as any Account Manager would tell you, the value of the risk assessment goes down as the client gets closer to contract renewal. The goal then really should be – can you go ‘upstream’ and look for early indicators of risk, and then give the Account Managers enough time to execute strategies to mitigate them.

The challenge with this is obvious: there is a distinct advantage to solving downstream problems. Downstream problems are relatively easier to define; usually we have strong signals in data to be able to solve for them and in most cases, the feedback loop is much stronger. Customer churn risk prediction models tend to be more accurate as the customer get closer to renewal; likewise, risk mitigation strategies are easier to monitor and evaluate as you get closer to the renewal period. On the other hand, trying to assess the risk upstream – i.e. looking for early churn signals becomes progressively harder. In general, as you go upstream:

1. Problems are more diffused: It is harder to define the problem with clarity – e.g. what is the right proxy metric to track early warning signals for churn? If it is engagement – how do you define engagement?
2. The data becomes progressively noisy: to add to the low signal to noise ratio, the signals themselves tend to be underlying factors which are harder to discern – e.g. what are the right causal factors to use for early warning signals? You would want to use the quality of engagement interactions to understand the factors – but then how do you measure them?  
3. The feedback loop is not very clear: Let’s say you do figure out some behavioral signals and use that to drive some actions – e.g. Next Best Actions for the Account Manager’s playbook. How do you measure if these actions are effective?

These challenges notwithstanding, there is no doubt that there is enormous value in solving the ‘Upstream’ problems. I would strongly recommend that you constantly challenge your teams to go beyond the obvious, here-and-now problems to go upstream and look for ways to solve the problems when they are still vague and fuzzy. I would even lay a key design principle: The value created from solving a problem increases non-linearly faster as you go further upstream from the actual manifestation of the problem.

Related link:  Upstream: How to Solve Problems Before They Happen by Dan Heath