You can’t learn about case interviews without hearing about hypothesis based testing. Few people do a good job of this, so I thought I would give some guidance on what hypothesis based testing means and how to use it.
Hypotheses Are Tools
The number one thing to learn about hypotheses is that they are tools. Identifying a hypothesis is not some strange case-interview ritual. Stating a hypothesis is not a box to check. If you use a hypothesis, you need to make sure you are capable of using the hypothesis to help you come to a conclusion. You do not earn any points by simply saying “my hypothesis is [X[.” You do earn points if you use the hypothesis to more efficiently solve the case.
You do not always need to state an explicit hypothesis. Some cases start off more exploratory, though they may have room for a hypothesis later on. Part of being a good consultant is recognizing the appropriate time to use each of your tools.
How to Make a Good Hypothesis (or How To Create the Best Tool)
There are a few attributes of a good hypothesis.
Answer the question
Your hypothesis should be a statement of a possible answer to the overall question you’re trying to solve. If the case asks you whether a Private Equity group should purchase another company, your hypothesis could be “yes, they should make the purchase.” If the case asks whether to launch a new product, you might have the hypothesis of “no, they should not.” These are some pretty easy situations to handle with a hypothesis. I’ll address more complicated situations next.
Don’t be overly specific too early
It’s easy to make a hypothesis when your only options are “yes” or “no.” Things can get complicated when you encounter questions like “how can our company grow its mobile app revenues?” or “how can our company respond to increasing numbers of competitive entrants to the industry?” or “how can we increase our production throughput?” These sorts of questions may be best approached with a bit more of an exploratory approach first, where you outline all the necessary factors to consider, and create a hypothesis later on when you have some more specific information. It might be counterproductive to say at the start that “my hypothesis to improve mobile app revenues is to focus on licensing.”
Ironically, being overly specific causes problems when you end up “proving” your hypothesis. For example, you might have a hypothesis that “declining revenues are causing our profitability problem.” You might then find out that declining revenues are causing a problem and conclude that your hypothesis is correct. The problem comes when you then fail to look into the possibility that costs are causing the problem as well. Proving a specific hypothesis right can prevent you from looking into the entire range of possible issues. If you’re going to be specific, make sure that your framework will not only be able to disprove your own hypothesis, but all alternatives as well.
Besides making specific hypotheses for complex problems, another pitfall is when you turn a simple question into a complicated hypothesis. In a “yes or no” situation, some candidates will go too far, saying something like “my hypothesis is: yes, introduce the new product, because the product is exactly what customers want for a great price and will enhance our other product lines.” The hypothesis before the italics is fine. If you don’t have a foundation for the details of your hypothesis, don’t make them up. Too many details can pigeon-hole you into leaving out essential alternatives.
Make it disprovable
Your hypothesis should be either provable, or disprovable. To my experience, it’s much easier to try to disprove my hypotheses than to try to validate them. Whether your brain works better on a prove or a disprove model, make sure you focus on the validity of the hypothesis throughout the case.
For example, if my hypothesis is “yes, the PE company should purchase this other company,” I might try to disprove that by looking for weak profits, a declining market, heavy competition, a low level of internal skills and capabilities, poor management without replacement prospects, a high price-tag, a long payback time, a negative brand image, etc. (note that I would organize these ideas in a logical way). If I find things that look bad for the hypothesis, I know I’m starting to disprove it and will need to refine it. If things look good, then I’m strengthening and supporting my hypothesis.
Have some foundation
Although you shouldn’t include excess detail in the actual hypothesis, interviewers do like you to have some sort of reason on backing to the hypothesis. At the start of the case, you can reference some piece of external information that you’re aware of, but make sure you test whether that external information is true for the case. Your initial justification doesn’t have to be solid, it should just provide some context for why your hypothesis is what it is.
As you move through the case, your hypothesis should become increasingly refined based on the data you receive in the case. More on that later.
How to Use the Hypothesis (or How to Use the Tool)
Once you’ve created a good, disprovable hypothesis, you need to wield it skillfully.
Build your framework around your hypothesis
If you start with a hypothesis, your framework should be built around disproving it. This is how a hypothesis can work for you. If you’re struggling to develop coherent, “MECE” frameworks, having a hypothesis might guide your thinking. Instead of thinking “what in the world might solve this problem?” you can start thinking “what would make this hypothesis bunk?” This is often an easier question for candidates to answer.
Continually return to your hypothesis
Another reason that you need to build your framework around your hypothesis should you choose to use one is because you MUST return to your hypothesis throughout the case. I would say that the single biggest mistake that candidates have been making with hypothesis-based testing is that they give a hypothesis at the beginning, and then forget about it. As I said at the beginning, you don’t get any points for checking off a hypothetical “hypothesis box.” You need to demonstrate your ability to use the hypothesis.
The most natural place to return to your hypothesis is at the end of branches of analysis when you incorporate the “synthesis model” (which I wrote about here). The first step of the synthesis model is to give the implication of the information that you’ve found. The implication is simply the update to your hypothesis. You should very clearly say that “my original hypothesis was X, but with this new information it’s Y.” Your hypothesis might be the same, but you need to tell the interviewer that, and clearly explain why it’s the same.
Premise testing in diagnosis phases
This is just a special case technique that helps me sometimes.
A common case prompt will involve a company that doesn’t know why it’s losing profits and wants to know how to fix it. The first thing I like to do is find out why the company is losing profits. Instead of making a hypothesis like “I hypothesize that the company is losing profits due to a problem in their premium product line,” I simply make use of a hypothesis that says “the company is losing profits.”
I already know that the company is losing profits, but if I keep that as a hypothesis in my head, I can think about what would disprove that as I build my framework. It helps keep me organized and looking for the correct things.
Of course, I don’t vocalize that hypothesis. As far as the interviewer knows, I don’t have a very specific hypothesis that I’m working with. But I am able to work through the problem efficiently because I have a statement that I’m trying to disprove guiding my thinking.
After I’ve used this technique to identify the problem, I will start to build hypotheses around how to solve the problem. I state these ones out-loud, and often build a new framework to address this second part of the case.
Controversy around the word “hypothesis”
I’ve heard of some people being somewhat passionate over the issue of whether to say the word “hypothesis.” Some interviewers love it when candidates use that word, while others think it’s a really bad idea. I chose to avoid saying the word “hypothesis,” and instead say something like “my hunch is …” or “I think the answer is …, but I’m going to test that answer by…” Those alternative phrases make it clear that I’m using a hypothesis, even if I don’t say the word out loud. Find what works for you.
Conclusion
Use a hypothesis as a tool, just like how you should be using your framework. Let it guide your thinking as you continually return to it. Your hypothesis-based testing should work just like how scientist use hypotheses, where they make a prediction of what must be true if the hypothesis is true, and then run tests to see if that prediction works. Hypothesis testing is a problem solving method, not a strange consulting ritual.
Keep seeking truth.
You may also be interested in:
