Hi!

The questions you ask at the beginning have the following objectives:

1. Completely understanding the context/situation (including, unclear terminology, but also, for example, the business model of the client if unclear!)
2. Understanding the question(s) of the client
3. Understanding (and quantifying if applicable) the underlying objective(s) of the client

These questions are NOT meant to start the analysis already!!! They are aiming at understanding the initial setting, hence forming a precondition to outline your structure towards answering the core question (the issue tree)!

The later questions that you ask while navigating through the case are then aiming to verify the actual relevance of each sub-branch in your tree. So if you have defined and disaggregated the criterion to answer the client's core question in a clean way, all these leater questions follow a this precise "roadmap" as layed out by your tree. These questions then oftentimes also comprise enquiries on current performance metrics (revenues, costs, growth rates etc.), which normally should never be asked in the clarifying questions (before making explicit your structure).

Cheers, Sidi

Hi,

There is always more that you can understand. For example, if you understand the goal as improving profits, there's so much more you can ask - do they have a % change target in mind, how long do we have to turn this around, do they prefer this to be done through raising revenue or cutting costs, etc.

I always write BOTMG at the bottom of my framework page to help myself think of things I'm missing in case I'm stuck.

This helps "trigger" you to consider questions around B = Business Model, O = Objective, T = Timing, M = Market, G = Geography.

However, you should never just say "so, what is their business model?" Obviously, ask questions that help you frame your hypothesis, understand the situation, and ultimately drive your case better.

Dear Andrew!

I recommend to ask you 2-3 clarifying questions before diving into a case to understand the objective of the case interview:

What is the measurable metric of success?

What is the time frame?

What are the potential restrictions or limitations?

If you don't then go for this type of clarifying question

questions about the information that strengthens your understanding of the company

You can also ask a question about the definition of a term you are unfamiliar with.

Most consulting interviews do not require you to have specialized knowledge or expertise in an industry. Therefore, if you come across a term that you are unfamiliar with, it is completely acceptable to ask the interviewer for the definition.

Hope this helps and speak soon,

André

Dear Andrew,

That's a very important question. Especially since these first 5 minutes of the interview can make or break your case.
Below my experience, with the consulting day-to-day job as inspiration:

• We as consultants are supposed to solve client's problems. However, often big part of the magic is in cristalizing the real problem. All too often a client will come with a specific problem, while the real questions lies deeper. (e.g. "why are revenues for latests products X & Y down" --> real question could be "why are we not in sync anymore with market demand?"
• Secondly, as a consultant it's key to be able to alternate between high level views and deep dives. On a project you will have to spend time on the storyline, bringing concise & clear messages to CxO level. However, other days you will be very deep down in a data analysis, to get out the deepest insights... it's very important to be able to do both

All that in mind, what the interviewer is really looking for is this ability to "feel when to go deep in analysis" and to really understand the clients problem. That's why the clarification problems are so important. Here you should really stay at the high level, resisting the temptation to jump to the analysis. What you should do is get a really good understanding of the problem, make sure all terms / business models / ... are cristal clear and form a basic hypo as to have a guidance on where to focus the analysis in a later stage.

I really hope this is somewhat clear, it's much easier to explain with a real case, but I truly believe you always have to keep the why of this interview in mind. Basically we just want to test if you would be able to perform on a real project, and therefore these case interviews are very well thought through! :)

Cheers,
Sibren

(editiert)