Stating the hypothesis

hypothesis
Neue Antwort am 31. Aug 2020
6 Antworten
579 Aufrufe
Anonym A fragte am 24. Aug 2020

Hi. I am wondering in which cases, stating hypothesis is appropriate and in which cases do not need hypothesis before a framework. Or, do we state a hypothesis for every case? Thanks.

Übersicht der Antworten

Upvotes
  • Upvotes
  • Datum aufsteigend
  • Datum absteigend
Beste Antwort
Sidi
Experte
antwortete am 24. Aug 2020
McKinsey Senior EM & BCG Consultant | Interviewer at McK & BCG for 7 years | Coached 300+ candidates secure MBB offers

Hi!

And another round of the ever-repeated identical question... ;) So let me repeat what I already explained in multiple posts before:

Stating a hypothesis for the overall problem only makes sense if you really have something to ground your hypothesis on! This is very rarely the case, since case prompts tend to be quite vague at the beginning. Just stating a hypothesis for the sake of it serves no purpose! It would just be a shot from the hip - and this is something you should avoid at all cost during an MBB interview!

If the question is about finding the reasons for an observed phenomenen (e.g., fallen profits), then you can rather say “I would like to first identify the numerical driver of the problem, which can sit either on the revenue or on the cost side (or both). Based on this initial assessment, I would build a hypothesis on the underlying reasons for the detrimental development, then verify the hypothesis, and subsequently derive measures to address these reasons in order to reverse the trend.”

If the question is eseentially a go- or no-go-decision (e.g., "Should we enter the Brazilian market?"), then a MUCH better approach than a blank "Yes/No"-Hypothesis (which feels stupid anyway, right?) is to define the criterion according to which the question can be answered. This implicitly comprises hypothesis-thinking, but in a much cleaner way. All you have to do is to

(1) narrow down the question,

(2) define the criterion according to which the question can be answered with "yes",

(3) outline how you can test whether the criterion is met.

That's it! This is how you address strategic questions without shooting out non-substantiated hypotheses (or rather wild guesses!), while still being super top-down and super efficient.

Hypotheses then are used all along the way of performing the actual analyses! But it is not hypotheses on the overall question, but hypotheses on the various sub-aspects which you need to test in order to eventually answer the overall question.

I hope this helps.

Cheers, Sidi

War diese Antwort hilfreich?
Ian
Experte
Content Creator
antwortete am 24. Aug 2020
BCG | 100% personal interview success rate (8/8) and 95% candidate success rate | Personalized interview prep

My view is that your framework is actually your hypothesis. It's a bit nuanced, but bear with me :)

Your framework is your structure for approaching the problem. It consits of a few main areas you'd like to look at. Inherent in your framework is a view that "If I answer A, B, and C, then we have an answer"

So, for market entry:

1) If the market is big, and it's growing, then we still want to considering entering

2) If #1 = yes, then let's see if it's attractive...can we win there? Is our product good/better than our competition's? Etc. If yes, let's definitely consider entering.

3) If #1 and #2 = yes, then, when we do enter, are we sure we can win? I.e. do we have the right plans. Will implementation actually pan out? Do we have the expertise, capital, etc.? In other words, if #2 is the thearectical, #3 is the reality.

Then, your summary becomes "I believe we should enter the market, if we can prove it's a good market, the it's attractive to us specifically, and that we will win it".

^Now this is a hypothesis :)

Read these 2 Q&As for some great context + discussion:

https://www.preplounge.com/en/consulting-forum/interviewer-led-case-interview-hyposthesis-and-ideas-7390

https://www.preplounge.com/en/consulting-forum/forming-a-hypothesis-case-in-point-vs-victor-cheng-7311

War diese Antwort hilfreich?
Allen
Experte
antwortete am 24. Aug 2020
Ex-McK Experienced hire and EM - I specialize in helping experienced hires perform

Love this question!

I have two thoughts here.

Firstly, if the initial evidence is pretty clear as to what the answer is, you can make that your hypothesis. Example: The question is whether to invest in new equipment that will lower costs. Makes sense to say yes we should because XYZ. That shoudl be your hypotheses and you should state it.

Secondly, if the evidence is not clear, your structure needs to test a hypothesis. Example: The question is whether I should enter a new market? Answer is I would enter this new market if a) I can forecast profitability b) I have internal capabilities and c) the market is attractive (customers, competition). Here the hypothesis is not yes or no b/c at the beginning I don't know yet, rather the hypothesis is that these are the important factors that need to be analyzed.

Does that make sense?

Crucial to get this right when you are learning how to solve cases. I'm happy to explain more if you like.

War diese Antwort hilfreich?
Antonello
Experte
Content Creator
antwortete am 31. Aug 2020
McKinsey | MBA professor for consulting interviews

Hi, I confirm stating a hypothesis is not always required, even if it often helps you in prioritizing the branches of your issue tree and lead the case

Best,
Antonello

War diese Antwort hilfreich?
Robert
Experte
Content Creator
antwortete am 27. Aug 2020
McKinsey offers w/o final round interviews - 100% risk-free - 10+ years MBB coaching experience - Multiple book author

Hi Anonymous,

Even though Victor Cheng offers a lot of excellent advice, including a strong focus on the hypothesis-driven approach (which really helps many candidates sharpening and focusing their thinking along the case!), stating a hypothesis at the very beginning of the case usually turns out to be more counterproductive than helpful.

Unless you are an experienced hire with a strong focus on exactly that one case question to discuss, stating a hypothesis right at the beginning of the case interview is essentially nothing else than poaching with a stick in the dark and guessing around. And here you are: you are perfectly set for a highly unstructured and confusing start into your case! (Please note that even as experienced hire, you might be completely wrong with your hypothesis, especially in the slightly artificial case interview world - so I would not even strongly recommend the early hypothesis there)

However, at the same time it's also a matter of defining 'hypothesis'. If you look at your structure at the beginning of the case interview, it is basically the connection between the current client situation and a specific goal you want to achieve. In other words, this initial structure is also a kind of hypothesis which elements you need to consider and analyze in order to clearly understand the root cause and develop a solution for that. So essentially you can also consider your structure as some kind of hypothesis.

Apart from that technicality, the correct time to explicitly state a hypothesis during your analysis phase is when you have collected some initial data and you start 'connecting the dots'. Once some distinct pieces of your analysis guide you into one specific direction, then it's the correct time to explicitly state your hypothesis and focus in on 'verifying' (in the non-scientific way) your hypothesis!

Hope that helps - if so, please be so kind to give it a thumbs-up with the green upvote button below!

Robert

War diese Antwort hilfreich?
Anonym antwortete am 25. Aug 2020

Hi A,

Hypothesis depends on the case. So it's a case by case desicion.

Generally speaking, stating the hypothesis explicitly is not mandatoru to solve the case, however, it's always good to have one.

Best,
André

War diese Antwort hilfreich?
0

Sidi

McKinsey Senior EM & BCG Consultant | Interviewer at McK & BCG for 7 years | Coached 300+ candidates secure MBB offers
428
Meetings
4.497
Q&A Upvotes
78
Awards
134 Bewertungen