The Pyramid Principle: Book Summary & Review (Part 3: Logic in Problem Solving)

This review is the third in a four-part series on Barbara Minto’s 2010 edition of The Pyramid Principle:

1. Logic In Writing
2. Logic In Thinking
3. Logic In Problem Solving (you are here)
4. Logic In Presentation

Parts 1 and 2 were about how to structure and order ideas once you have them. Part 3 shifts to something I find more interesting: how to figure out what problem you’re actually solving, and how to structure your analysis so you’re not just collecting data and hoping an answer appears.

This is the section of the book that most directly mirrors what I experienced at McKinsey. The first two parts are about communication. This one is about thinking.

Most People Skip The Problem Definition

The biggest mistake I see in my coaching work is people jumping straight to solutions. Someone comes to me and says they need to build a presentation. I ask what problem they’re solving. They look at me like I’m being difficult.

Minto makes the same observation. She devotes all of Chapter 8 to defining the problem before you try to solve it, and she frames it in a way I’ve found genuinely useful.

Her definition is straightforward: a problem exists when there is a gap between where you are now (she calls this R1) and where you want to be (R2). R1 is your current undesired result. R2 is your desired result. The problem is the gap between them.

This sounds almost too simple. But the reason it matters is that most people are fuzzy about both R1 and R2. They have a vague sense that something isn’t working, but they haven’t clearly articulated either where they are or where they want to be. And if you can’t do that, you can’t define the problem, which means you definitely can’t solve it.

The Problem-Definition Framework

Minto lays out a structured way to define any business problem. She uses four elements:

1. Starting Point / Opening Scene: What is the situation? What was happening before anything went wrong?
2. Disturbing Event: What changed? What happened to create the gap?
3. R1 (Undesired Result): Where are you now as a result?
4. R2 (Desired Result): Where do you want to be instead?

If this looks familiar, it should. These are the raw materials for SCQA, though the mapping is looser than it first appears. Minto puts the Starting Point and the Disturbing Event together inside the Situation, and then gives one rule for where the seam falls: read the elements left to right and down, and whatever is “the last thing known by the reader” becomes the Complication that triggers the Question. Which element that is depends on your reader, not on the framework. For a reader who already knows what changed, the Disturbing Event is old news and the Complication sits further along.

Minto’s point is that SCQA isn’t just a communication trick. It’s rooted in a genuine problem-definition process. The reason SCQA works as a structure for introductions is that it mirrors how problems actually develop in the real world: things were going a certain way, something changed, now we’re in an undesirable spot, and we need to figure out how to get somewhere better.

In my experience, spending 30 minutes filling out these four boxes before starting any analysis will save you hours of wasted work later. I have a simple worksheet I use with clients that is essentially this framework, and I’m always surprised how often they realize mid-way through that the “problem” they came to me with isn’t actually the real problem.

Seven Standard Problem Situations

One of the more practical parts of this chapter is Minto’s list of seven situations a reader can be in. The framing matters: she is not sorting problems by subject, she is sorting them by how far along the reader already is in looking for a solution. She groups them by how often they come up.

Her list, in her words and her groupings:

Most common circumstances

1. They do not know how to get from R1 to R2.
2. They think they know how to get from R1 to R2, but they are not certain they are right.
3. They know for sure how to get from R1 to R2, but they do not know how to implement the solution.

Variations on the most common circumstances

4. They thought they knew how to get from R1 to R2 and implemented it, but that solution turned out not to work for some reason.
5. They have identified several possible solutions, but don’t know which to pick.

Also possible but not common

6. They know R1 but cannot articulate R2 specifically enough to permit looking for a solution.
7. They know R2 but are not sure whether they are at R1 (typical benchmarking study).

The payoff is that each situation produces a different introduction, because the complication is always the last thing the reader already knows. A reader in situation 3 has settled on the solution and is stuck on execution, so a document arguing that the solution is correct answers a question they stopped asking. You have to know which of the seven you are writing into before you know what your document is for.

I won’t pretend that I walk around with these seven memorized. But I do find them useful as a diagnostic checklist when I’m helping someone who seems stuck. Often the reason they’re stuck is that they’re treating their problem as situation 1, where nobody knows how to get from R1 to R2, when they’re actually in situation 6 and cannot yet state R2 at all. Getting that wrong sends you looking for a route to a destination nobody has named.

Sequential Analysis: Five Questions

