How often do you actually 'draw' an issue tree when answering cases?

Hi Paul, 

I saw your comment below that none of the answers fully addressed your question, so thought I'd take a crack. To recap, this was the prompt you received: 

"A leading manufacturer of instant cameras and one-hour photo finishing machines is facing a dramatic downturn in business due to the rapid increase in digital photography and sharing photos over the Internet. What should it do?"

The other answers stressed the importance of clarifying the company's objectives, so I won't say more. Assuming the objective is something basic (e.g., shareholders want to increase value), here's how I would approach the question:

1. Tweak an existing framework that you know is MECE

I would use an M&A framework as a "template" to tackle this question. For example, in an M&A, you typically use the following framework:

1. Is this an attractive market to enter?
2. Is this an attractive company to acquire?
3. Is this the right opportunity for our client? (e.g., Can our client afford the target? Will there be synergies?) 

For this question, I would adapt slightly as follows:

1. What is the outlook on the photography market?
2. What is the outlook on the company?
3. What are the opportunities for our client? 

TIP: The general framework of "market / company / opportunity" is always MECE and works pretty well for cases that involve market trends. 

2. Use questions to build out each "level" of the issue tree

Under the first heading (What is the outlook on the photography market?), I would have the following sub questions:

• What is the market size of photo services? Is it growing or shrinking?
• What is the breakdown between digital, instant, and other photos? How has this changed over time? 
• Who are the major competitors in this space? What moves are they making? 

Under the second heading (What is the outlook on the company?), I would have the following subquestions:

• What is the revenue and cost over time? (Here you can use a good ole revenue / cost framework. It's a framework within a framework!) 
• Does our company have competitive advantages relative to other players? 

Under the last heading, I would list the points you raised:

• Is there a buyer who would interested in our client's assets?
• Could our client pursue product development?

TIP: Using questions as the headings is helpful to break out each level for non-standard cases. In fact, almost all issue trees I showed clients were framed as questions. 

3. Prompt the interviewer to hint where you should go

Once you share the framework, you might be unsure where to go next. It's always fine to ask the interviewer: "Where in the framework do you recommend I focus?" If the interviewer says "Let's talk about product development," you can start breaking that out into more detail. 

A few last thoughts: 

• You can always make a MECE framework. Dynamic problems are tough, but that's why interviewers ask them! 
• Yes, diagramming or writing frameworks in the form or an outline are both common. I've done both on actual cases. 
• Try putting this to task on a non business problem. We used to do a fun one in training called "Should I ask her on a date?" All participants then made a pretty humorous (but MECE!) framework to answer the questionl. 

Hope this is helpful!

Cheers, 

Hi Paul,

Completely agree with Francesco:

1) You start with clarifying questions:

• Clarify the business model. Even if you think you understand it, try to repeat it to make sure that you understand it correctly.

• Clarify the objective. Here make sure that your goal is Measurable, Has a time-frame, Has / has no limitations (e.g. Should I invest 100k in this business for 1 year if I want to get 15% return?)

• Ask the questions that will help you build a relevant structure and remove ambiguity

2) You always do a structure in the beginning. I don't think you will pass the interview without it. Which initial structure to use? 

• In some cases, you'll be able to build a fully MESE structure (e.g. Profitability, Value chain). Usually, you go 2-3 levels deep in your structure in the beginning of the case.
• In other cases, you should be using a broader structure. For example, in a private equity / due diligence case your structure can be: Market, Company, Competitors, Feasibility of exit. For the 2nd layer, you make subpoints (e.g. in the Market you put: size, growth rate, profitability, segmentation, regulation, etc). I usually use a bullet point list under each bucket.

3) You never stop using the structures. The most common feedback on the interviews is "You are not structured enough".  To avoid this you should always be structuring. Make an initial structure and then dig deeper with the new structures. These structures can be both fully MESE issue trees or frameworks or a combination of both.

For example, if you find that we spend more time on cleaning the job shop than the other division you go with the following:

• Frequency of cleaning * Time spent per one cleaning
• If we find that the frequency is the same, we structure it further into: People, Process, Technology

4) You can also demonstrate business judgment if you not only make the structure but also make the hypothesis on how to prioritize the certain parts of the structure. You do it either based on your industry / functional knowledge or on the case context:

• For example, you split your problems in the newly created sales department into: Sales strategy, Sales coverage, Motivation structure and Sales Process
• You prioritize Motivation as your hypothesis, since motivation is the most common issue in the newly-established sales organizations. 

