Overview
The "So What?" test is not attributed to a single inventor — it is a synthesis discipline embedded in consulting firm training, most clearly described in Ethan Rasiel's The McKinsey Way (1999) and Paul Friga's The McKinsey Engagement (2009). It flows naturally from Barbara Minto's Pyramid Principle (see that page): the "so what?" question is the mechanism for climbing the pyramid from supporting facts to governing thought. Every time you have a piece of data or analysis, asking "so what?" produces the next level up — the insight the data implies.
The insight hierarchy has three distinct levels, and most analysts stop too soon:
- Data: "Revenue declined 12% in Q3." Raw fact. True but inert.
- Observation: "Revenue declined 12% in Q3, concentrated in the mid-market segment." Pattern identified. More useful, but still not actionable.
- Insight: "Revenue declined 12% in Q3 in mid-market because customers are choosing the competitor's self-serve option for smaller deals — which means our enterprise-only sales model is structurally misaligned to this segment." Root cause identified. Recommendation implied. Actionable.
The gap between observation and insight is where most analytical work stalls. Observations describe what happened. Insights explain why it happened and what it means — they carry a "therefore" or "which means" embedded in them. The "so what?" test is the forcing function that crosses that gap.
The test applies at every level of the pyramid. After each piece of analysis: so what? After each supporting argument: so what? After the overall recommendation: so what does this mean for the client's decision? The question never stops being useful.
When to Use It
Continuously — in the synthesis phase of any engagement, before delivering any recommendation, when reviewing any slide or section of a deck, and especially when the team is running out of time and needs to convert analysis into argument quickly. The "so what?" test is the fastest way to determine whether a piece of analysis has been synthesized or just reported.
How It Works
The mechanics are simple. For every finding, ask:
- "So what?" — what does this fact, observation, or analysis imply? What follows from it?
- "For whom?" — so what for the client? For their customers? For their competitors? The implication changes depending on the perspective.
- "What should they do?" — does this implication point toward a specific action? If yes, the insight is complete. If not, ask "so what?" again.
- "Can I state this in one sentence?" — a genuine insight can be expressed as a single clear sentence that contains both the finding and its implication. If it requires three paragraphs to explain, it hasn't been synthesized yet.
The test can also be applied to check whether an argument is circular. "Sales are declining because customers aren't buying" answers "so what?" with nothing — it restates the problem. "Sales are declining because the product's onboarding experience has a 40% drop-off at step three, which correlates directly with churn in the first 90 days" answers "so what?" with an implication: fix the onboarding experience, specifically step three.
The inverse test: for any finding you're about to present, ask "so what would happen if this were not true?" If the answer is "nothing would change," the finding doesn't belong in the presentation.
Running It in a Session
Apply the "so what?" test throughout the session, not just at the end. When the Analyst brings a finding to the team, the Lead Consultant's first question should be: "So what does that mean for our recommendation?" If the Analyst can't answer immediately, the finding hasn't been synthesized yet — put it aside and focus on what it would take to get it to insight level.
The Skeptic's most useful single intervention in any session is asking "so what?" after a finding that the team is treating as complete. It either forces the team to articulate the implication (which sharpens the recommendation) or reveals that the finding doesn't yet support an implication (which prevents it from being presented as if it does).
In the debrief, one of the most revealing questions is: "Did the recommendation actually follow from the analysis?" Teams that passed the "so what?" test throughout the session almost always have a recommendation that answers this question clearly. Teams that didn't have a gap somewhere between the analysis and the conclusion.
Common Pitfalls
- Stopping at observation — identifying a pattern but not explaining what it means; most analytical work stalls here because observations feel like insights when they're being generated
- The implicit "so what" — assuming the audience will supply the implication themselves; they won't, or they'll supply the wrong one; make it explicit
- Circular reasoning — answering "so what?" with a restatement of the fact ("revenue is declining because we're selling less"); push for the causal explanation, not the description
- Insight without action — a genuine insight implies something to do; if the "so what?" chain ends at an interesting observation with no actionable implication, keep asking
- Applying it too late — using the "so what?" test only in the final synthesis phase rather than throughout the analysis; catching shallow findings early saves time and produces better analysis
References & Further Reading
- Rasiel, Ethan M. The McKinsey Way (1999, McGraw-Hill) — describes the synthesis discipline in practice
- Friga, Paul N. The McKinsey Engagement (2009, McGraw-Hill)
- Minto, Barbara. The Pyramid Principle (1987, Pitman) — the structural framework within which the "so what?" question operates
Recommended Books
- The McKinsey Way — Ethan Rasiel
- The Pyramid Principle — Barbara Minto
- Bulletproof Problem Solving — Conn & McLean