Defining the problem this way is the start of what Minto calls sequential analysis. She does not claim it. Her footnote credits B. Robert Holland’s Sequential Analysis, McKinsey & Company, London, 1972. It is five questions asked in order:

1. Is there/is there likely to be a problem (or opportunity)?
2. Where does it lie?
3. Why does it exist?
4. What could we do about it?
5. What should we do about it?

Minto then maps the five onto three jobs. Questions 1 and 2 define the problem. Question 3 tells you how to structure the analysis. Questions 4 and 5 find the solution. She adds a detail that ties this section back to Part 1: the answers to questions 1 and 2 become your introduction, and the answers to 3 through 5 become the body of the pyramid.

The order matters. I’ve seen many teams skip straight to question 4 or 5, proposing solutions before they’ve confirmed where the problem sits or why it exists. This is the consulting equivalent of prescribing medicine before running any tests.

At McKinsey, this kind of sequential thinking was baked into the process. You’d spend weeks on questions 1 through 3 before the team would even begin discussing solutions. It felt slow at the time, but I came to appreciate that the teams who did the upfront work almost always produced better answers than the ones who rushed to solutions.

Structuring The Analysis

Chapter 9 is where Minto gets into the mechanics of how to actually analyze a problem once you’ve defined it. She starts with an observation about the history of consulting that I find amusing and accurate.

She describes the old approach: a consulting team would show up, spend weeks gathering massive amounts of data, then try to figure out what it all meant. Starting from data leaves you with an overwhelming number of facts and no way to draw conclusions from them, and she has a number for the cost of it. A major consulting firm, unnamed, once estimated that “fully 60% of its fact-finding and analysis effort was wasted,” producing interesting exhibits only marginally connected to the client’s real problem.

The better approach, which she attributes to what “the better consulting firms now do,” is to start with a hypothesis and structure the analysis to prove or disprove it. This is essentially the scientific method applied to business problems: generate a hypothesis, design the analysis to test it, carry out the analysis, then decide what to do based on what you found.

Minto describes what the better firms settled on, and she is explicit that they are borrowing from science rather than inventing something:

Eventually they determined that what makes sense (and what the better consulting firms now do) is to structure the analysis of the problem before beginning to gather any data. To an extent they are replicating the classic scientific method, in which you:

• Generate alternative hypotheses
• Devise a crucial experiment (or several of them) with alternative possible outcomes, each of which will as nearly as possible exclude one or more of the hypotheses
• Carry out the experiment so as to get a clean result
• Plan remedial action accordingly.

She has a name for the step people find hardest, which is coming up with the hypotheses in the first place. She calls it abduction, and she sends you to Appendix A for it. Her short answer is that you do not invent hypotheses out of nothing. You get them by looking hard at the structure of the area where the problem showed up.

This is something I’ve written about before in the context of structured problem solving. The hypothesis-driven approach is one of the most powerful things I took away from consulting, and it’s underused outside of that world.

Diagnostic Frameworks

Minto describes three main types of diagnostic frameworks for structuring your analysis:

1. Showing the physical structure of a system. If you’re analyzing why a company’s distribution is inefficient, you might map out the actual physical flow of goods from warehouse to customer. This lets you see where bottlenecks or problems occur in the real process.

2. Tracing cause and effect. Start with the problem and work backwards through the chain of events that produced it. If sales dropped, was it because of fewer customers, lower prices, or reduced volume per customer? Each of these has its own set of causes that you can trace further.

3. Classifying possible causes. Group the likely culprits by similarity before you go looking for facts. Her example is a sales decline, split first into semi-fixed and variable factors, then into candidates you can test one at a time: a falling market for that type of goods, store coverage that doesn’t match the market, store size capping volume. Her instruction is that the split at the top has to be MECE, because that upper branch is what generates the possible causes below it.

In practice, I’ve found that the second and third types are by far the most common in consulting work. Tracing cause and effect is what you’re doing whenever you build a logic tree or issue tree to decompose a problem. Classifying possible causes is what you’re doing when you build a framework to organize your analysis.

The important thing about all three approaches is that they force you to structure your thinking before you start collecting data. You’re saying “here are the possible explanations, and here’s what I’d need to see to confirm or rule out each one.” That’s very different from “let me gather everything I can find and see what patterns emerge.”

Logic Trees

