This entry is part of a multi-post case study.
So, you’ve defined your problem; well done! Now you need to look for its root cause(s). We’ll use a specific type of issue tree: a why issue tree (or diagnostic issue tree).
Issue trees help you be exhaustive in your thinking process—by helping you identify all possibilities—and efficient, by considering each possibility only once. So building a why issue tree is an essential part in the resolution of any complex problem. (Here is a basic explanation of issue trees).
As issue trees dissect the key question in its components, perhaps their most important part is the left-most node: how you breakdown your key question into its different parts, so be ready to spend some time on that.
Think about various way in which you can breakdown your problem
In most cases, you can breakdown your key question in more than one way.
In this example, we can break the key question (“Why does it take so much time to close negotiations with our cable providers?”) in at least three manners: by owner (because we prevent the close vs. because the providers prevent the close), by attribute of the value proposition (because we can’t agree on the price vs. because we can’t agree on the offering), by stage in the process (because we don’t plan the negotiation well vs. because we don’t execute the plan well), etc.
Be innovative so that you come up with various potential breakdowns. It’s in your best interest to come up with as many of those as possible; at this stage, as long as they are MECE (or, more precisely, ICE), they are good enough.
Once you’ve developed several potential frameworks, you need to select the best. So… how do you define “best”?
Select the most insightful breakdown
The answer is, choose the most insightful breakdown, as in, choose the breakdown that bring the most value in this particular situation. Just to be clear: this is very problem-specific. You can have very similar situations and find that in one situation one breakdown works better and, in the other, have the second breakdown work better.
As an illustration, consider the old joke of the driver of a car asking a passerby where she is and his reply: “in a car”. The answer is funny because, although it is technically correct, the answer isn’t insightful at all; that is, it brings no value to the driver.
Or, at least, that’s the premise in 99% of the cases. But remember that we don’t know anything about the situation. What if the driver had just fainted? What if she had just been in an accident? Would the insightful answer now be directions, or would it be to tell her she is in a car?
We’ve talked in other posts about how problem-solving is an art that requires you to exercise good judgement. This is one stage of the process where you need to apply your good judgment. So, to help you choose the best potential framework, you need to understand the implications of your choice, i.e., ask yourself the respective “so what” of your candidate frameworks. (It might be useful to write down the implications of your frameworks and to spend some time thinking about them—as well as asking friends/coworkers what they think and let it sit for a few hours so you get some perspective.)
In this particular example, we went with the first framework. I’ll show how the logic tree developed in another post.