The SOLVE Framework

Surface the real problem

Asks arrive vague (“profits are down, help”) or pre-shaped as solutions (“build us a model”). Either way, don't accept them at face value. Clarify who the client is, what they're really trying to achieve, what's in and out of scope, what constraints bind, and — critically — which bottom-line metric this serves and what its baseline is. Success means beating current practice, so go find out what today actually looks like. Then say the problem back and get agreement from the person who owns it.

You produce: a one-sentence problem statement with a bottom-line metric, a baseline, and the problem owner's sign-off.

Where people go wrong: accepting the requested thing as the problem. The client who asks for an app rarely needs an app; they need something the app is supposed to cause.

In a case interview: this is the Opening — restate the prompt, ask two or three sharp clarifying questions, confirm the objective before touching structure.

Observe the behavior

Translate the bottom line into one or more target behaviors using the three behavior questions: What are people doing today? What would they be doing differently if we succeeded? What behaviors predict the result we care about? “People” means customers, users, employees, or stakeholders — anyone in the system. Because behaviors are things people do, they're observable and measurable — which is what makes them a target you can actually manage toward.

State the linkage explicitly, in pairs: if we create this behavior change for the customer, it will deliver this result for the business. And know your indicators: the bottom line is usually a lagging indicator (it tells you how you did); the behavior should be a leading one (it tells you where you're headed while you can still steer).

You produce: a target behavior statement — who, what they'd do differently, measured how, from what baseline to what target.

Where people go wrong: targeting a build (“launch the tool”) or a bottom line (“increase revenue”) and calling it a behavior. If you can't watch someone do it, it isn't one.

In a case interview: this is what separates a good opening from a great one — restating “grow profit” as the customer or operational behavior that would have to move.

Learn the drivers

Decompose before you solve, and stay solution-agnostic while you do it. Two structures cover most problems. When the question is economic — where did the profit go, what does this cost — build an issue tree: break the metric into parts that are mutually exclusive and collectively exhaustive (MECE), then quantify how much each branch explains. When the question is behavioral — why don't people do X — build a journey map: lay out what people actually do step by step, then mark the boosters (behaviors that predict success) and blockers (behaviors that predict failure) at each step.

Structure is a discovery tool, not a decoration: the tree tells you which numbers to go get; the map tells you which people to go watch and interview. Keep a running list of what's a fact you found versus an assumption you're carrying.

You produce: a driver map — tree or journey — with the branches quantified where possible, plus an explicit list of unknowns.

Where people go wrong: reciting a memorized framework instead of structuring this problem; or polishing the analysis forever instead of ranking branches by size and going deep on the few that matter.

In a case interview: this is the Structure — the moment the interviewer decides whether you think in organized ways. Draw the tree, say it aloud, then pick the branch your hypothesis points to.

Vet the shakiest claim

Turn your leading option into a falsifiable claim using the two-part template: We believe [this change] will create [this behavior change]. We'll know we're right when [this measurable evidence]. Then list everything that must be true for the claim to hold, rank those conditions by shakiness, and design the cheapest test that attacks the shakiest one — vet before you bet. That test is an experiment: the smallest thing you can do or make to learn whether the hypothesis is true. (A note on the word “MVP”: some fields use it for exactly this kind of cheap experiment; others — including product management — use it for a first sellable release with a deliberately chosen feature set. Both uses are legitimate, and they are different things — so this framework says cheapest test, and lets “MVP” mean whatever your field means by it.)

Evidence comes in three kinds, and strong work names which kind it has: analytical (does the logic and math hold?), behavioral (do people actually do what the claim requires?), and outcome (did the metric move?). Expect to be partly wrong while wrong is still cheap — and when a test fails, loop: back to another option, or back to Question 3 with better information.

You produce: a written hypothesis, a ranked must-be-true list, test results, and a record of what you revised because of them.

Where people go wrong: running analysis to confirm the answer they've already chosen; or “testing” by building the whole thing. If your first experiment takes a month, it isn't an experiment.

In a case interview: this is the Analysis — state a hypothesis, ask for the data that could break it, do the math cleanly, and update out loud when the numbers surprise you.

Earn the yes

The final deliverable is an argument, not a report of activity. Lead with the conclusion, support it with two or three reasons, back each reason with evidence, quantify the value in dollars and days rather than adjectives, and name the risks with mitigations. Then add the part most teams forget: the adoption argument. Every recommendation asks somebody to change their behavior — your colleagues and stakeholders are customers too — so the more your solution changes how people work, the heavier that argument must be. A model without its adoption argument is a demo, not a deliverable.

Finally, close the loop you opened in Question 2: specify the measurement plan — which leading indicators will show, within weeks, whether the must-be-trues are holding.

You produce: a conclusion-first recommendation (sometimes wrapped around a working artifact) with quantified value, risks, an adoption plan, and a measurement plan.

Where people go wrong: narrating everything they did in chronological order; or delivering an answer that's analytically right and dead on arrival because nobody asked the people who'd have to live with it.

In a case interview: this is the Recommendation — thirty to sixty seconds, answer first, no wind-up, risks acknowledged, next step named.