Start with the main point, organize logically, and communicate complex ideas with clarity and impact.
When a Fortune 500 company is stumped by a complex business problem, who do they call? They call a strategy consulting firm like McKinsey, BCG or Bain, and somehow they solve it. But how? It’s not necessarily because they are smarter or know more about the industry than the client. They often don’t. Rather, it’s because they have a systematic approach to problem-solving. The method is highly sophisticated, rooted in logic and the scientific method, but it is packaged in simple principles and useful tools like issue trees and hypothesis trees. Consequently, any business can adopt the method to conduct better research and make better decisions.
Great problem solving has never been more important for business and society. The problems facing mankind are larger, more complex, and moving faster than ever before. Complex problem solving is the key skill for all businesses, and the common thread that runs through all the types of work that humans do in the modern workforce.
The consulting approach to problem solving (CAPS) is versatile and powerful - today, consultants are just as likely to be hired to help a country’s public health system prepare for the next Ebola outbreak as to develop a digital marketing strategy for a new consumer product.
CAPS was developed at McKinsey and has been used heavily at that firm and other management consultant firms for decades. The method is supported by decades of real-world application in real consulting cases, as well as solid intellectual foundations. It draws heavily from René Descartes’ “methodic doubt” which encourages independent thought and a systematic search for certain truth (from first principles). Descartes four directives from “Discourse on the method” summarize much of the CAPS:
Many books have been written about CAPS, including *Bulletproof Problem Solving*, *The McKinsey way*, and *Cracked it!* In this post I will explain the methodology with reference to the seven step process laid out in Bulletproof Problem Solving, with some ideas from other sources, and elaborating on some key points.
Precisely defining the problem you are trying to solve is the sine qua non of good problem solving. Poor problem definition is the cause of a surprising number of failed projects. Before data gathering, expert interviews, etc. you have to clearly define the problem you are solving, the boundaries, the criteria for success, and the level of accuracy required.
Any problem of real consequence is too complicated to solve without breaking it down into logical parts. Consultants use logic trees of various types to break up a problem in order to see different pathways to solve it, prioritize issues, and enable delegation. Logic trees are just structures for seeing the elements of a problem in a clear way, and keeping track of different levels of the problem.
The process of creating a logic tree structures the team’s thinking, and once it has been created it serves as a map of the problem that gives the team a shared understanding of the problem. Consequently, it is worth the initial time investment - a problem well defined is a problem half solved.
There are many different logic trees for different types of problems and different stages of the problem solving process, but by far the most frequently used and general-purpose trees are issue trees and hypothesis trees.
[2 pics here]
An issue tree is used to break down a problem into causes of (problem tree - example 1) or solutions (solution tree - example 2) to the problem, proceeding from the highest level and going into increasing detail from left to right. The purpose of the issue tree is to enumerate all possible solutions or causes of a problem in an attempt to find the root cause(s) or best solution(s) - i.e. explore the whole problem/solution space. Consequently, you need a principled breakdown rule to make sure nothing is left out. Consultants swear by the MECE rule - branches must be mutually exclusive (non-overlapping) and collectively exhaustive (cover every possibility). [Explain with reference to example above].
An issue tree is quite general purpose and is a useful tool for various methodologies and philosophies, such as [root cause reasoning](https://coda.io/@ross/root-cause-reasoning), Socratic questioning, “five whys”, Ishikawa diagram and first-principles thinking.
Once the issue tree has been created, the work proceeds from right to left. You start working on the outermost leaves and then synthesize findings at higher and higher levels of abstraction (more on that later).
In any case, the issue tree is often used early in the problem solving process to explore the problem/solution space, and hopefully come up with a few potential solutions (hypotheses) to test rigorously with a hypothesis tree.
A hypothesis tree starts with a claim or hypothesis (e.g. a proposed solution to a problem) at the root, and breaks it down (repeatedly) into what must be true for the overall conclusion to be true.
Each layer of the tree consists of arguments with premises that support the conclusions in the previous layer. In that sense, it can be thought of as nested logical arguments.
For example, in this example, the overall conclusion “Pioneer Bank can increase sales-force productivity” rests on the assumptions “Pioneer can increase selling time as a proportion of total available time” and “Pioneer can increase sales volumes from available selling time”. Those assumptions rest on some further assumptions. For example “Pioneer can increase selling time as a proportion of total available time” rests on the assumptions “Pioneer can transfer or outsource many non value-added tasks” and “Pioneer can reduce or eliminate many non-value-added tasks”.
At the core, issue and hypothesis trees are the same, but they differ in content and purpose. The structure is the same. The structure is a tree of issues, connected by logical operators.
Issue trees are essentially logic trees where every operator is OR. The solution to housing affordability is Increase Supply OR Manage Demand OR Financial Assistance Programs.
[picture]
Hypothesis trees can have a range of logical operators from formal logic. AND, OR, XOR (exclusive or), SOME, ALL, etc. A hypothesis tree is fundamentally a set of nested logical arguments.
[picture]
In most visual representations of logic trees you don’t see any logical operators. Implicitly or by convention the logical operator is AND (for hypothesis trees) or OR (for issue trees). With Descartes, you can state the logic clearly and thereby create more powerful logic trees.
Although you want to disaggregate the issues in a complete, MECE way in order to cover every aspect of the problem, you may not need to or have time to work on every part. Thankfully, the tree serves as an overview of the problem, so you can prioritize what parts to work on and the order you go in.
McKinsey-ites use the phrase “don’t boil the ocean”, which means: don’t try to analyze everything. Be selective; figure out the priorities of what you are doing. Know when you have done enough, then stop. Otherwise, you will spend a lot of time and effort for very little return, like boiling the ocean to get a handful of salt.
Specifically, not boiling the ocean can mean for example:
- Being selective about what branches of the issue tree to analyze in depth. You can use intuition to surmise that a branch is low-impact. For example [picture]
- Using a hypothesis tree to test a specific solution, rather than exploring every possible solution. McKinsey gathers enough facts to prove or disprove a hypothesis or support or refute an analysis — and only enough facts.
- Performing analyses in the most efficient order, for example by doing knock-down analyses that either immediately refute a hypothesis, or rule out some branch of the tree, etc.
Generally, the impact of different issues on a problem is Pareto distributed (80/20 rule) - a few issues have a high impact, and the rest are low to medium impact. Consultants recognize this, and don’t waste their time doing thorough analysis on issues that they believe are low impact. With Descartes, you can assign impact to different issues, in addition to other project planning features.
[picture]
Consulting firms have excellent processes for getting the highest quality of work out of their teams. Two of the key ingredients are brainstorming and being hypothesis-driven.
After the team has done some initial research and familizarized themselves with the problem, they start brainstorming. Everyone comes into the meeting with a “fact pack” with their findings, which everyone reads, and then they bounce around some ideas and disaggregate the problem in various ways. In many cases, the discussion is centered around hypotheses. Each participant comes in with an initial hypothesis which they present and refine as a group.
Moreover, suppose a team of McKinsey consultants is brainstorming the Teleco customer retention problem shown above. Most non-consultants would just shout out some ideas and write them down on the whiteboard.
Consultants, on the other hand, break down the problem systematically into categories of causes, and use that map of the problem to drive the discussion.
With Descartes, you can use a Miro-like canvas for breaking down problems visually in a team meeting. Whiteboard also works fine for the brainstorming part, but a digital solution might be better in many cases, for example if people are participating remotely.
Using logic trees during brainstorming has some advantages over more unconstrained brainstorming.
Consultants are hypothesis-driven and end‐product oriented. They use strong hypotheses to guide workplanning and analyses. This doesn't mean they are trying to prove the hypothesis in spite of the facts. Just the opposite: Strong hypotheses are easier to challenge and pressure test. Vague problem statements don’t drive action or analysis.
Using a hypothesis tree is very effective at triggering this mindset shift and countering confirmation bias and other cognitive biases. A hypothesis tree forces you to separate reasoning from facts, and follow the evidence wherever it leads.
They also use various other techniques which show their commitment to truth-seeking and avoiding bias. For example, team members have an obligation to dissent if they disagree, no matter who they are talking to; they use the dialectic standard of thesis, antithesis, synthesis - meaning, no idea can go unchallenged, it must be challenged and then refined; and they have teams with diverse viewpoints.
Logic trees can get complicated. You need a work plan to assign responsibilities, set deadlines and expectations, etc. You can plan it with a project management tool and follow typical project planning principles. In many ways, logic trees make project planning easier, especially if you follow some best practices specific to logic trees.
First of all, logic trees help drive alignment by giving everyone on the team a shared understanding and overview of the whole problem. Moreover, the workflow of starting with analyses at the leaves and proceeding to the left in the tree, synthesizing overall findings at increasing levels of abstraction, ensures that individual contributions converge into a coherent whole.
The picture below illustrates this point. On the left is a cloud of confusion, unstructured facts and questions, ill-defined roles. On the right is a logic tree where the branches of the tree are a place to attach knowledge and analyses, like a clothing rack is a place where you can hang up clothes; and where you can easily delegate tasks to different people and synthesize the overall findings.
Thinking of the tree as dynamic, not fixed - something that you iterate on based on findings and fill out gradually as your knowledge increases, is key to understanding the workplanning principles that apply to logic trees specifically.
We find there is great clarity in stating what you know about your problem at any point in the process. It helps bed down what understandings are emerging, and what unknowns still stand between the answers and us. We call this a one‐day answer, and they convey our current best analysis of the situation, complications or insightful observations, and our best guess at the solution, as we iterate between our evolving workplans and our analysis. By working this way we can divert resources to areas where we have the biggest gaps in problem solving and shut down analysis that is not taking us anywhere. We contrast this approach with typical efforts that encourage gathering huge data sets and endless interviews before problem solving starts. As analysis results come in, we can refine our one‐day answers and begin to synthesize our evidence into more complete stories.
Because rigorous analysis can be time-consuming, you start with an uncertain “one-day answer” based on rules of thumb, educated guesses, or simple analysis. Then, you progress gradually to more certain answers with more thorough analysis.
With Descartes, this workflow is built into the app. Issues have properties like “Status” which indicates the degree of certainty of the answer. From “one-day answer”, to “in review” to “complete”.
[picture]
The logic tree is always provisional and subject to change. Sometimes the approach to solving the problem can change dramatically based on one fact that you discover.
Descartes has version control built in - meaning that every change is tracked. You can create milestones at pivotal moments, e.g. before a major change, to have an overview over the progression of the project.
At the leaves (i.e. the outermost “nodes”, all the way on the right or bottom, depending on the orientation of the tree) of the logic tree are specific, testable sub-issues or sub-hypotheses that can be investigated with some analysis or research. You should break down the logic tree to the point where that sub-issue or sub-hypothesis can be addressed with some specific piece of work which reasonably answers the question.
[picture]
For example, suppose the logic tree above stopped at “Liters of fuel per km flown has risen” and an analysis was performed that confirmed the claim. That confirmation would immediately beg the question “why”, so it doesn’t reasonably, independently answer the question. In contrast, consider an analysis showing, for example, that the airline is now flying shorter routes on average, and consequently, the impact of takeoffs on fuel consumptions is greater than it was before, thereby reducing the overall fuel efficiency on average. Such an analysis is independent and reasonably answers the question. It is also insightful and a piece of the puzzle that you can use to piece together the big picture.
The work that you might do for an analysis is varied and of course depends on the problem. You might use statistics, data analysis, internet research, excel modelling, or whatever else. You can learn more about the techniques that consultants use [here] (?), but it kind of falls outside of the scope of logic trees and is a separate matter.
However, one important principle to keep in mind is to do complex, time-consuming analysis sparingly, and only when necessary. Start with an analysis to get an imprecise order-of-magnitude answer or uncertain answer, and then perhaps do more complex analysis afterwards.
With Descartes, you simply get an empty document to write your analysis, as well as a place to put web sources and attachments (e.g. excel files or whatever else).
[picture]
A logic tree is a tool for doing research, but it also provides the structure for the communication that comes later. It structures the thoughts in a pyramidal shape starting with the conclusion, followed by key arguments, and then detailed information. This is in line with the Minto pyramid principle of communication, which we’ll get back to in a moment.
In any case, once the tree is filled out, the report writes itself. An anecdote from Bulletproof Problem Solving shows the power of logic trees for structuring communication: “[Charles] got on a plane to Calgary for the first meeting with the client and found himself sitting next to the senior partner on the project, who nodded a greeting and went back to his work. He was furiously scribbling on a pad of paper and ripping off the sheets. When Charles worked up the courage to ask what he was doing, his colleague answered, “I am writing the final presentation.” Final presentation? How could that be? They hadn't even met the client. He answered, “Look, I know my hypotheses are early stage and some will be wrong, but if I guess at the answers now, I'll know what questions to ask the client when we meet their team.” And he was right. Imagining a set of hypotheses allowed the team to begin focused data gathering from the first meeting.”
[picture]
A logic tree is inherently also a Minto pyramid. The shape and contents of the logic tree (=Minto pyramid) precisely resembles the reasoning that got you to the conclusion. The purpose of a consulting presentation or report is to recommend some action and present the reasoning for why. Presenting the reasoning clearly with a good structure (e.g. with a Minto pyramid) is crucial for making the communication clear and understandable.
[picture]
A Minto pyramid is a pyramid of ideas, where the higher up part of the pyramid has a conclusion of the overall idea, and directly below is a set of ideas that support the conclusion above. It can have arbitrarily many levels. Higher up in the pyramid, ideas are expressed at a higher level of abstraction. That abstraction is a synthesis of the information presented below. Further down in the pyramid, ideas are expressed in more detail.
Take the example above. Suppose the executive asked the consultants why they recommend buying the Leyland Franchise. They might give a quick answer with the three main supporting arguments (shown in the second layer of the tree) - this answer will be a synthesis of the overall argument at a relatively high level of abstraction. Then he might inquire further about one of those reasons, and the consultants will give more detailed information (at a lower level of abstraction). Very often, executives only care about knowing the high-level abstracted version of something. So if the information is synthesized and abstracted at different levels, they can get the information they need at whatever depth they care to know about.
This is no different than how good communication should be anyways. (The Minto pyramid/logic tree just forces that structure more explicitly.) The degree to which the writing corresponds to the core logic that got you to the conclusion determines how clear it is for readers. Good writers more or less follow this format. Their paragraphs might consist of three clearly stated main points. Their chapters might consist of three to five clearly stated main points (in the form of paragraphs or sections). And so on.
Logic trees and Minto pyramids are closely connected. If you simply turn a logic tree on its side, you have a Minto pyramid. It starts with the conclusion, followed by key arguments, and then detailed information.
Consequently, an executive can either read through the logic tree directly, as if it were a report, or you can easily convert the logic tree into a report or presentation manually or with the help of AI.
Descartes makes it easy to do both.
[picture]
This view mode of the tree is suitable both for making/writing logic trees, but also for reading through the reasoning as if it were a report. At every level is a preamble, key ideas, and a conclusion block. The conclusion block is for synthesizing the ideas at that level of abstraction. This structure for the logic tree (with a conclusion block for synthesis) makes it completely equivalent to a Minto pyramid.
It might be necessary in many cases to communicate with a regular presentation or report. Given the similarity in terms of content and structure, this can easily be done with AI.
An AI generated presentation for the “Purchase a large British Leyland Franchise” logic tree above might look something like this. The structure of the tree is indicated at the bottom.
[picture]
Different rhetorical techniques are appropriate for different audiences. Business meetings are often dry, logical and information-dense. That makes sense, because you’re just presenting information. Our AI presentations will probably be limited to that presentation style. If you want to make fun and engaging presentations for different audiences, you can do that manually. Nonetheless, it is probably smart to have the solid reasoning at the foundation, and then just tweak the rhetoric.
Finishing up, here is some general advice on problem solving.
We hope this guide has provided you with valuable insights into the consulting approach to problem solving. By following these steps and utilizing the tools and techniques discussed, you can tackle even the most complex problems with confidence and precision.
The consulting approach is all about structured thinking, disciplined analysis, and effective communication. It emphasizes the importance of starting with a clear hypothesis, breaking down problems systematically, and iterating based on findings. By incorporating these principles into your workflow, you can ensure that your problem-solving efforts are both efficient and impactful.
Remember, the key to successful problem solving lies in the details. Take the time to thoroughly understand the problem at hand, gather relevant facts, and perform targeted analyses. Use tools like hypothesis trees and issue trees to structure your thinking and guide your work. And don't forget the importance of effective communication – whether you're presenting your findings to a client, a stakeholder, or your team, a clear and well-structured presentation can make all the difference.
Thank you for taking the time to read this guide. We hope you found it informative and useful. If you have any questions or need further assistance, please don't hesitate to reach out. Happy problem solving!
Powerful, self-serve product and growth analytics to help you convert, engage.
Dive into the heart of innovation with our 'Coding Chronicles' blog section. Explore a rich tapestry of articles, tutorials, and insights that unravel.