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!
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!
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.
- Frame based on the objective: Identify exactly what the objective is, then think about the areas you would look at to solve the problem.
- 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.
- Practice with Introduction, then End, then framework:
- Practice a number of cases where you hear just the introduction, then build a framework.
- THEN, look at the end of the case and what conclusion was made, and re-do your framework.
- THEN, look at what framework(s) was/were proposed as the answer.
- Read the Economist religiously: The Economist 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!