[READ BOOK] McKinsey Mind

[dharashah410]

• Chapters
  • 1
  • 2....
• Structured Notes
• Write a review for Amazon.com and GoodReads
• Summarize the book as a Tweet Thread

[dharashah410]

One page book summary

The McKinsey Mind talks about how they analyze project. They call their method as - McKinsey’s Fact-based, hypothesis-driven, structured problem-solving process

1. Why structured? — Logically structuring an ambiguous problem statement into smaller components allows a) you to convey ideas in a clear and convincing way b) you, your client and teammates can collectively solve it with facts and logic.
2. Why hypothesis-driven? — A hypothesis (conjecture) allows you to start from the end and then work backward. It is always easier to prove or disprove something than to find a perfect answer. Operationally, it gives direction for your analysis. Finally, it allows you to objectively access multiple options (hypothesis) quickly.
3. Why fact-based? — Facts establish credibility with the client and compensate for the consultant’s lack of experience and intuition relative to an executive with years of business experience.

1 — Framing the problem

1. Break the problem into distinct, non-overlapping components and ensure no component is overlooked (MECE) and then document the same as a logic tree i.e. a hierarchical listing of all components from the 20,000 feet view and progressively downward. Also, never take the client’s diagnosis of the problem at face value. Dig deeper.
2. Determine the boundaries of the problem by eliminating unimportant factors and prioritizing amongst the rest.
3. Build a hypothesis based on limited facts with some additional research. Build a hierarchical tree of questions/issues and sub-issues by asking — a) What assumptions need to be true to this a viable option? b) Any reasons why this option won’t work? Brainstorm — Everyone must come prepared, having absorbed all facts and spent time thinking about implications. The objective is to get new ideas.
4. Finally, avoid presenting decisions as binary i.e. YES or NO (all or nothing approach). Instead, open out all possibilities and then consider/reject them independently.

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

1. Prioritise (80–20) and focus on only those factors that have the greatest impact. Try to get dominant questions first. The answer might make the rest of the issues (todos) irrelevant. (Critical Path Method)
2. Take the path of least resistance to getting a directionally correct and in the right order of magnitude.
3. If you reach a question that is unanswerable with facts, then triangulate to determine the likely scope (upper and lower bounds for the answer) of the question.

3 — Gathering the most useful information as quickly as possible

1. Start with annual reports. Look for outliers. Study best practices and frameworks within the industry (possibly via competitors)
2. User Interviews — Write an interview guide (questions and sequence) prior to the interview. Start an interview by communicating the larger context and with less sensitive issues. Your objective is to make the interviewee a co-problem solver. If an interviewee says — “I have no idea”, then dig deeper. Ask more pointed questions to dig answers out. Every time the interviewee answers, follow it by encouraging active listening responses (nodding, facial expressions, etc.). Paraphrase as much as possible to build a shared understanding of the interviewees' answer. End with “Is there anything I forgot to ask?” After the interview, send a Thank you note.
3. Names of experts, blogs, industry studies, wall street analyst reports, annual reports of public companies.

4 — Interpreting the results (Insight as a service) i.e. figuring out what it all means

Piece together data and analyses from previous steps into a coherent narrative/advice that leads to an action plan.

1. Understanding the data — Every analysis must meet the test of “So what?”. Eliminate all dead-ends i.e. analysis that neither prove or disprove your hypothesis. Perform sanity checks whether a particular analysis is within the bounds of probability. Concentrate on the big wins.
2. Insight — The insight is useless if your client cannot implement it. Hence, it must be tailored based on your client’s capabilities.

5— Presenting the results

1. Structure — Establish a top-down structure of your PPT with conclusions first (avoid deductive reasoning), early on so your audience knows where you are going so they have an easy time following you. This also gives you the flexibility to explain the solution quickly and only go down the issue tree to finer points only if the audience is not convinced or asks for it.
2. Buy in — Avoid surprises. Walk key stakeholders through your key findings prior to the meeting and seek feedback. Allow them to put their mark on presentation. This helps you know if you’ve missed something critical, helps build consensus and know if any stakeholder is going to resist your solution.