Minto’s discussion of logic trees will be familiar to anyone who has worked in consulting. The basic idea is simple: take a question and break it down into sub-questions that are mutually exclusive and collectively exhaustive. Each sub-question can then be broken down further.

For example, if the question is “how can we increase profits?”, you might break it into “increase revenue” and “decrease costs.” Revenue can be broken into “increase price” and “increase volume.” Volume can be broken into “more customers” and “more purchases per customer.” And so on.

Minto’s contribution here isn’t the idea itself, logic trees predate her book. What she does well is connect them back to the broader framework. A logic tree is a tool for generating hypotheses about solutions. You’re not trying to list every possible action. You’re trying to create a structure that ensures you haven’t missed a major category of solution.

The common mistake with logic trees, in my experience, is making them too detailed too early. People will build a five-level tree before they’ve confirmed that the problem is even where they think it is. A two- or three-level tree is usually enough to frame the initial analysis. You can always go deeper once you’ve narrowed down which branches matter.

Issue Analysis

One section I found particularly interesting is Minto’s short history of issue analysis. She hedges the attribution herself, writing that “so far as I can ascertain” the phrase belongs to two McKinsey consultants, David Hertz and Carter Bales, who coined it while working for New York City under Mayor John Lindsay in the 1960s. She also gives it a lineage: she traces the method back to systems analysis, which the U.S. Department of Defense was using at the time, and that it was built for decisions where more than one option had merit and the criteria for judging them conflicted.

The key innovation was framing the analysis around yes-or-no questions rather than open-ended topics. Instead of having a workstream called “analyze the budget,” you’d frame it as “is the budget deficit primarily caused by revenue shortfalls rather than spending increases?” This forces clarity about what you’re actually trying to determine, and it makes it much easier to know when you’re done.

Minto is precise about what these questions are for. Their answers “unambiguously identify or exclude the contributing causes of a problem,” and she says they “also have the great advantage of telling you in advance when you will be finished with your research.” She also draws a line I had been blurring: a diagnostic framework of this kind should not be confused with a decision tree, because a decision tree reveals the need for action while this generates questions.

I’ve used this approach many times in my own work and coaching, and I can confirm it’s one of the most practical tools in the consulting toolkit. Open-ended workstreams tend to drift. When you frame each piece of analysis around a specific yes-or-no question, the team knows exactly what they’re trying to prove and exactly what evidence would settle the question.

Revealing Flaws In Your Thinking

Structuring the analysis also works backwards, as a check on thinking you have already done. Minto shows a list of ten “major issues” a team had drawn up for a study on energy costs. As a list, every item looks like a reasonable thing to look into. Mapped onto a structure, most of them slot into branches of a choice diagram, and her verdict on the rest is flat: “You can see that Issues 7, 8, and 9 simply don’t relate to the subject.”

That is the value of the exercise. Nothing about issues 7, 8, and 9 looks wrong on a list. They only become visible as the wrong questions once there is a structure for them to fail to fit.

This connects directly to the ideas from Part 2 about avoiding “intellectually blank assertions.” If you can’t organize your ideas into a coherent logical structure, if they resist being grouped in a way that supports a clear summary, that’s a signal that the thinking isn’t done yet.

In consulting, the phrase for this was “the storyline doesn’t hang together.” It meant that the individual pieces of analysis might each be correct, but they didn’t add up to a coherent argument. The fix was always the same: go back to the problem definition, check your structure, and figure out where the logic breaks down.

My Takeaway

Part 3 of The Pyramid Principle is where the book gets most directly practical for anyone doing analytical work. The first two parts are about how to communicate ideas once you have them. This part is about how to develop the ideas in the first place.

If I had to distill it into one principle, it would be this: structure your thinking before you start your analysis. Define the problem before you collect data. Generate hypotheses before you interview stakeholders. Build your logic tree before you build your spreadsheet.

This runs counter to how most people work. The natural instinct is to gather information first and figure out what it means later. But as Minto argues, and as I’ve seen over and over in my own work, that approach leads to wasted effort and muddled conclusions. The teams that take the time to structure their analysis upfront are the ones who end up with clear, convincing answers.

Part 4 picks up from here: once the thinking is done, how you get it onto a page or a screen without losing it on the way.

If you’re ready to practice these skills in a structured way, consider enrolling in Think Like a Strategy Consultant. The course includes hands-on exercises in problem definition, hypothesis generation, and logic tree construction.