Structure

Sorry, this is wrong.

A framework is NOT background nor assessment nor conclusiong nor recommendation.

First of all, recommendation and conclusion are the same thing (i.e. not MECE).

Furthermore, this is obvious. Tell me a project where this doesn't apply. Consultants don't do this. A client would show them the door.

You get paid lots of $ because you bring actual thinking to a client's problem. Stating the obvious of “we will do a backgorund on your firm, then we will assess your problem, and then provide a recommendation” is totally and complettly wrong.

You need to talk through HOW you are going to approach the problem.

Imagine if you wanted to hire a lawyer, or a tax attorney, and they gave the above to you as how they do their work…would you hire them? Of course not!

Sorry to be so blunt, but you need a fundamental mindset shift in how you framework.

==========================================

Honestly structuring is the hardest thing to solve on your own. I highly highly recommend a coach because there's nowhere else you can get direct feedback/advice based on your specific frameworking/structuring.

I've collated some of my past advice on structuring/problem-solving here, which I hope can help you regardless of coaching or not!

Frameworking/Case Driving

First, remember that casing isn't just about memorizing every step, industry, case type, etc. It's about learning how to be adaptable and nimble. So, always be prepared for the unexpected.

1. All cases are structured, wheather you realise the structure or not. It's your job to keep it organised and keep it to a good flow/framework!

2. Figure out what data/information you need and ask for it: The interviewer won't just give it to you (just like your client won't know what you need from them). Use your framework to dive into areas! If your interviewer insists they don't have data in that area (after you've gone specific), then go into another area of your framework (or expand out).

3.In this case try and keep a mini framework in your head. You can write as you talk as well.

When you say "not those kinds of questions an interview-led style would ask" this shows me that you're limited in your preparation....don't come in expecting a certain format/style! Be ready to drive your own case if needed. Think if you were on a real life project and asked to lead it...this is what they need you to demonstrate!

Frameworks

If there's anything to remember in this process, is that cases don't exist just because. They have come about because of a real need to simulate the world you will be in when you are hopefully hired. As such, remember that they are a simplified version of what we do, and they test you in those areas.

As such, remember that a framework is a guide, not a mandate. In the real-world, we do not go into a client and say "right, we have a framework that says we need to look at x, y, and z and that's exactly what we're going to do". Rather, we come in with a view, a hypothesis, a plan of attack. The moment this view is created, it's wrong! Same with your framework. The point is that it gives us and you a starting point. We can say "right, part 1 of framework is around this. Let's dig around and see if it helps us get to the answer". If it does, great, we go further (but specific elements of it will certainly be wrong). If it doesn't, we move on.

So, in summary, learn your frameworks, use the ones you like, add/remove to them if the specific case calls for it, and always be prepared to be wrong. Focus rather on having a view, refering back to the initial view to see what is still there and where you need to dive into next to solve the problem.

HOW to learn/think in the right way.

1. Frame based on the objective: Identify exactly what the objective is, then think about the areas you would look at to solve the problem.
2. Think of buckets as "building blocks" - understand the 10-odd buckets that exist out them (Market, Product, Company, How to Enter, etc.). Learn these, and what their used for, then think of them as ingredients that you then pluck out and tailor to your framework.
3. Practice with Introduction, then End, then framework:
   1. ​ Practice a number of cases where you hear just the introduction, then build a framework.
   2. THEN, look at the end of the case and what conclusion was made, and re-do your framework.
   3. THEN, look at what framework(s) was/were proposed as the answer.
4. Read the Economist and BCG Insights religiously: The Economist and BCG Insights is an excellent, longer-term base knowledge/thinking resource for you. I've found that reading the Economist over the years has been instrumental in helping to shape my thinking and holistically understand problems, whether political, economic, social, or anything in between. Feel free to throw in the Financial Times or BCG Insights into the mix!

Hi there, 

High-level, it doesn't sound wrong. 

But it's impossible with this level of granularity to tell if you're right. 

I'd suggest you provide us with a synthesis of the context and the question you are solving. Then provide your detailed answer the way you would provide it to the interviewer. 

Then we could help with more targeted feedback. 

You can also improve your structuring knowledge with the following guide:

• Mastering Brainstorming: A Consultant's Guide
   

Best,
Cristian