The McKinsey Method

The McKinsey Mind talks about McKinsey’s Fact-based, hypothesis-driven, structured problem-solving process

Why structured? Structuring an ambiguous problem statement into smaller components can help you communicate ideas clearly and effectively, as well as enabling you, your client, and your teammates to work together to solve it using facts and logic.

Why use a hypothesis-driven approach? Starting from the end and working backward is often easier than trying to find the perfect answer. It provides direction for your analysis and allows you to objectively evaluate multiple options quickly.

Why focus on facts? – Facts help to build trust with the client, and can help to make up for the consultant’s lack of experience and intuition compared to an executive with many years of business experience.

Framing the problem

Break the problem into distinct, non-overlapping components (MECE) and document them in a logic tree. This tree should list all components from the highest level view to the lowest. Additionally, don’t take the client’s diagnosis of the problem at face value; investigate further.

Determine the boundaries of the problem by eliminating unimportant factors and prioritizing the remaining ones.

Formulate a hypothesis based on existing facts and further research. Construct a hierarchical tree of questions and sub-questions by asking:

• What assumptions must be true for this to be a viable option?
• Are there any reasons why this option won’t work?

Brainstorming is encouraged; everyone should come prepared, having studied all facts and pondered their implications. The goal is to generate new ideas.

Finally, avoid presenting decisions as a binary choice, such as yes or no. Instead, consider all possibilities and reject them one by one.

Build a work-plan of what analyses needs to be done to prove or disprove the hypothesis

Prioritize using the 80–20 rule and focus on the factors with the greatest impact. Begin by addressing the most pressing questions; the answer may render the remaining tasks irrelevant. Utilize the Critical Path Method.

Take the path of least resistance to getting a result that is directionally correct and of the right order of magnitude.

If you come across a question that cannot be answered with facts, try to triangulate in order to determine the likely range of the answer.

Gathering the most useful information as quickly as possible

Look for outliers. Study best practices and frameworks within the industry (possibly via competitors)

Before conducting an interview, write an interview guide with a list of questions and the order in which they should be asked. Start the interview by providing the larger context and beginning with less sensitive topics. Your goal is to make the interviewee a partner in problem-solving. If they say “I have no idea,” ask more specific questions to get answers. After each response, show active listening with nods, facial expressions, and other cues. Paraphrase as much as possible to ensure a shared understanding of the answer. End the interview by asking if there is anything you forgot to ask. After the interview, send a thank-you note.

Names of experts, blogs, industry studies, wall street analyst reports, annual reports of public companies.

Interpreting the results, i.e., figuring out what it all means

Understand the data. Every analysis should answer the question: “So what?” Get rid of any analysis that doesn’t prove or disprove your hypothesis. Make sure the analysis is within the bounds of probability. Focus on the biggest wins.

Provide insight tailored to your client’s capabilities. This way, they can actually implement it.

Presenting the results

Establish a top-down structure for your PPT with conclusions first, avoiding deductive reasoning. This will let your audience know where you are going, making it easier for them to follow. You can then explain the solution quickly and only go into finer points if the audience is not convinced or requests more information.

Buy-in — Avoid surprises. Walk key stakeholders through your key findings before the meeting and seek feedback. Let them have a say in the presentation. This helps you identify any critical points you may have missed, builds consensus, and lets you know if any stakeholder will resist your solution.

Related: Experiment-driven Development