Hi Anonymous,

Great question! Before going into some more details, let's have a look at the 2 concepts. When you start thinking about them from a purlely logical perspective, the issue tree is one of many subelements of a conceptual framework - so in the first place there is no contradiction between the two concepts, but perfectly go along with each other.

Concering the example of how many layers and buckets ... think MECE & quality first, quantity second. Your specific numbers provided are usually enough for a good structure of the case .. but it depends on how well the frameworks fits the case and not how many layers and buckets were included.

One of the most common mistakes I see for many candidates is how they think about structuring the case in the first place. A strong structure is not only a brain-dump of MECE components, but also need to have a logical flow built in. So solving a case is not only about content, but also about process - like a ghost-deck which is compiled at the beginning of a study.

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

Robert

Hi there,

I agree with Daniel, you could have an issue tree which is a conceptual framework, there is not necessary mutual exclusivity between the two concepts.

I always suggest to structure an issue tree for business cases (while for some market sizing types tables work better) – I think it just makes easier to visualize and explain the buckets.

Best,

Francesco

Hi,
it depends on the case. When you can draw it - especially for quantitative problems solvable with a formula - I recommend using issue trees.

Best,
Antonello

Hi

My feedback from MBB interviewer. I suggest that you don't go to the interview with a strong conviction on using framework vs. issue trees ... It's very good that you have all those tools in mind. However, the most important is to propose a structured approach, MECE and that you manage to engage a real discussion with your interviewer who will drive you along the case. Listen to all information you get and try to step back regularly to analyze all information you gathered to crack the case.

Best,

David

Hi! I don't get your question, because conceptual frameworks are also the issue trees in the end of the day. E.g. Porter's Five Forces is an issue tree.

And yes, every case usually starts with some sort of an issue tree.

Your task is just not to use some generic framework / issue tree, but to create the one which is tailored to solve the case at hand.

Hope this helps! DM if you want to discuss.

Best,
Daniel

Hello!

This is one of the many questions to which it would be a mistake to give a categoricall answer, since cases can be so diverse that need to be studied one-on-one.

This said, I find issue trees clearer to structure, which lso enhances a better communication.

Regarding number of overall buckets and layers of capilarity out of those... again, totally depends. The more detail, the better, but also controlling timings and the overall approch of it (e.g., if you deep dive too much in one branch and miss other relevant big branches in the 1st node, it´s not good either)

Hope it helps!

Cheers,

Clara

Hi,

neither am I a coach nor do I have long experience in consulting, therefore please take whatever I write here with a grain of salt.

Though, what I was taught in terms of how to properly think about business problems was following:

you should ALWAYS use an issue tree for structuring your cases!

Simply because structuring, at the end of the day, is nothing else but defining precise criteria based on which you are going to answer the question asked with a "yes" if they are met and a "no" if not. ONLY after rigorously disaggregating those criteria into their components and sub-components you should ask for qualitative factors/use qualitative frameworks in order to quantify them.

This is for decision-cases, such as M&A, Product launch, Market entry etc. There is another category, the diagnose-cases (mostly the so-called "profitability-cases"), where you first have to isolate the root-cause of the problem by disaggregating the metric (profit, lead time or anything which has negatively changed and the client asks you to find out why) into its quantitative components and sub-components and comparing them with historical data. ONLY after isolating the quantitative root-cause you may think about qualitative reasons which triggered that numerical change (competitive situation, customer preferences, regulatory changes etc.).

If by saying "conceptual frameworks" you mean a bucket list looking somehow like (imagine it is a market entry case):

- firm analysis (capital, products, customer base, market share, growth)
- market analysis (size and growth, customer segments, competitive situation, margins)
- financials (profitability, investment required)
- capabilities (access to suppliers, access to distribution channels, organizational experience)
- feasibility & risks

then this is not a structure, but a random laundry list of areas you want to look at, in the hope that the interviewer will give you some interesting data to work with.

Don't focus on the specific fields I wrote and whether they make sense or not. No matter what you add in/tweak it, the approach will remain wrong! Simply because even if these areas might make perfect sense to look into, they're hanging on the air and are not in ANY way logically and explicitly related back to the core question you want to answer.

Therefore:

Issue trees = the only tool you should use for setting up the structure of your case (means for showing the interviewer based on which precise criteria you are going to answer the client's question)

Frameworks = particular areas to look into AFTER you have finished structuring the case (= identified all quantitative components and sub-components) for quantifying particular elements

https://photos.app.goo.gl/55y8EAvz2uXwRYKx6

(edited)