Question:
I appreciate your response and just had a quick opinion question. I spoke to a friend of mine, ex-Mckinsey consultant and interviewer.
He said, when I asked him about casework and interviews, that there is a key that many people who employ solely the framework miss out on. It seems a bit different from some of the advice given in your lectures and information.
He stated that when given a case to work, any kind of problem, the first thing you should do is intuitively solve the problem as quickly and accurately as possible, not waiting until the end of a case interview to describe a solution backed by data.
Then during the rest of the interview, utilize frameworks to check the completeness of your solution and to give data-driven support to a conclusion.
What do you think about that? It suggests a different style of approach and ideas, and in his mind is the difference between someone feeling around for the right answer, and someone intelligent and reasonable enough to have the rightanswer. A.K.A the difference between receiving an offer and almost receiving an offer.
My Reply:
At first glance it would seem your friend’s perspective differs from the advice I’ve given previously. But, it really is not very different at all — though there is a terminology difference.
When your friend says you should try to “intuitively solve the problem as quickly as possible…”, I would simply use the word “hypothesis,” instead of that entire phrase.
So to rephrase using the terminology I’ve been using, your friend’s advice is to not rely only on a framework and produce a solution at the end, and is suggesting that you state a hypothesis immediately or very early in the case.
This is very compatible with what I’ve said previously. There is some debate as to whether you state a hypothesis immediately or early in the case.
Frankly, I personally do both, depending on the situation. If there is a little bit of data to go on, I might set a hypothesis immediately. If not, I might wait 5 – 8 minutes to get some data before setting a hypothesis.
Keep in mind it is always possible to set a hypothesis up front in a case. There’s a very high probability the hypothesis is wrong, but often that is not important, because you quickly figure out why it is wrong if you test your hypothesis correctly.
And given how many candidates are overly framework-driven with no hypothesis, it is probably a good idea to just start off with a hypothesis at the beginning of a case.
When I interviewed, there was very little case interview information publicly available, and generally the people who knew frameworks also knew how to use a hypothesis.
And most people did not use frameworks at all. So when I interviewed, not using an explicit hypothesis up front was not a problem, but given how the competitive pool has changed, it is a good idea to start with a hypothesis from the start of the case.
The part of your friend’s comment that I totally agree with is it is a big mistake to never state a hypothesis (or make an intuitive guess at the problem), and to only use a framework.
In that scenario, you are not really problem solving. You are simply processing data.
Now there is also a wrong way to be intuitive that a lot of people use.
You can using intuition to create a hypothesis as to the a) problem, or you can create a hypothesis as to b) the problem + the solution, or c) the solution.
I strongly recommend you re-read the last sentence three times. It is very important to understand this point.
When people use intuition the wrong way, especially early in a case, they use option C — creating a hypothesis around the correct solution.
For example: A company is losing money. How should they turn it around?
So a solution-only hypothesis which I will argue is incorrect would be: “The client should cut their fixed costs to fix their profitability problem.”
It is wrong because it doesn’t actually explicitly state the problem… and sort of leaps ahead to a solution to a problem that might not even exist.
The other problem is it’s a little more confusing to test this hypothesis.
The “right” way to state a similar hypothesis using option B above is, “The company’s fixed cost structure has increased by the exact same amount as the drop in profits, and therefore, overhead should be cut.”
Notice in the “right” way, the same solution is presented but the underlying problem is stated explicitly.
Also notice how much easier it is to test a hypothesis that includes a “problem definition,” not just a “solution definition.”
So compare the two hypotheses and ask yourself what data you would need to prove each hypothesis:
Hypothesis 1: The company should cut overhead costs to improve profitability.
Hypothesis 2: The company’s fixed cost structure has increased by the exact same amount as the drop in profits, and therefore overhead should be cut.
For me, it is a little less obvious to figure out what data you need to test Hypothesis 1. In comparison, it is very easy to figure out how to test Hypothesis 2.
All you need to know to start is: Have fixed costs gone up? By how much? And is this increase equal to the recent drop in profits? (Of course, you’d want to set it up as an issue tree, using the profitability framework as a template.)
If fixed costs actually decreased, we know the hypothesis is wrong.
So early in a case, the right way to use intuition is to state a hypothesis that includes both an explicit reference to the problem, and a solution…. or just state a hypothesis indicating what you intuitively feel is the problem.
The only time to use a solution-only hypothesis is late in a case, when through your analysis, issue trees, and process of elimination, you’ve clearly isolated the problem… and through synthesis you have conveyed that this is the core problem, then refining a hypothesis to focus on a solution (without any reference to the problem) is perfectly acceptable because the problem has already been explicitly defined, proven with data, and mutually agreed upon.
When you use intuition early in a case where the problem has not yet been fully isolated and defined, and your hypothesis statement does not explicitly reference the problem (only a solution), which I will argue is a bad habit, most people will form their issue tree to prove/disprove their explicit solution… when instead, they should have created an issue tree to prove/disprove the problem implied by their statement first. (And most in practice candidates never do this… which is why this is a bad habit.)
If this sounds a little convoluted and confusing, that’s because it is!
So long story short, always make sure your hypothesis includes an explicit definition of the problem and you will be fine.
So let me be clear, using a hypothesis that is only solution-oriented is not wrong in the absolute sense. To be more precise, it is a bad habit because it dramatically increases the odds you will set up your problem-solving structureincorrectly… because most people will not notice the problem implied by their solution-only hypothesis, and will therefore not gather data to test their implied hypothesis as to what the problem is… and ultimately “get stuck.”
You only get stuck when you skip steps! If you never skip steps, you never get stuck!
So in your hypothesis statements, define the problem explicitly… don’t skip this step!
I have never been stuck in a case — ever. That’s because I never skip steps. Now, I do occasionally miss certain insights on the first attempt, and perhaps have to find them on a second attempt… but I never get “stuck”.
If you are getting stuck in your practice cases, it is because you skipped a step — usually without realizing it.
By the way, you will see many, many examples of every kind of hypothesis I referenced above in Look Over My Shoulder®.
Many of the people who did poorly used a, “I think the right solution is Y” type of hypothesis, and then would transition to, “The data I need to test whether Y is right or not is ABC data.”
Whereas those who did well had a, “I think the problem is X, and therefore the right solution is Y… so the data I need to prove X (the problem), is Z data… and if X is indeed the problem, then Y is the right solution, so let me focus on proving X is true.”
This is structured problem solving (using a creative and intuitively determined hypothesis as a starting point)… notice how it is both creative and analytical/structured at the same time.
As people who have Look Over My Shoulder® intuitively figured out by listening to it several times over and over again, when a candidate uses the bad habit approach, and the hypothesis is wrong… the candidate has no idea why it is wrong… and ends up spinning their wheels and gets stuck.
By using the good habit approach (of which the hypothesis is just one of many, many good habits demonstrated in Look Over My Shoulder®), if your hypothesis is wrong, it is usually very obvious why the hypothesis was wrong.
Additionally, it is usually obvious what a better or refined hypothesis should be.
If you have additional interest in this topic, I’d refer you to the Look Over My Shoulder® Program which has many examples and demonstrations of everything I talked about above.