Best,

Vlad

Of the 1000+ interviews I've given, I would say that maybe 25-40 people have drawn an actual diagram. I am usually very surprised when I see this. The interviewer is looking for a logical, MECE set of issues in your structuring of the case or sections of the case. However, if you choose a structure such that it can be easily diagramed into an issue tree, it is probably a) mechanical, b) boring and c) not going to standout. For instance, if asked why a restaraunt profit was decreasing, you could easy break it down into an issue like:

* Revenue

• In restaurant
  • Food
  • Beverage
  • Merchandise
• Out of restaurant (catering)

* Costs

• Variable
  • Food / Beverage
  • Labor 
  • Maintenance
• Fixed
  • Rent
  • Insurance
  • Taxes

You do not want to take this approach and instead want an approach that:

• Is very structured, logical and MCE… BUT stands out (not profit equal revenue minus cost)
• Has 3 - 5 distinct buckets that show the breadth of your thought
• Has proper depth under each distinct bucket highlighting 2 order issues

So, for my example, I may use something like: 

• Category dynamics: Has there been a decline in the market or is it only happening at my restaurants? Has there been a decrease in the average price of meals / meal items sold? – both for my restaraunt and in the market?
• Customer dynamics: Has my customer type changed? Have we seen less traffic? Hasthe average size of customer parties decreasing? Has the average spend per customer / customer party changing?
• Competitive dynamics: Are there existing or new competitors who could be exerting pricing pressure? Has a competitor changed its selling strategy dramatically (new concept, new channels)? Has a competitor launched a marketing promotions (e.g., tv ads) lately
• Channel dynamics: Are certain channel formats doing better than others? Are certain geographies underperforming? Are costs varying by channel? Have we opened new formats that are under/over-performing?
• Internal dynamics: How are resources allocated against opportunities in the market? How do we approach innovation? Are there any internal biases to preferentially support different channels, customer segments or product ideas?

Hi Paul,

I would say it’s always better to have an issue tree at the beginning of the case for your structure. If you are unable to draw a tree, this means your structure is not MECE enough. Your question thus translates in how to have a MECE structure for some specific type of cases (this could be a good topic for a new thread).

In some cases, it would be better to consider the points of the issue tree as a flow rather as equally important at the same level. Say for example that in order to enter a new market to reach $10M in revenues you are analysing the following:

1. Market attractiveness
2. Opportunity for your client to meet its revenue objective in the market
3. Ways to enter and related capabilities required
4. Risks

You can consider Points 1 and 2 as conditions for the following points in your analysis – that is, IF you find that Points 1 and 2 are satisfied, that is, there is an opportunity to meet $10M in revenues for the client in an attractive market, THEN proceed to analyse the ways to enter and capabilities required in Point 3. Otherwise stop and reject the hypothesis you should enter.

For a profitability case, I believe an issue tree could be very useful. One that could work well to understand the problem would be the following:

http://bit.ly/2kEHQqr

Obviously, that doesn’t mean you would have to limit your analysis to this (once completed the steps in the issue tree, you would need to understand why the client has a certain issue for a certain segment; if required, it would also be useful to have another issue tree to structure the potential ways to increase profits).

Best,

Francesco

Thanks for the replies all. When I am practicing, I usually draw out a tree for problems that are relatively straightforward, such as profitability, market entry, etc. However, I recently came across a problem that was a lot more dynamic and was thus considering what would be the best way to actually diagram it out, so as to present it in the most MECE way. Here was the question:

"A leading manufacturer of instant cameras and one-hour photo finishing machines is facing a dramatic downturn in business due to the rapid increase in digital photography and sharing photos over the Internet. What should it do?"

This is a bit dynamic as it involves something like an industry analysis and a competitive response, which can go in any number of directions. I haven't really found a 'framework' or issue tree that does this in a concise way and I am not really happy with the response in the practice book. I think this kind of question involves a lot of different dynamics. First, addressing WHERE "the internet" is actually taking away business and WHY. Second, determining the different strategies for assessing what to do, which can vary considerably: product development (think Ansoff matrix), mergers or acquisitions (in the one hour photo field or in the "internet" field), takeovers (in the one hour photo field and without), diversification of revenue streams (completely new products or building on the one hour photo technology), and so on. I am having trouble mapping this out neatly on paper and in a way that is truly exhaustive.