Introducing the Case Interview Process Model© - Part 2: Hypothesis & Structure

This post follows the first part of the Case Interview Process Model, where we discussed the goal of the maps and how to open a case.

First of all, my sincere apologies to post the second part this late. The combination of interviews, quitting a job and devoting time to charity has been has been overwhelming. Yet, this is not an excuse, because as we shall learn when working in consulting, great performance is a function of discipline, and discipline only. I obviously lacked it during those three months :) On that note, let's get started!

(Click to enlarge)

In today's post, we will focus on the first two steps of the Analyze Case sub-process: Define Initial Hypothesis and Structure Hypothesis. Those tasks are the bulk of a case study so they need to be discussed at length. You can quickly observe that the map describing Analyze Case is substantially larger than the one used in Open Case. This is obviously explained by the fact that actual work to solve the problem is done in Analyze Case.


But before walking you along the process, let me define some of the new shapes you can find on this process maps.

• Automatic Tasks: those with the little cogwheel icon inside. Here they are meant to represent tasks that the candidate must do but which do not require any communication with the interviewer. In other words, those tasks always happen in the candidate's head and she does not need to tell the interviewer about what she's doing. This is NOT the original meaning of automatic tasks by BPMN, but I thought this distinction to be quite valuable in our case.
• Diamonds: represent classic workflow decision points. Very often, the decision is binary (e.g. yes or no). An important point to note is that BPMN diamonds do not perform any work; they only serve as a gateway to the logic flow. Hence it is compulsory to always have a previous task that actually performs the logic test. We follow here the BPMN rule.
• Loop Activities: marked with a curved arrow at the bottom. A loop activity (in this map, a sub-process) is a great example of the neatness of BPMN. The loop means that the activity will repeat itself indefinitely UNTIL a certain condition x is true. In other words, as long as x is false, the activity loops. When x becomes true, then the activity stops looping and the flow can move forward.

Now that we are all on the same page about those nice little drawings, let's crack this case wide open.

Define Initial Hypothesis

The method advocated by Victor Cheng (and depicted in those maps) is in reality nothing but the Scientific Method, remixed with some consulting terminology and communication aspects. So let's all go back to our Science lessons taught in primary school. The first thing we learned is that the method is deemed scientific because it uses measurable facts to prove or disprove a hypothesis.

The first step that you must do is therefore to define an initial hypothesis, based on the preliminary background knowledge you gathered (cf. Open Case process). Now, I would like everyone to carefully read the following sentence: IT DOES NOT MATTER IF THE HYPOTHESIS IS CORRECT. You ought to probably read it again. This is really important. The initial hypothesis is akin to the first draft that you do when drawing something. Don’t bother too much about the exactitude; you have a lot of chance to correct it along the way.

After picking up a hypothesis that you vaguely think may be correct, you must explicitly communicate it to your interviewer. Victor Cheng argues that you are free to use or not the very term "hypothesis" in your verbal communication, the important part being that the interviewer realizes you are hypothesis-driven. I tend to disagree with that approach and recommend that you explicitly use the word "hypothesis" when you announce it. This is mainly motivated by the fact that saying this word out loud clearly helps the interviewer to know you have a hypothesis and remove any ambiguity whatsoever (especially if English is not your mother tongue).

You can congratulate yourself now. You are on the path to case glory :)

Structure Hypothesis

Finally, the real deal. So let me be very clear about this. STRUCTURE IS THE MOST IMPORTANT ASPECT OF A CASE PERFORMANCE. I know that we already saw few other activities that I said were extremely important. Indeed they are but don't be fooled. So far, the reviewed activities were very binary, depending on your action. You either verified the objective or you did not. If you did, congratulations, you continue on the happy path. If you didn't, be prepared to haunt the land of the failed case interviews.

Structure Hypothesis is nothing of that sort. It is neither black nor white, but indeed always grey, for the perfect case structure does not exist. If you are serious about case interview preparation, you have seen a lot of other authors speaking about structure, some of them being even entirely focused on that aspect. This is because the ability to efficiently structure a problem is a very valuable skill for a consultant, while at the same time it is very difficult for most people.

The key to solve any particular problem is to have a clear idea about what it is, and this is exactly what structuring means here. By diligently breaking down a particular issue into its main drivers (spoiler: this is textbook consulting lingo), you literally structure it; that is you understand the nature of the problem.

