Say why you include sub buckets in your structure?

Question

Hi!

When I communicate my structure I usually try to say why I have included the different buckets (both top buckets and sub buckets) in my structure. Is this a good thing to do? In some cases it feels kind of mechanical to do for the sub buckets. Further, lets say I have a top bucket called market and that one of the sub buckets is customers. Then I typically say something like: "In order to understand whether this is an attractive market I like to look into 4 things. First I would like to look at the customers to learn more about what they look for in a product as well as what customer segments that are evident." Then when I drill down in the customer sub bucket I typically find out that I also look at it for more things (e.g. to find preferred distribution channels etc.) Do you guys have a better way of approaching this?

Answer 1

Hi Anonymous,

in general yes, it is a good idea to explain the reason why you considered a specific bucket in your structure; ideally when you do so you should connect with the goal that you verified at the beginning of the case – this will help to personalize the structure for each case and make the presentation less mechanical.

In terms of your second question, if you find you are regularly missing some areas in the sub-buckets (eg distribution) it probably means you should either include them in your initial structure, or you should mention them as a potential reason to explore a particular bucket/sub-bucket when related to that.

Hope this helps,

Francesco

Answer 2

Hi!

My view is that ou should never concentrate on explaining buckets anyway! This is NOT what a structure should do.

Structuring a case does not mean to explain the interviewer WHAT you want to look into (the "buckets")! Structuring a case means to explain the interviewer HOW you are going to answer the specific question that has been asked!

So your structue needs to be a LOGIC, not a set of qualitative buckets! Such qualitative elements (Customers, Market, Product, Competition, etc.) are nothing more than influencing factos that determine the answer to the question THROUGH the logic that you have outlined. THIS is how you think as a strategy consultant, and THIS is how you work out the approach towards strategic problems on real engagements. And you might not be surprised that this is also by far the best way to approach case questions in a rigorous way.

Cheers, Sidi

Answer 3

Hi,

I believe you should be presenting your buckets and providing a list of things you have in your buckets (e.g. In the market I would like to look at Size, Growth rates, segmentation, growth rates of the segments and regulation)

I do not recommend explaining why you are looking at these things, because you are stealing your own time. Just imagine - you have 4 buckets, 5 bullet points each. Multiply it by the time you need to explain the rationale for each point (please be realistic, since you'll have pauses between sentences, etc). You'll get the total extra 4-5 min waisted out of 25-30 min case. Moreover - the interviewer will get tired and distracted, although you have not even started the case.

Best

Answer 4

Hi there, because of the way a consulting firm works (charging a different hourly fee on projects based on the seni... (read entire answer)

Hi there, because of the way a consulting firm works (charging a different hourly fee on projects based on the seniority of the professionals working on it) this system is vit... (read entire answer)

Answer 5

They're often used interchangeably in the real world, but they tend to have more specific meanings when it comes to c... (read entire answer)

They're often used interchangeably in the real world, but they tend to have more specific meanings when it comes to case studies: A structure is the logic and approach by wh... (read entire answer)

Answer 6

Hi Laura, Based on my experience, you should be able to make each issue tree/framework inclusive of all the importa... (read entire answer)

Hi Laura, Based on my experience, you should be able to make each issue tree/framework inclusive of all the important areas of the case. If you find that this is not happening... (read entire answer)