Effecting Change: Discovering the Technical Problem

Distilled’s Seattle office once engaged with an enterprise software company, who intended to merge their web properties onto a single domain. Leadership suspected gathering them together would be better for branding. But it turned out to be no small task — more than eighty different sites housed bits of their content!

As we talked with their team, we saw why the sites had proliferated. The company’s web team coded their brand site by hand. As a result, marketing teams couldn’t upload or change their own content. Marketers felt disenfranchised, so savvy employees gave themselves a voice. They made their own platforms.

As outside observers, we saw that this consolidation would be a temporary fix. The client needed to simplify content creation. Otherwise, they’d wind up playing whack-a-mole with their own teams. Painting a clear picture of these management issues is an important part of what we do. Effecting change is an important part of Distilled’s core values. Often the way a client manages a problem is more impactful than the problem itself!

Still, the technical problem is real. The technical problem is the thing that takes expertise to resolve. And to have a voice in the conversation about content creation, we needed to first support the client with their site consolidation. We had to show our expertise and prove ourselves trustworthy partners.

To build that trust we needed an efficient and effective approach to solving technical problems. The method I’m outlining in this post is how I resolve difficult technical problems because it lets me focus my effort on what matters most. The approach respects the importance of the technical problem and acknowledges that there is more to the whole story.

SEE THE EXAMPLE SPREADSHEET

How the spreadsheet looks.

Start with MECE

Have you ever seen (or delivered) a 60-page technical audit? How much did the client do (or even read)? Consultants write these documents when they try to tackle a big problem head-on. When the scope of the problem is unclear, when do you stop working?

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 — or poorly understood — variables. They resist formulaic approaches. The way a client manages their problems is complex.

When you look at a technical problem and feel paralyzed, you’re recognizing how complicated it is. But complicated problems are vulnerable to structured approaches. By breaking that problem down into several smaller problems, the solution is known.

In this post, we’ll break a big problem down with the MECE principle. This process helps expose the substructure of the problem. It’s easier to explain by example — if you’ve seen the Technical Audit Checklist for Human Beings, that spreadsheet is MECE.

MECE stands for Mutually Exclusive, Comprehensively Exhaustive. Here’s what that means:

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

• Comprehensively exhaustive. The subproblems cover all possibilities.

Breaking down the problem with MECE principles lets you feel confident that you’ve inspected all relevant angles. Let’s look at how this concept works in the rest of this article.

Three steps to technical discovery

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 under the context in which you’re working.

It’s an intuitive process — not controversial. The difference is applying a principle like MECE at each step to focus your attention.

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 need to increase my organic traffic.” For Distilled, that’s a surprisingly common scenario — and a difficult demand to fulfill! Where do you start with an open-ended problem like that? Applying the MECE principle will give us a direction to go in.

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? These are the top-level possibilities I came up with:

Need more organic traffic

• Maybe add more content to the site

• Maybe improve existing content

• Maybe increase authority of content

Applying MECE is recursive. You don’t just break the big problem into subproblems, you also break down each subproblem in turn. This continues until you can clearly take 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 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 “If we cast a wider net, are there head terms in markets we aren"t considering?” These are all questions that will drive action and give us confidence.

In fact, we wind up with some fairly common actions. We need to do a tech audit. We need to brainstorm campaign ideas. The difference is that we now know exactly why we’re doing them — and therefore how to invest in each.

Next, form a hypothesis

In the first step, you exposed the possible solutions. 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. Looking at the example spreadsheet, I’m starting 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.

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 a better approach 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:

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 subproblem can be given 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 this skill, the three-step outline is simple:

1. Expose possibilities

2. Choose the most promising

3. Validate the chosen possibility

Confidently executing this process efficiently exposes technical solutions. Solving this complicated problem gives you more opportunity to collaborate with the client on complex problems, like the impact of their management practices.

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 is a book with great ideas in it, 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.

Distilled