So you may think that if structuring a hypothesis means to tear it down into sub-components, it shouldn’t be that complicated right? Well, think again. It is not enough to breakdown your hypothesis, you have to do so in an optimal way if you want your structure to be of any use. We already mentioned that you must focus on KEY DRIVERS, aka the most important factors that explain your particular hypothesis. But this is not enough. To really become a structuring master, you have to adhere to the now famous MECE concept.

MECE (pronounced mee-see) is an acronym invented by McKinsey folks that stands for Mutually Exclusive and Collectively Exhaustive. It captures the essence of what an optimal structure is: all the relevant factors to the problem are identified (collectively exhaustive) and they do not overlap (mutually exclusive). Despite its apparent simplicity, MECE is a very hard concept to follow and it can be argued that real life consulting engagements do not use structures which are 100% MECE (as Arnaud Chevallier from Powerful Problem Solving expresses it, you should not even bother trying). This is particularly true in a case interview, where there is absolutely not enough time to come out with a structure perfectly MECE, unless using mathematical formulas (such as the Profitability equation).

Now that we know we need to be somewhat MECE but not strive for the 100%, it is time to focus on the different types of structures that exist. This is easy, there are only two: Frameworks and Issue Trees.

Frameworks
Ha… frameworks. It seems that every book, website, forums or article about consulting interviews talk about them. Without a doubt, they are still the superstars of the case interview tools. Even though their status has started to get seriously attacked by advocates of the Hypothesis Method, for many candidates, succeeding in a case interview closely relates to having chosen the right framework to tackle the problem given.

A framework is as a pre-defined set of categories and sub-categories that accurately explains a particular situation. Frameworks are popular because a lot of them are taught in school. Every business student has heard about Porter’s Five Forces, The Marketing Mix 4P’s, The 3 C’s, McKinsey’s 7s and so on. Those frameworks are all solid and well designed structure because a) they tend to score fairly high on the MECE scale and b) they have proven to be very relevant to the problem they are applied to.

And this is where the problems start with frameworks. If you carefully review the last point, it says that frameworks are only good if they are used to solve the specific type of problem they were designed for. For example, Porter’s Five Forces were designed to explain the competitive environment of an organization. It does indeed do a fantastic job to solve this very problem but if you try instead to use this framework to understand the supply chain of a company, you are doomed to fail. In that respect, frameworks are not agile. But can’t force a framework to solve a problem it is not supposed to cover. Please read the last sentence again. This is a very important point.

Another problem that arises with frameworks is that they are too “well-defined”. Let me explain. All the frameworks that are taught to aspiring consultants are well-known and have been refined for a long time. The different aspects of a framework are all precisely defined, thus leading the framework users to rely on all the parts of the frameworks with no adaptation to the problem at hand. Interviewees who follow that route are known in consulting jargon as “framework robots”, that is they explore methodically all the different aspects of the framework, without realizing that perhaps some parts are not important at all, while other aspects are actually key and need to be drilled down much further than the actual framework advocates.

On the other hand, frameworks do provide you a quick and safe start when breaking down a problem. You need to understand what is wrong with your client’s marketing? You can safely start using the 4Ps, before probably tailoring this to really suit the considered problem.

Issue Trees
While Frameworks are convenient but rigid, issue trees are the exact opposite. An issue tree is basically a tailored structure that you create on the spot to solve the problem considered. The big advantage of using issue trees is that they are so flexible. Because every issue tree is original, every problem on earth can be readily solved by it.

Of course, this nimbleness comes at a price: issue trees are not easy to craft, especially ones who are highly MECE. In practice, tailored issue trees are a re-combination of different aspects of a framework, stitched together in a way that does effectively explains the issue to solve.

It is usual to distinguish two different kinds of issue trees: diagnostic and solutions trees. Diagnostic trees tend to answer “Why” questions (this is why they are also called “why trees”). A diagnostic tree’s goal is to identify all the root causes of a problem. On the other hand, solution trees (“how trees”), aim to identify all the potential solutions to a problem. Diagnostic and solution trees are complementary and a strong candidate should always use both kind of trees (sometimes merged together in the same structure).

Much has been written about issue trees and for a good reason. It is potentially the most potent tool for solving cases, because as we already discussed, trees can be tailored to fit the very problem at hand. Therefore, I urge you to review the literature on issue trees. If you can master the tool, you will definitely be in the right direction to solve the case.

In the next post, we will review all the further steps featured in the Analyze Case sub-process. Stay tuned!