I will be interviewing with McKinsey next week. I've been watching the case interview video and it was extremely useful. However, regarding the business situation framework, I have a question.
Yesterday I had my first case interview workshop in McKinsey.
Two highlights from the workshop are: 1) Don't ask too many questions or do not ask questions at all; 2) When you are coming up with the framework, be result-oriented.
I've been using the business situation framework in the workshop. What I noticed was that your business situation framework seems to include everything.
In a situation where we need to get information, this framework is good. But the trainer mentioned we should be clear about why we are including certain items in the framework, and explain the reasons at the beginning.
So the difficulty I've found was since I barely knew much information when I was constructing the framework, I was unable to explain why I should include them and how they would direct me into my potential conclusion.
Now I'm a bit concerned that if I use the business situation framework in the interview and ask questions on the checklist, the interviewer would think I am asking too many questions, which in the workshop, the McKinsey trainer made it clear not to do.
Do you have any suggestions on how I can improve that?
Let me answer this question by explaining why the trainer has made this point about not asking too many questions.
The complaint I'm seeing from interviewers is that candidates are getting frameworks from books and off the internet that have a laundry list of questions to ask.
The candidate memorizes the entire list, and then asks the questions one-by-one until the person has asked all 20 questions on the "framework".
From the interviewer's standpoint, this is annoying because all the interviewer has been able to do is confirm the candidate's ability to memorize a list of 20 questions.
And to be fair, my framework list including the business situation framework does have a list of questions attached to it (available to you at www.caseinterview.com/login listed underneath the 12 videos).
So this is why the trainer is telling people to not just mechanically memorize a list of questions and ask them during an interview. The problem is this approach doesn't demonstrate any critical thinking, analysis, or problem solving ability.
What is the missing piece in this approach?
I'll give you a second to think about it. It's a very common mistake that everyone who has gone through my Look Over My Shoulder® program should 1) be very familiar with, 2) recognize the bad habit from a mile away, and 3) know not to make this mistake.
So what's missing?
The purpose of a framework, the business situation framework or any framework, is to start a case. It is not to finish a case.
Start a case with a framework. Transition to a hypothesis. Drive the rest of your analysis using the hypothesis as your guide. End on a synthesis (or in case interview practice, lots of mini-syntheses after every major transition in the case, as demonstrated in Look Over My Shoulder®.)
The hypothesis driven approach can evolve in one of three ways:
a) It still makes sense to go through the rest of the business situation framework on a selective basis -- meaning you only cover the questions that seem the most relevant given the hypothesis. So often this will involve skipping four out of five questions listed in the framework.
As you include the questions that are relevant, you want to explain what your hypothesis is, what information you need and why... and then ask your question.
(This is the trainer's point about if you're going to ask a question, explain why the question is relevant).
So if hypothesis is: I think the client should enter this market. The market demand is there. The client has the right product for the market. Margins are excellent. but, to be really sure, I need to analyze the competition to determine two factors: 1) are clients being served by existing competitors, and 2) does the client's capabilities represent a genuine competitive advantage in the marketplace?
If competitors are ignoring the target customer segment, and the client's capabilities are in fact unique in the marketplace -- meaning it has a major competitive advantage, then this would confirm my hypothesis.
With that in mind, I'd like to analyze the competitors. First, do any competitors even exist? I see.. how many are there? What are their market shares? I see... a very fragmented market. (mini-synthesis) This looks favorable to my hypothesis.
Are any competitors focusing on the target customer segment? Oh, none are... that's interesting, that means the target customer segment is potentially under-served.
Do the competitors offer a comparable product even if intended for a different market segment? No... well that's really interesting.
Notice by stating the hypothesis up front, it's much easier to "see where I'm going" with my line of questioning.
If I forget or fail to state the hypothesis as soon as possible (and Look Over My Shoulder® members know to never ever make this mistake), the questions do not have any coherence or organization to them. It just looks like a bunch of questions.
Basically the question to ask yourself is this (and write this down -- it's very important): "What information do I need to prove or disprove this hypothesis?"
b) It may make sense to switch to a different framework. This very common with cases that seem to start with the profitability framework. The profitability framework will tell you what is wrong with a company (costs too high, sales volume too low, etc...), but it will not tell you why, nor will it tell you what to do about it.
c) The final scenario is to use a customized issue tree (see the three example hand-drawn issue tree diagrams in Look Over My Shoulder® as a reference -- I believe it's in cases #2, #4, and #5). You use a custom issue tree (basically making up your own framework on the spot) when the current framework does not fit nor does any other "standard" framework you know.
You can see an example of this with an actual BCG case at:
So to wrap up this question, I think the trainer's statement to ask very few or no questions is an over-reaction to the endless question-asking problem made by many candidates (but hopefully not by anyone reading my emails!).
The only time when you can reasonable start with a hypothesis is in a profitability... "My hypothesis is it's a cost problem. Lets look at costs."
The hypothesis will most likely be wrong or overly general, but it's probably still a good idea to use it anyway. It gives the analysis some direction.
I suppose you could also start a case like a market entry case (typically associated with the business situation framework), with a very simple hypothesis. The client wants to know: should they enter the XYZ market? My hypothesis is "yes".
It's kind of a lame hypothesis, but it IS a hypothesis and you still need to go through the business situation framework to refine why you think "yes", but for the sake of being 100% hypothesis-driven and not just 90% hypothesis-driven, it's probably a good idea to start this way.
Then as you transition immediately into the business situation framework, you'd say that customer demand and customer trends would need to be favorable in order to support this hypothesis, so let's analyze this further.
a) Do any customers exist today? b) What are the segments?, etc... As you learn new things, keep tying in back to the hypothesis, and refine the hypothesis as you go.
Again, there are about ten hours of examples of this "rhythm" in Look Over My Shoulder® (especially the last example for each case, which is the "best practice" version).