What Is the MECE Principle?

Imagine starting a job as Director of Growth for a SaaS startup. The company measures your success by growth in revenue for your subscription product line. It’s a big task, the pressure is high, your mind reels as it grasps for a starting point. After mulling it over you take your trusty whiteboard marker, and on the nearest board you write:

How might we increase revenue?

  1. How might we increase signups?
  2. How might we decrease churn?
  3. How might we increase subscription fees?

These issues cover all relevant ideas, and none of them overlap. This simple example shows the essence of MECE. Examining each of these problems will be more straightforward than the original “increase revenue” prompt.

MECE definition

MECE stands for mutually exclusive, comprehensively exhaustive. It is a framework for solving complicated problems. When you apply it to a problem, you break that problem into subproblems that are mutually exclusive (they don’t overlap) and comprehensively exhaustive (they cover all possibilities).

When to use MECE

There are two kinds of problems – the complex, and the complicated. Complex problems have many overlapping pieces with crosstalk and feedback among them. Complicated problems have lots of parts that ultimately, you can reconcile, even if it requires supporting tools.

Designing a top-down social welfare program that impoverished rural communities will accept is a complex problem. Deciding whether to sell a business you own is a complicated problem.

When you have a complicated problem, that’s when MECE will be most helpful. Partitioning the problem into smaller problems makes it easier to solve.

How to use MECE

There are two ways to structure a MECE analysis.

First, you can take a hard question, and break it down into sub-questions. The introductory example at the top of this article uses that approach. You take a wide field of possible investigations and partition that into smaller areas. It’s useful when we’re trying to discover more approaches to solving a problem.

Second, you can take an assertion, and break it down into sub-assertions. This approach is useful if we’re trying to use our knowledge of a problem to make an informed decision. We’ll illustrate this use in the example of the following sections.

Once you’ve chosen a flavor, there are only three steps:

  • apply MECE, recursively, until you can confidently speak to the resulting issues,
  • evaluate each subproblem, and
  • reflect on what you’ve learned.

Example MECE application

Technical Audit Checklist spreadsheet


Let’s use MECE to break down an actual investigation that Brainlabs SEO consultants perform daily. The fundamental question is, “does anything about the way we implemented our site prevent us from getting as much organic search traffic as we could?”

Because we understand this problem, instead of taking the question approach, we’ll formulate it as an assertion that “there is a technical reason that our website receives less organic traffic than it could.” We must discover whether this is true, and if it is, what makes it so.

First, apply MECE

We’ve already formulated an assertion. Using MECE means breaking that down into smaller claims:

There is a technical reason that our website receives less organic traffic than it could.

  • There is a technical reason Google’s index doesn’t include good content.
  • There is a technical reason indexed content isn’t ranking as prominently as it could.
  • There is a technical reason the content has a lower click-through rate than it might.

These are still somewhat complicated. We can’t look at one of these and trivially formulate a plan to address it. We’ll have to apply MECE recursively. After breaking down the initial problem, we break down the smaller issues in turn. That continues until we can identify a physical action to address the issues. 

problem subproblem flowchart

Let’s break down that first sub-assertion further:

There is a technical reason Google’s index doesn’t include good content.

  • We present bad URLs to crawlers as good.
  • URLs are not discoverable by crawlers.
  • Duplication is causing Google to ignore pages.
  • Our site serves too many unique pages.
  • On-page content is not readable by crawlers.
  • We haven’t shown where we do and don’t want content discovered or indexed.
  • Our site doesn’t respect mobile-first best practices.

We’re getting warmer, but we’re not quite there. Even if one of these points were true, there would be many potential underlying causes. Let’s zoom in one level deeper:

We present bad URLs to crawlers as good.

  • Error pages return 200 status codes.
  • Internal links point to URLs returning 4XX or 5XX status codes.
  • Robots.txt doesn’t block URLs that don’t belong in the index.
  • Sitemaps contain valid URLs we want to keep out of the index.
  • Sitemaps contain invalid URLs.

That’s more like it! We stop here because the problems are specific enough to generate the next physical actions. In this case, we’re only going deep on a single branch of this tree to keep things simple. The spreadsheet fully fleshes out the example.

Next, evaluate each subproblem

With this exhaustive (and, well, non-overlapping) catalog of technical issues, our analysts can confidently investigate whether our clients’ organic search programs are suffering from technical issues. Because the system is MECE, they know they’re checking everything, and that they won’t duplicate their effort.

The team goes through the entire checklist, line-by-line. They uncover which assertions turn out to be true, and collect supporting evidence.

Finally, reflect on what you’ve learned

When we promise a client that we’ll help them resolve such technical issues, we don’t mean that we’ll present them with a spreadsheet. Resolution means fixing the issues that matter.

We reflect on our findings. If there is a technical problem, is it damaging? Is the damage worth fixing? If it is worth fixing, what lead to it happening in the first place? What’s the solution? Our MECE approach guarantees we’ve done a competent investigation. It’s up to our consultants to determine the next steps.

For instance, let’s say that a client’s sitemap contains invalid URLs. We checked for that! Now, by working our way, inside-out, if you will, through the MECE assertions in the sheet, we will be able to explain exactly why that matters:

“Your sitemaps contain invalid URLs. Therefore, we know that we present bad URLs to crawlers as good content. Because of this, we can reasonably expect Google not to index all the content you want in the index.”


Further reading

  • The McKinsey Way by Ethan M. Rasiel. MECE is attributed to former McKinsey employee Barbara Minto.
  • Flawless Consulting by Peter Block. This book has great ideas, but it takes some effort to parse. I’ve created an internal training course for our team to share its principles in a more structured way. For those who are willing to invest in its ideas, there is the potential for a huge payoff.
  • How to Present a Recommendation.