The Abstract Case Has No Framework. That, It Turns Out, Is the Framework
On the case type nobody drills for, why most of it is familiar terrain entered through a side door, and the one I got badly wrong first.
Essays on economics, institutions, markets, and education · Written by Pranshu Sanghai, edited by Claude
On the case type nobody drills for, why most of it is familiar terrain entered through a side door, and the one I got badly wrong first.
By Pranshu Sanghai
Continue reading →︎I work at Boston Consulting Group, where outputs are structured and timelines are fixed. I also write, where neither is true.
The questions are the same in both places: economics, institutions, markets, education, taken here at whatever pace they deserve. If something seems worth arguing with, the notices below will tell you where to find me.
On the case type nobody drills for, why most of it is familiar terrain entered through a side door, and the one I got badly wrong first
By Pranshu Sanghai
One day in September, well into our prep season and long past being polite, my case partner handed me a prompt: how could someone reduce loneliness in a city?
I did the most foolish thing I could: I tried to answer it.
I spent four or five minutes listing ideas: community centres, redesigning parks, subsidised clubs for the elderly, and even an app I’d rather forget. My partner let me keep talking, which I now realize people do when they’re having fun. By that point, we’d worked through about forty cases from Case Interviews Cracked and the usual smuggled PDFs. I had strong opinions on frameworks, much like people do about cricket. But none of that helped. I knew all about profitability, but I was lost when it came to loneliness.
I spent more time than I’d like to admit trying to figure out why, but what I learned turned out to be the most valuable lesson from that whole season.
Most of the time, preparing for a case is about getting comfortable through practice. There’s a framework for profitability, another for market entry, and one for growth. You don’t want to repeat these frameworks word for word since any good interviewer would notice, but they’re like handrails in the background. After enough practice, you stop needing them. The situations start to feel familiar. If costs go up somewhere, it’s probably the supply chain. If revenue stays flat in a growing market, someone else is taking your share. Instead of building solutions from scratch, you’re really just recognizing patterns you’ve seen before, just with different details.
Abstract cases seem to take away those handrails. But here’s the thing: they only seem to do that.
Think about how a typical profitability case works. You start at the top: profits are down. Then you check the first level, which is revenue or costs. Next comes the product line, then the region. Usually, it’s only at the fourth or fifth level that you find the real insight, like noticing that delivery truck use in the north has quietly dropped.
Now imagine the interviewer skips the introduction and just says: our client’s delivery fleet is underused. What would you do?
It feels abstract because there’s no casebook chapter about trucks. But really, nothing new has happened. You’ve just been handed the fourth level of a tree you’ve climbed many times, and now you’re supposed to treat it as the starting point. The structure above is gone, but the habits you’ve built, like starting with structure and following the MECE principle one step at a time, still work. If you can explain falling profits, you can explain empty trucks. It’s the same thinking, just at a different level.
The first thing to do with any abstract case is figure out if it’s really abstract, or just a regular case that’s missing its ladder. You’d be surprised how often it’s the second one. Some prompts do survive the check, like reducing loneliness, improving people’s trust in institutions, or deciding how a country should regard happiness. What makes these hard is not the lack of a framework, since you never were going to have one, but the presence of too many options. You could build parks, subsidise therapy, or ban phones. Every possible answer is allowed, and when all possible answers are given, then no answer really stands out. This is about where I found myself after four minutes of talking.
What I should have done, and what I do now, is pause before answering. Not to avoid the question, but to take a moment to look at it more closely.
An abstract prompt is called that because it doesn’t give enough detail, and each missing piece is a question you’re allowed to ask. For example, who is the client? Loneliness means one thing to a city government, something else to a health insurer, and something different again to a start-up with an app. Once you know the answer, you can rule out half the options. Who exactly is lonely? Is it the elderly, newcomers, or remote workers? Each group faces a different problem, even if we use the same word. What does success look like, and by when? A clear, measurable goal leads to pilot projects, while a vague goal leads to policy. What are the constraints? Is it budget, regulations, or political will? These might sound like bad news, but they actually help by narrowing your choices. And why now? No one suddenly decides to solve loneliness; there’s always a trigger, and that usually shows what the client really cares about.
If you ask four or five of these questions, you’ll see the difference. “Reduce loneliness in a city” becomes “help the city government reduce isolation among residents over sixty-five, using the current social services budget, and show results within three years.” The second version is just an example. The first was only a broad idea.
That’s also what’s expected of you. Most clients don’t come with clear problems. They come with concerns, and your first few weeks are spent turning those into real questions. If an interviewer gives you a vague question, they’re not testing your creativity. They want to see if you can turn an unanswerable question into one you can actually solve. It’s less glamorous, but much more useful.
Once you’ve narrowed things down, what’s left is regular problem-solving, just in a new context. Build a structure, but make sure you get there step by step: identify stakeholders if it’s about who can act, find the root cause if it’s about why things happen, and think about the kind of solution, like prevention versus treatment or incentives versus infrastructure, if it’s about what to do. Say which approach you chose and why, and explain why you’re focusing on a certain area. No one is grading your answer to the loneliness question, since there’s no perfect answer. What matters is that someone watching you go from confusion to clarity would trust you to help them do the same.
I should mention the limits of this approach. I’ve seen people do a great job scoping a question, only to get stuck on the details. I’ve also met at least one interviewer who really wanted a flood of ideas and was bored by my careful narrowing. No method works for everyone. The best thing I found was to spend five minutes each day scoping a tough question without solving it. It feels like cheating, but it’s the whole skill. Try making a MECE tree for a simple, random topic, like why the campus restaurant is always empty, or take a deep branch from a case you’ve done before and use it as a new prompt. That way, you won’t be fooled by the disguise.
As for the loneliness case, a few weeks later, when I was less sleep-deprived, I asked my case partner what the model answer was. He said he had no idea. The prompt came from a casebook with the solutions section missing, and he’d given it to me just to see what I’d do.
It is still the most instructive case anyone has ever given me.
Thanks for reading Pranshu’s Substack! Subscribe for free to receive new posts and support my work.
Also published on Substack ↗︎, where new essays land by email.New essays land by email. Subscribe ↗︎
Thirty minutes, on the phone.
Checking the calendar…