The MECE framework — what it is and how to use it

See more in the follow-up How to present a recommendation.

To change the behavior of an organization, you must address both the technical problems and the way people engage with those problems. The people problem is the hard one.  Still, you usually have to solve the technical problems too. The secret is not to get bogged down in the technical bit.

The MECE framework is one way to solve seemingly intractable technical problems. It allows you to spend less time on the technical side, and focus your energy helping other people change and grow.

I’ll give you an outline of the approach, and follow up with links to useful resources. If you have questions to ask or experiences to share, I want to hear from you!

SEE THE EXAMPLE SPREADSHEET

How the spreadsheet looks.

What is MECE?

Have you ever seen (or delivered) a 60-page technical report? How much did the client do (or even read) as a result? Consultants write these documents to prove their competence. They trap themselves by not defining the problem well enough. If the scope of the problem is unclear, when do you stop solving?

Big problems can be complicated, or they can be complex. Complicated problems are challenging, but solvable if you find the right approach. Technical problems are usually complicated. Complex issues have too many variables to understand. They resist formulaic approaches. The way a client team manages their problems is complex.

If you look at a technical problem and feel paralyzed, you recognize how complicated it is. The right way to solve a complicated problem is to impose structure on it. Breaking that problem down into several smaller problems makes it easier to solve.

MECE is a framework for breaking down big problems. It stands for Mutually Exclusive, Comprehensively Exhaustive. Here’s what that means:

• Mutually exclusive. All the subproblems we identify are different, and they don’t overlap.

• Comprehensively exhaustive. The subproblems cover all possibilities.

MECE gives you confidence that you’ve inspected every angle without wasting effort.

Questions or assertions

Check out both sheets of the example document to follow along.

There are two ways to structure a MECE analysis. You can think in terms of questions that you want to answer, or assertions that you want to check.

As an illustration, consider the Technical SEO Audit Checklist for Human Beings. The technical problem is whether the way a website was built is keeping users from discovering its content. We could frame this in two ways:

• Question. “Are there technical reasons that users can’t discover our content?”

• Assertion. “There are technical reasons that users can’t discover our content.”

Though these are similar, they split in different directions. For the question format, you try to generate all possible sub-questions that you should ask to answer the big question. For the assertion format, you produce all of the sub-assertions that would be necessary to prove your big assertion.

Breaking down the problem

Let’s use MECE to break down a technical problem. We want to understand the technical challenge quickly, confidently, and in a replicable way. These are the three steps to follow:

1. Familiarize yourself with available data.

2. Form a hypothesis about what to do.

3. Validate the solution.

We’re going to use both the question and assertion approach. We’ll start by using the question approach to expand the horizon of our analysis. Then, when we think we have the right answer, we’ll use the assertion approach to support our conclusion.

First, familiarize yourself with available data

Check out the first page of the example Sheet to follow along.

Imagine a client has come to you saying, “I just need to increase my organic traffic.” For Distilled, that’s a common scenario — and a difficult demand to fulfill! Where do you start with an open-ended problem like that? Applying MECE will give us some direction.

Let’s give it a try, starting from the top. More organic traffic is the goal. What are all the possible ways you could achieve that goal? Remember, the list must be mutually exclusive, and comprehensively exhaustive. These are the top-level possibilities I came up with:

Need more organic traffic

• Could we get more organic traffic if we add more content to the site?

• Could we get more organic traffic if we improve existing content?

• Could we get more organic traffic if we increase the perceived authority of our content?

MECE is recursive. You break the big problem into subproblems, and then you also break down each subproblem in turn. This continues until you can identify a physical action to solve the subproblems. Here’s a visual representation of the process:

For example, we could increase traffic to the site by adding more content that targets high-volume search terms. That’s a more focused problem than “increase organic traffic”. But it’s still a bit paralyzing. So let’s break the problem down further:

How can we increase traffic by adding content?

• Maybe create more content targeting competitive head terms?

• Maybe create lots of content targeting long-tail terms?

We’re getting warmer, but we’re not quite there. Let’s do one more try, focusing on the possibility of adding long-tail content:

How can we increase traffic with long-tail content?

• Could we automate content creation with proprietary client data?

• Can we design a content calendar the client could use to produce targeted content?

The process stops here because the problems are specific enough to generate the next physical actions. We could break the points down further, but that wouldn’t change the actions we’d take to research them.

This process is fully fleshed out in the spreadsheet. In the end, we come up with things like “Are there head terms in markets we aren't considering?” These are all answerable questions. They will drive action.

In fact, we wind up with the same actions we have for most projects. We need to do a technical audit. We need to brainstorm campaign ideas. The difference is that we now know exactly why we’re doing these things — and how much we need to invest in finding an answer.

Next, form a hypothesis

In the first step, you exposed all possible approaches to answering the big question. By doing that research, you’ll have formed an opinion about what the answer is. If not, collecting everything in one place should bring out some contenders.

Now it’s time to form a hypothesis based on your research and professional intuition. For instance, looking at the example spreadsheet, I start to suspect that creating long-tail content will be the best way for the client to increase their organic visibility.

That’s my informed opinion — I might be wrong. The hypothesis doesn’t have to turn out correct. That’s why you need to validate it.

Finally, validate your recommendations

Check out the second page of the example Sheet to follow along.

Validating is when we turn from the question approach to the assertion approach. This step is often skipped when tackling complicated problems without a formal process. It’s natural to form an opinion about what to do while you’re researching. It may even seem obvious that you have the right answer, and you might!

Imagine going to the client at this point with your opinion. You’d say, “I did a bunch of research and it pointed toward this recommendation.” While that’s better than going to the client with a massive audit, there’s still room for the client to doubt. It’s time to shift focus.

In step one, we analyzed every relevant facet of the “get more traffic” problem. Now we’ve got a hypothesis. We need to inspect this hypothesis from all angles. Let’s look at our example hypothesis, and what we need to show in support of it:

We should invest in creating content for long-tail keywords

• Improving rankings of existing content isn't practical.

• We can capture new long-tail traffic.

• Capturing long-tail traffic has a positive ROI.

As with the first step, we continue this process until each question could have a concrete answer. Check out the spreadsheet for inspiration.

We’re taking it from “the evidence points in this direction” to “we’ve looked at this from all relevant angles, and are confident we can support it”. This is the most important supporting evidence to present.

A little thinking goes a long way

David Allen says in GTD, “You have to think about your stuff more than you realize, but not as much as you're afraid you might.” That’s as true for big technical problems as it is for your own to-do system.

The art is breaking down the big problem into a set of sub-problems. That isn’t easy — but it’s more effective than trying to do a bunch of audits and hoping they’ll coalesce into meaningful insight.

Once you’ve mastered MECE, the three-step outline is simple:

1. Expose possibilities

2. Choose the most promising

3. Validate the chosen possibility

This process will efficiently arrive at a reasonable solution. Solving the complicated technical problem gives you more opportunity to collaborate with the client on complex people problems.

SEE THE EXAMPLE SPREADSHEET

Engaging with these ideas

Here are two books that have introduced me to these methods. If you’re interested in this approach to problem-solving, I recommend them!

• 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.
  
  

• The McKinsey Way by Ethan M. Rasiel. There are plenty of books on McKinsey and MECE. I happened to get my introduction to the concept here.

The MECE framework — what it is and how to use it was originally posted by Internet Marketing