I just finished reading a very interesting book about problem solving, by Nat Greene. The book is titled, Stop Guessing: The 9 Behaviors of Great Problem Solvers (the hyperlink takes you to this book at Amazon.com). It is available in print, ebook, or audiobook.
I really like this book and the behaviors it teaches. This would be a great book for managers from first-line to CEO level. The author explains clearly why so many popular problem solving methods are weak in the face of hard problems: those methods tend to encourage wild and random guessing of possible causes. This leads to incredible amounts of wasted effort, as each possibility must be chased until it can be fully eliminated. Obviously time, money, and the energy of people will get wasted chasing these fruitless branches on a problem solving tree.
One could make the argument that any problem hypothesis is a “guess” but that is not true if you are using reasonable and scientific methods to create an up-front problem statement. A well-defined problem statement is going to lead you to far fewer possible causes and will give you a clear path to quickly establishing the stuff that you did not know at the beginning about the problem.
Perhaps one reason guess-based problem solving is popular with many managers is that they find themselves confronted with too much that they don’t understand. So they will call for a “brainstorming” session where no ideas are considered bad ideas. Unfortunately some ideas are bad ideas and most brainstorming is just a further waste of time and energy for the responsible engineers; but it can make some managers feel useful. Nat Greene has an excellent answer for this: his 3rd behavior is to Embrace Your Ignorance.
The author’s 7th behavior is to Believe in a Simple Solution. I needed to re-phrase this idea a couple of times before I could come to agreement with this behavior. Perhaps it could be expressed as that we should trust that most problems have simple solutions. I don’t want to get into religious arguments as part of my problem solving, so words like “believe” sound too much to me like faith, not science based problem solving.
I am raising a very minor word choice question here. It does not detract from the validity of Greene’s 7th behavior: when you have drilled deep enough to where you can actually see the problem, you will very likely find a simple fix for that problem. Yes, some hard problems are many-layered onions that we have to peel. As each problem is isolated and identified, we fix that problem (probably with a simple solution) and then move on to the next problem.
As an engineer who has mostly worked on the design side of electronic products, I constantly deal with the possibility that there are nearly an infinite number of valid solutions to some problems. Some solutions are just better than other choices. Some solutions fit the constraints of the problem better. These might be size, cost, power consumption, thermal performance, relative toxicity, or lots of other possible restrictions placed on the product you need to actually deliver.
Thus an important part of the design process is optimizing my choices within the curves and shapes that define the universe of valid solutions. I trust that a simple solution can be found, but that also means I will test and re-test that simple solution against all of the requirements and constraints of the project. You should too.
The author’s 8th behavior (and corresponding Chapter 8) is to Make Fact-Based Decisions. This chapter cemented my positive impression of the book. In multiple examples, he demonstrates the power of fact-based decisions and shows the weaknesses of opinion-based decision making.
Finally, in Chapter 10, Nat Greene touches on a specific method he uses for problem solving, Variable Analysis. I have not studied nor used this method enough to comment based on experience, but at first glance, it is a method that requires fact-based and thinking-based solutions. Instead of blindly following some specific dance steps, the method forces you to document and think about what you are trying to accomplish. Sounds like some pretty good problem solving to me.