Issue trees are basically maps of problems. They give you a clear and systematic way of looking at the problem you need to solve. They help you break down a big problem into smaller, more manageable ones, and prioritize certain parts of the problem. In other words, they're useful for the "divide and conquer" strategy.

Issue trees are also great for communicating about a problem with others since they provide a map of the problem.

There are two basic kinds of issue trees:

1. Problem trees – created by answering "Why?"
2. Solution trees – created by answering "How?"

How to create an issue tree

Problem tree

A good issue tree must cover the whole problem. It has to be rigorous. Here are some basic principles for creating an issue tree.

1. Start breaking down the problem into separate categories/branches.
2. Use the MECE principle: mutually exclusive, collectively exhaustive. 
   • Mutually exclusive means there is no overlap between different parts of the tree. Collectively exhaustive means they cover the whole problem.
3. Do not go into the small details (specific hypotheses): focus on capturing the broad categories that make up the problem.
4. Apply the 80/20 rule: focus on the few parts of the problem that are most impactful.
   • This is best to base on data, rather than your own hypotheses. 

Solution tree

When you have singled out some specific parts of the problem that you want to focus on, you can follow up with creating a solution tree.

1. Take the problem part you want to focus on and ask "How might we improve/fix this?"
2. Map out potential categories of the solution
3. Generate ideas within each category

The advantage of this structured way of thinking is that working with constraints will actually help you generate more ideas.

Example

Let's see an example of creating an issue tree. Suppose you're working on a product and you're seeing customers not adopting one of your key features. That will be the tree starting point.

We'll break it down to smaller branches that cover possible causes:

• Low adoption of feature X
  • Customers don't know about the feature.
  • Customers know about it, but still don't use it.

For a first level of the tree, it's incredibly basic, but it's actually MECE – it's mutually exclusive yet covers the whole problem.

Branching out further, we can eventually get this tree:

• Low adoption of feature X
  • Customers don't know about the feature
    • The feature is not discoverable in the product
    • Customer's don't learn about the feature outside of the product
  • Customers know about it, but still don't use it
    • Customers haven't tried it yet
      • They don't believe the feature can help them
    • Customers tried it but decided not to use it
      • The feature is not usable
      • The feature is not working properly
      • The feature doesn't support customer needs

We could investigate even further, but already we can see which part of the problem to start with. In this case, focusing on the knowledge about the feature should be a high priority – there might be nothing wrong with the feature, customers just don't know about it.

This is a nice example of how a very simple issue tree can help you break down a problem and give you a starting point for solving it.

Takeaway

Issue trees are a great tool for approaching problems systematically by breaking them down. You can create problem issue trees (by asking "why?") or solution issue trees (by asking "how?") depending on where you are in the process of problem-solving.