This review is the third in a four-part series on Barbara Minto’s 2010 edition of The Pyramid Principle. If you’re just finding this, here are the links to the full series:

  1. Logic In Writing
  2. Logic In Thinking
  3. Logic in Problem Solving
  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. This maps directly onto SCQA. The Starting Point is the Situation. The Disturbing Event is the Complication. R2 gives you the Question (how do we get there?). And your analysis produces the Answer.

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 observation that most business problems fall into one of seven patterns. She identifies them as standard situations that each lead to a different type of question:

  1. You know R1, you know R2, and you need to figure out how to get from one to the other (“How do we get there?”)
  2. You know R1 but aren’t sure what R2 should be (“What should our goal be?”)
  3. You know R2 but aren’t sure where you actually stand (“Where are we really?”)
  4. You know something went wrong but aren’t sure what (“What’s actually happening?”)
  5. You have a solution someone proposed and need to evaluate it (“Will this work?”)
  6. You implemented a solution and it didn’t work (“Why didn’t it work?”)
  7. You have multiple possible solutions and need to choose (“Which one?”)

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 type 1 (how do we get there?) when it’s actually type 4 (what’s actually happening?). Getting the problem type right changes everything about how you approach the analysis.

Sequential Analysis: Five Questions

Minto also presents what she calls “sequential analysis” — a process for working through a problem that boils down to five questions asked in order:

  1. Is there a problem? (Or is the perceived gap imaginary?)
  2. Where does the problem lie?
  3. Why does it exist?
  4. What could we do about it?
  5. What should we do about it?

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. The problem, she argues, is that starting from data is backwards. You end up with mountains of information and no framework for making sense of it.

The better approach, which became the standard at firms like McKinsey, is to start with a hypothesis and then structure your 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 frames it as a four-step process: “devise a hypothesis about what is going on, devise an experiment to prove or disprove the hypothesis, carry out the experiment to get a clear yes or no, and then plan the action implied by the result” (The Pyramid Principle, p. 127).

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 potential explanations into categories. Minto gives the example of classifying potential causes of a manufacturing problem into equipment issues, material issues, and personnel issues. This is essentially MECE applied to diagnosis.

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 create 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 discussion of the history of issue analysis at McKinsey. She credits David Hertz and Carter Bales, two McKinsey consultants, with developing the approach in the 1960s during a study of New York City’s financial problems.

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 makes the point that the answers to these yes-no questions should link logically: “if yes to question 1, then we need to check question 2; if no, we move to question 3.” This creates a decision tree that guides the entire project.

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

The last piece of this section that I want to highlight is Minto’s discussion of how structured analysis can reveal flaws in your thinking. She gives several examples in the book where grouping ideas into a logical structure exposes gaps or contradictions that weren’t visible when the ideas were listed individually.

One example she uses is a set of recommendations about energy costs. When the ideas were in a simple list, they seemed reasonable. But when grouped into a logical structure, it became clear that some of the recommendations contradicted each other, and others were actually solving different problems than the one stated.

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.

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.

Enroll in Think Like A Strategy Consultant