In this post I describe an incredibly powerful problem solving skill every executive team should have.
Arguably, the most important thing any executive team can do is choose the direction of their company. Just like the captain(s) at the helm of a ship, once they set a course, the entire crew knows what to do. From this decision, all other action follows.
However, to do this properly, the executive team must have a masterful understanding of the complexity in front of them. This post describes a relatively unknown but incredibly powerful technique that can help with solving complex problems.
“Kosta, I already do this in my head”
Let me start with a story. I want to share with you some observations I gained from watching one of the most compelling executives I ever had the chance to work with. For the sake of anonymity, I’ll call him Paul.
Paul’s intelligence levels are off the charts. He was the top student in his high-school and studied engineering and math in college with top honors. He is a natural problem solver. The most extraordinary thing about his decision making style is his ability to gain incredible clarity of the big picture at 50,000 feet, but also the intricate tactical/technical details on the front-line of the company.
I watched him closely to see what I could learn. He spent a lot of time on the phone. Every day, he would call people at random throughout the organization to find out what they were dealing with, what challenges were on the horizon, and how projects were progressing. It was as if his mind was building a map of information, tracing the intricate forces of cause and effect at every level of the company. I could see that he was building a hierarchy by identifying top level issues that had an impact on overall strategy, secondary issues that affected execution, then tertiary issues which were being seen on the front line. Every time he had a new conversation, he would update the data in his mind, re-run the cause/effect relationships, and evaluate the implications.
This thought process made him an incredibly effective problem solver in unbelievably complex circumstances. He could think 6-12 months further into the future than anyone else in the organization and understood the intricate steps necessary to get towards his vision. He had the highest accuracy rate of any decision maker I have observed.
Paul’s fatal flaw was that he did this by himself. He would capture the information, solve a problem, and often announce a certain action to his team as fete accompli. Of course, the other intelligent and capable executives around him would often challenge his suggestions. But the problem was, they just didn’t have the context he did, and arguments would ensue. Paul would get very frustrated by the need to bring the rest of the team up to speed with his perspective. For a guy that liked to move fast, this was a waste of time. The result is that Paul had the ability to generate substantial resistance for his ideas and actions, even though he was right most of the time.
What Paul missed is that solving a problem by himself was only part of the answer. He needed to bring his team along for the ride. By making his mental process clear to others he could have made the whole team smarter.
If I had suggested he build an issues tree, he would have said “Kosta, I already do that in my head”.
What are Issues Trees?
An issues tree is a visual representation of the full set of challenges and issues a company is facing in order to achieve a specific goal. They start with a central question, and then break down into a hierarchical representation of issues: from strategic at the highest level, to secondary and tertiary issues all the way to intricate implications at the front line. Here’s a picture of an issues tree to illustrate the concept.
There are essentially two types of issues tree: Diagnosis Trees, and Solutions Trees.
A Diagnosis Tree answers the question “Why”? For example, “Why are customers churning away from our product?” or “Why are we not being successful raising capital?” Why trees end in the root cause of a problem. (As an aside, I have also built Diagnosis trees that are “What” trees, answering questions like “What is preventing the company from doubling its growth?”, and the branches of the tree focus on factors that impact the main question).
A Solution Tree answers the question “How”? For example, “How can we consolidate our product offering?” or “How can we increase total profit?”. How trees end with actions that can be implemented to solve a problem.
In either case, the trees are hierarchical. For example, a solution tree starting with the question “How can we increase total profit?” leads to (a) “How can we increase quantity sold?” and (b) “How can we increase profit margin per item?”. The secondary level item (b) then breaks down into (i) “How can we reduce fixed costs?”, (ii) “How can we reduce variable costs per item?”, and (iii) “How can we increase the price we charge per item?”
Why Do The Work?
There are several reasons:
1) You’ll get objective clarity about the nature of the true problem and it’s root causes or possible solutions
2) You can socialize with the team to improve everyone’s collective wisdom and avoid biases
3) You can identify hypotheses for solutions which can be tested with hard data
4) You’ll be able to generate evidence that a solution will in fact solve the problem
5) You’ll fundamentally master the complexity of the challenge in front of you
How Do You Build Them?
Issues Trees can be very difficult to build and require a lot of mental clarity to do them right. However, once done properly, they can become a foundation – a single version of the truth – which will release the full creative and problem solving power of a team. Building Issues Trees is a skill, but the process is well known and can be replicated.
Here are some practical guidelines on how to do it:
1) Find some mind-mapping software
You will need to graphically represent your tree. I use mind-mapping software and my favorite product is MindJet. Its one of the more expensive mind-mapping software products, but for exercises as important as solving strategic problems, the ROI is high. Don’t try to use a visual product like Visio, Illustrator or PowerPoint, they’re just not flexible enough. If you don’t want to buy software, there are also lots of free products out there to try. In my experience, MindJet is the best for this type of work.
2) Define a central question
The way the central question is defined is by far the most important part of developing an issues tree. I cannot emphasize this strongly enough. Misdefine the question you are answering and the whole process will be corrupted. More importantly, I have never encountered a team who got the question right the first time. There is always something that was missed in the original definition of the question, only later for someone to have an “ah-ha” moment that leads to the central question being rewritten.
Think of this example. If Sir Isaac Newton had observed the apple falling from the tree and asked himself “why did the wind blow the apple off the tree?” instead of “what force caused the apple to fall?”, he may never have discovered gravity. He simply would have been blind to the possibility of new invisible forces not yet described by science. The same applies for solving complex challenges – properly defining the central question is paramount.
Your key question should be a ‘big’ question and encompass all other questions. If you are having trouble fitting issues into your core question, try to define a bigger one. You may add a level or two to your tree, but that doesn’t matter at all. Getting the question right matters most.
3) Capture the full range of conceivable issues
The first tree you build will not be correct – it’s simply impossible to be right the first time – so your first objective should be to get as much onto paper as possible. Collect data and opinions. Write out nodes on the mind-map to capture everything that you can see. Include all opinions, irrespective of how diverse or relevant they may seem to be. The first objective is to go wide and cover the field, before going deep into the problem.
4) Structure issues into a hierarchy
Once you’ve captured the full range of conceivable issues in your first run at building a tree, you should go back and restructure it. Good Issues Trees start with a central question (on the left) and break down into increasing detailed issues (to the right). At the very end of the tree (most right) you should have data points which are observable on the front line. Each level of the tree should describe the previous level in more detail, and add value to it. At the end of the tree, you should have either run out of detail or essentially ‘completed’ the issue above it.
To make sure your tree is structured properly, for every node you should ask:
– Does this issue fit completely into the one above it?
– Do the issues underneath this one represent a complete breakdown?
– Have I duplicated any issues, and if so, where is the one place it should go?
– Are any issues too vague? Can they be clarified or made more specific?
One last point. If every level of the tree should have more detail than the one before it. You should never have an issue with only one sub-issue. If you do, something needs to be redefined.
5) Keep your discipline with Why’s and How’s
To be done properly, you should keep a discipline about how you build the tree. If you’re building a ‘diagnosis tree’, every issue should be a ‘why’ or a ‘because’. If you’re building a solution tree, every issue should be a ‘how’ or an ‘action’. One of the main mistakes of people new to the process is to combine ‘how’s’ and ‘why’s’ in the same tree. How trees will lead to actions that can be implemented, Why trees lead to the root cause of a main problem.
6) Check every issue is MECE (or NONG)
The best issues trees cover the whole issue exactly once. MECE is an acronym for “Mutually Exclusive, Collectively Exhaustive”. It’s the idea that you’ve covered every issue exactly once. Another way to say that is NONG, or “No Overlap, No Gap”. Here’s a visual representation of the concept.
Being MECE/NONG with an issues tree is critical. If you are sloppy with your definition of issues, you can create blind spots in the problem solving process. You may completely miss a critical issue, preventing the team from considering it when developing a solution. If defined correctly, you’ll be able to solve each issue exactly once, which is the ultimate goal.
Building an ‘exhaustive’ tree, one that has no gaps, is quite hard and takes some creativity. You have to think out of the box to capture all possibilities, and you might have to fight against some of your own biases to make sure you include issues that you don’t think are relevant. You might prove yourself right, but it’s best to include every issue and test them later.
Creating a tree with no overlaps is just as hard. Each issue needs to be defined crisply so that it can stand alone. Having duplicates of an issue means something has been defined incorrectly. In my experience, this is the part that takes the most practice and it helps to get feedback from the team to find areas where overlaps exist.
7) Socialize and improve
Socializing the Issues Tree empowers your team to diagnose/solve a core problem. It’s not a solo exercise. Send your draft around and ask people to help you improve it. Every time I have done this I have found that people around me can see my own blind spots and add detail that I didn’t or couldn’t contemplate. Similarly, every time a new piece of information comes to light, make sure you include it. Every addition improves the overall power of the team to master the complexity of the issue you’re trying to solve.
This technique has powerful applications on a wide range of crucial strategic issues that companies face. Consider these questions:
– How can we increase overall profitability?
– How can we reduce our production cost?
– How can we increase conversion rates on our website?
– How can we enter the [new country] market?
– How can we improve our company culture?
– Why is our production process slow?
– Why are employees not behaving in accordance to our defined values?
– Why are our customers churning away from our product?
Notice the relative ‘size’ of some of these questions. Strategic and tactical issues can all be solved using this approach. The list of possibilities is limited only by your creativity. It’s an incredibly robust and powerful tool when used correctly, and that’s why it’s a skill every executive team should have.
Revisiting Paul’s Fatal Flaw
Paul did all this work in his head. He was a master at it and it made him an incredibly effective problem solver. If he’d gone through the process of reducing his thoughts to writing, not only would he have been able to learn from his team (and therefore be more right), but he would have brought his team along for the ride. Together they would have been a more powerful combination and fully aligned to a strategic direction.
While I have been using this technique in my own work and companies over the past few years, I have recently found an in-depth resource which walks through the process in detail. If you like this article and want to know more, check out this website. The author Arnaud Chevallier does a great job of going into the details of the technique, and here’s a link to one of his very good PowerPoints on SlideShare.
I encourage you to give the technique a try – and if you have comments or thoughts, I’d love you to share them in the comments below.