Structured Problem Solving

A framework is scaffolding for thinking, not a source of insight. Applied to thin evidence it produces a confident, well-structured wrong answer, which is more dangerous than an obviously messy one. We use these to force rigour and to make reasoning inspectable, never as a substitute for the analysis.

This is the method underneath the rest of the Strategy section. Diagnosis applies it to a north star and a value tree; Two-Pagers applies it to a single decision. This page is the general form: how to take “why is onboarding stalling” or “should we build disbursement before the ATS” and produce something a colleague can disagree with precisely.

Write the question down first#

Most bad analysis is a good answer to a question nobody wrote down. Before any framework comes out, the question exists as one sentence, specific enough that you could tell whether it had been answered.

“Should we improve onboarding” is not a question, it is a mood. “Which step of onboarding loses the most tenants, and is that step something we control?” is a question: it names a unit, it can be settled with evidence, and you can be wrong about it.

How to tell: read your question aloud and ask what evidence would settle it. If you cannot name the evidence, you have written a topic, not a question. Rewrite it until you can.

Answer first#

Lead with the answer, then the support. The Pyramid Principle is the house default for anything written to be decided on: a document opens with the single sentence you want the reader to be able to repeat back, and everything below it exists to defend that sentence.

The standard opening is SCQA: the Situation everyone agrees on, the Complication that disturbs it, the Question that raises, and the Answer. Four sentences, then the support.

Diagnosis calls this the governing thought, and the bar there applies everywhere: an answer-first sentence earns its place only if it is specific, evidenced, and falsifiable. If the reader has to reach the last paragraph to learn the point, the document is written backwards.

How to tell: hand it to someone and ask what it says after they read only the first paragraph. If they cannot state your conclusion, rewrite the opening, not the body.

Decompose into an issue tree#

Break the question into sub-questions that can each be settled separately, so that they are mutually exclusive (no overlap) and collectively exhaustive (nothing missing). That is MECE, and the result is an issue tree.

An issue tree is not the same as the value tree in Diagnosis. A value tree decomposes a number into the drivers that multiply back up to it. An issue tree decomposes a question into sub-questions, some of which are not numeric at all: “do they understand the step”, “are they permitted to complete it”, “does it work”. Use a value tree when the outcome is a metric. Use an issue tree when the outcome is a decision.

The tree is doing its job when each branch can be answered by a different person in parallel, and when answering all of them answers the top question with nothing left over.

How to tell: point at any two branches and ask whether an answer could belong to both. If yes, they are not mutually exclusive and the tree will double-count. Then ask what would have to be true for the top question to have a “yes” that none of the branches covers. If you can name one, a branch is missing.

Commit to a day-one answer#

Write your best guess at the answer before you have the evidence, then go looking for what would prove it wrong. This feels backwards and it is the point: an explicit hypothesis makes the analysis falsifiable and tells you which evidence is worth the effort of collecting.

The hypothesis is a commitment to be corrected, not to be right. The move is to name, for each branch, the cheapest piece of evidence that would change your mind, and go get that first. This is the same instinct as testing the riskiest assumption in Discovery Craft, applied to analysis instead of to product bets.

How to tell: for each branch, can you name a specific observation that would make you abandon it? If nothing could change your mind about a branch, you are not analysing it, you are defending it, and the work on that branch is already finished whatever the data says.

When it goes wrong: the common failure is falling in love with the day-one answer and quietly downgrading the evidence against it. The guard is to write the falsifying evidence down before collecting it, so you cannot move the bar afterwards.

Name who decides#

Ambiguity about who decides costs more than a wrong decision, because it is silent. Bain’s RAPID is the shortest usable form: who Recommends, who must Agree, who Performs, who gives Input, and who Decides. One person decides. Input is not a veto, and agreement is only for the people who can genuinely block.

For most of our work this is one line at the top of the document, and it belongs there before the analysis starts, not after it produces a conclusion somebody dislikes. See DRI for how this maps onto ownership day to day.

How to tell: ask two people in the room who decides. If you get two answers, you have found the real problem, and it is not the one you were analysing.

The frameworks, ranked by whether they earn their keep#

The consulting canon is the best-codified version of this craft. It is also where teams most often mistake a diagram for a thought. Adopt it in tiers.

Adopt now#

Use situationally#

• McKinsey 7S (strategy, structure, systems, shared values, skills, style, staff). Strongest as a diagnostic: when a change will not stick, 7S tells you which of the seven is fighting it. Reach for it when a rollout keeps sliding back, not when designing something new.
• Three Horizons. Allocating capacity across core, emerging, and option bets. Useful at half and quarter planning, meaningless weekly.
• Playing to Win choice cascade (Lafley & Martin): winning aspiration, where to play, how to win, capabilities, management systems. The clearest format for annual vision and half strategy. Not for features.
• Pre-mortem (Gary Klein). Before committing, assume it failed and write the story of why. The cheapest risk tool that exists, and it works because it gives people permission to voice doubts they would otherwise keep.
• Porter’s Five Forces and value chain. For market-structure questions, which we ask rarely and should ask properly when we do.

Skip#

• BCG growth-share matrix, the balanced scorecard, and most 2x2s produced to fill a page. A 2x2 not derived from an issue tree is decoration: it sorts things you already knew into quadrants you chose to make them fit.
• Any framework applied before the question has been written down as one specific, answerable question.

How to tell a real analysis from a well-dressed one#

Four checks, in order of how often they catch something:

1. Can the reader disagree with a specific branch? If the only available response is to accept or reject the whole conclusion, the decomposition did no work.
2. Does a number stand behind the load-bearing claim? Not behind every claim. Behind the one the recommendation rests on.
3. Is there a branch that came back “no”? An analysis where every branch supported the day-one answer is usually a case for the answer, written after the fact.
4. Would you have noticed if you were wrong? Name the observation you were watching for. If there is none, the rigour was presentational.

When it goes wrong, the repair is almost never a better framework. It is going back to the question sentence, which is usually where the vagueness entered.

The frameworks in depth#

Each of these now has its own page: what it actually says, how to tell whether you are using it correctly, and where it stops.

• The Pyramid Principle & BLUF — lead with the answer.
• Issue Trees & MECE — decompose a question without overlaps or gaps.
• Rumelt’s Kernel — diagnosis, guiding policy, coherent action.
• RAPID — who decides, written down before the argument.
• McKinsey 7S — why a decided change is not happening.
• The Influence Model — the four conditions behaviour change needs.
• Waste Before Capacity — remove the queue before adding people.

Where to learn it#

• Barbara Minto, The Pyramid Principle. The one non-optional book here. Read it once properly and it changes every document you write afterwards.
• Charles Conn and Robert McLean, Bulletproof Problem Solving. The most practical modern treatment of issue trees and hypothesis-led work, with worked examples end to end.
• Chris Bradley, Martin Hirt and Sven Smit, Strategy Beyond the Hockey Stick. On the outside view, and why most strategy processes produce socially negotiated plans instead of choices.
• A.G. Lafley and Roger Martin, Playing to Win. The choice cascade.

Related#

• Diagnosis is this method applied to a north star: value trees, sizing the prize, and landing a governing thought.
• Two-Pagers is the format most of these documents take.
• Discovery Craft is the evidence side: how to get inputs worth decomposing.
• Communication is answer-first applied to a live conversation rather than a document.