Question:

I work in the Venture Capital Industry and am considering a switch to strategy consultancy. Normally, people switch the other way around, but I think that it would be good to acquire more analytical, team and strategy skills, as I started in the VC field straight from campus.

While orienting myself in the strategy consulting field, I find your material extremely helpful.

Going through your LOMS program, though, I deal with two questions which I haven’t seen in the Q&A on the website or daily newsletter. I would be really grateful if you could help me by answering.

i) When do you ask for the revenues’ or costs’ components and when do you start yourself by naming the “price” and “volume” as the obvious revenues’ components?

There is some variation in the LOMS cases as sometimes you suggest to ask for a breakdown of revenues, and sometimes you already fill in the price and volume components yourself and then ask for a next layer breakdown.

ii) When do you switch frameworks or dig deeper? While going through the profitability framework, I understand that the real aim is to eliminate the parts (trees) which are not relevant to fix the problem.

Just to note, I find this method extremely useful.

But once you have found something intriguing you want to dig deeper and even switch frameworks, I am wondering whether you would first like to eliminate the other parts before you change the framework, or whether you dig deeper first and come back to the original framework later?

I look forward to hearing from you and owe you a beer once you happen to come over to Amsterdam, the Netherlands.

My Reply:

For your two questions, I think you’re looking for a hard and fast rule. Unfortunately, there is not a hard a fast rule that I use or would recommend that you use.

What I can give you are some guidelines and reveal the thought process behind what is sometimes a judgment call.

1) In general, I recommend telling the interviewer you want to “break down a number into its component parts.”

Quite often, once you say this magic phrase, you scored points for the insight. In many cases, the interviewer does not expect you to know the optimal segmentation pattern.

(And in practice, a consultant will try 10 different segmentation analyses before they discover what’s the right one.)

2) If in the background of the case you have some information that suggests an obvious segmentation pattern, then you can take a shot at de-constructing the number yourself.

For example, if the client says they are concerned about a price war, then it just seems like common sense that you’d want to look at prices and volume… either the client didn’t drop prices, and their volume suffered… or they did drop prices, maintained volume, but have no profits… that sort of thing.

3) If there is not any obvious indication of what the segmentation pattern should be, then I would recommend being deliberately vague about it.

I would say, “I would like to break down X number into its component parts to see what’s really going on here. Do we have any data on that?”

This is a very important phrase to remember to use. By asking the question in this way (which is what I did quite religiously when I was a candidate), it basically invites the interviewer to tell you how to break things down for you.

Quite often, the interviewer will just volunteer the segmentation of that number. In which case, you just saved yourself a ton of work and time.

In other cases, the interviewer might feel that determining which way to segment is the big insight for the case.

In this situation, they won’t volunteer the segmentation pattern and might kick it back to you and say, “What data specifically did you want?”

The beauty of asking a deliberately vague question first is there’s absolutely no downside.

Best case, the interviewer just tells you the right segmentation. Worst case, the interviewer just forces you to pick a segmentation pattern yourself.

When to Switch Frameworks

In terms of determining when to switch frameworks, it’s also judgment call as to whether you dig deeper on some insight you’ve discovered (and come back to “finish” the original framework later) or cover the rest of the framework first, then drill deep in the most interesting area later.

I have done it both ways in a case interview (successfully) and the same with clients. In practice, with a real client, you’re going to do both — go deep in the most interesting area + cover some breadth.

Here’s how to decide. When you sense that you have a decision to make — go deep or go broad — I would suggest refining your hypothesis first… then decide.

Sometimes, the hypothesis can best be tested by finishing the rest of the framework. If you analyze the company and discover pricing and profits have fallen — your hypothesis might be that it’s an industry-wide problem. It makes sense to switch to competitor analysis.

At first glance, it may seem like you’re just “finishing” the framework. But in reality, you are letting the hypothesis guide you — and “finishing” the framework is just a coincidence.

(By the way, you might want to re-read those last two sentences. Many, many CIBs do not fully grasp what I said in those last two sentences, to their detriment.)

In other cases, your hypothesis might be better tested by drilling deep in one area.

If you know that the major issue the client has comes from something internal, then it makes no sense to over-analyze competitors. In that case, I would say “I’m going to come back later to competitors, but for now, my hypothesis is that XYZ is an internal issue, and I want to test that first.”

While I will use either approach, I also wouldn’t hesitate to change my mind in mid-conversation.

For example, perhaps in the middle of profit analysis, I suspect we have an industry-wide profitability problem going.

I would state this hypothesis out loud, switch from profitability to business situation framework. Then, let’s say I analyze competitors, only to discover the problem is not impacting competitors at all. It’s a problem specific to my client.

I would probably stick with the business situation framework, stop working on the competitor branch of the framework (which I’ve just discovered is less relevant) and focus on the “company” portion of the framework.

(By comparison, a lot of CIBs that are stuck in the framework robot mode would keep dwelling on competitors, even though we are now certain the “problem” is company-specific. This is, of course, a mistake.)

In the course of asking the questions about the company, I will likely uncover something unexpected, which would prompt me to further refine my hypothesis — maybe our labor cost skyrocketed, and it only impacted the client and nobody else.

Then quite often, I would switch out of the business situation framework and use a custom issue tree to test the more specific (and better factually informed) and refined hypothesis.

Early in my case interview preparation process, I was not able to switch so effortlessly between frameworks. By the end, I totally forgot about the frameworks and just used what seemed to be most relevant at the time.

The other distinction that’s worth pointing out is just how often my hypotheses were wrong.

For example, let’s say I had Hypothesis 1 and to test it, I used Framework A. I might very quickly discover that my hypothesis was totally incorrect. I would revise my hypothesis — let’s call it Hypothesis 2.  I would then immediately switch to Framework B, and so forth.

In other words, sometimes I think CIBs have this picture that when I do a case, I’m getting it perfectly each time. While I’m generally good at getting the right outcome by the end of the case, during the case I’m quite often running into lots of little dead ends… refining my hypothesis along the way.

The important thing is to not get hung up or stuck when the facts clearly prove your hypothesis is wrong.

Quite often, CIBs get this idea stuck in their head of what they think the problem is (in reality what they want the problem to be) and in the face of contradictory information, they simply can’t let it go and refuse to switch directions.  You will hear a lot of examples of this in LOMS.

If your hypothesis is wrong, it’s wrong.

Stop pushing the issue and instead think about it, given the process of elimination and… what else is left that could be/must be true?

In some respect, part of my success in case interviews came not from finding “the answer” to the case faster than other candidates, but rather discovering what the answer is not more quickly than others… and by process of elimination, what’s left must be the answer to the case.

It’s a subtle distinction, but one worth thinking about further.