How To Deliver Better SEO Strategies (Part 1)

I’ve been in enough interviews, pitches, and strategy meetings (ironically) to determine that we’re really not that great at being strategic. 

Whenever I present interview candidates with a business problem, 9 out 10 of will talk through action plans rather than strategise. 

Speakers at industry conferences deliver awesome presentations on creative content and advanced technical SEO, yet feature strategy in the minority. 

In strategy meetings, we show clients detailed slides on technicalities rather than telling stories with data, and painting a vision for the future. 

Why is that? Primarily it’s because SEO is inherently tactical. We divide our service into sub-services; outreach, content, technical etc. and we sell it as such. As resolutions to technical problems rather than big picture thinking. 

And for most of us, we’re programmed this way. It’s just hard to be strategic. Naturally, we just do things. The day-to-day – acting from routine. 

To deliver effective strategies, we need to get our heads up. Replace bottom-up with a top-down approach and solve complex SEO challenges in the most efficient way possible. 

Frameworks can support this change in thinking. In this post, I’ll introduce one from a well known consulting firm that has transformed the way I think about strategy.

There’s a better way to do things

We need to take some learnings from our friends over in the consulting world. 

Top global consulting firms such as McKinsey has strategy built into their core. They’ve built world-renowned strategic frameworks and have a deep-rooted culture for problem solving.

You can apply so much of their strategic expertise to help deliver better SEO strategies. Even if you act on 10% of the principles I suggest in this article, it’s a leap in the right direction. 

6 Steps to Solving Business Problems

I’ll be sharing some of the key steps of McKinsey’s Problem Solving Framework, and how it can be adopted by SEOs. 

I’ve seen multiple interpretations of this, but in the main there are 6 steps: 

1. Defining the problem
2. Structuring the Problem
3. Prioritising Issues
4. Plan & Execute Analyses
5. Synthesise Findings
6. Developing Recommendations

In part 1, I will describe how you can use steps 1–4 in practice, using the same example throughout. 

*I’m not McKinsey alumni, nor do I have any affiliation with McKinsey. This is my adaptation of their framework for SEO, following an inspiring read of McKinsey Mind, and from supplementary research. 

It’s starts at the problem 

Understanding the client’s problem is fundamental to solving it. If you don’t know exactly what the problem is you’re trying to solve, how do you expect to develop a strategy to solve it? 

I’ve seen it many times over where SEOs (including myself) haven’t grasped the client’s problem early on, only for the strategy to snowball entirely in the wrong direction. 

It looks a lot like this: 

Client: 

“We want to increase organic traffic by 20%” 

But what they really mean is: 

“We migrated in October and our organic traffic dropped by 20%. We want to increase it back to what it was pre-migration in 6 months.”

In the above slightly exaggerated scenario, the strategy would be wildly different without understanding the client’s real problem. 

If a client’s problem is vague, it’s your job to understand it.

McKinsey consultants use a problem statement to concisely define the problem, underpinned by SMART principles. 

This is a structured way of asking the right questions to achieve a workable objective. 

It starts at the initial scoping meeting with your client. Don’t take their objectives at face value – understand them. Challenge them. 

Use the Characteristics of SMART to frame your questions in a way to help the client define a smarter objective. 

Using the first scenario above as an example, you could ask: 

“Can you be more specific? Why do you want to achieve 20% more organic traffic?” 

“How relevant is organic traffic as a goal for your business? Was the traffic you lost during the migration driving conversions?”

Use data insights to shape objectives

Most of the time, clients won’t have the answer. Data from Google Analytics and Search Console can be the bridge to this chasm.

Bring some insight to your first meeting. You don’t need a library of data. Just enough to get more information from your client, and narrow the credibility gap. Your insight will help them to trust you, whilst forming a stronger objective. 

Using the first scenario again, after a brief look in Google Analytics and Search Console, you may ask:

“We noticed that your organic traffic started to dip from October, what happened?”

“Crawl errors have quadrupled since October, did you migrate your website?”

Generally, you’ll want to look out for: 

• Anomalies in organic traffic: are there peaks and troughs that don’t fit with seasonality or trend? 
• Product categories that drive organic revenue: do 20% of products drive 80% revenue? 
• Brand vs non-brand: does the majority of organic traffic come from brand queries? 

Data-led questioning will improve your objectives. With some structured questioning, the objective in our example changed from growth to recovery, which would lead you down a very different path. 

You can only discover the yellow brick road to guide you to achieving client objectives, by knowing, really knowing, their problem.

Start to:

• Ask SMART questions to build SMART objectives. 
• Collect some data to help understand their problem and shape your objectives.

Use structure to strengthen your thinking

It was a post by Distilled that first introduced me to a process to help frame problems. It immediately clicked with me that to solve complex SEO problems, you need to impose structure on them. 

I later read The McKinsey Mind which emphasised this point. To quote from the book, “For Mckinseyites, structure is less a tool and more a way of life.” 

To add structure to the problem solving process, you need to define the boundaries of the problem and break it down into its component parts. To do this, use MECE. 

MECE and Issue Trees

MECE (Mee-See) is a framework for breaking problems down. It stands for Mutually Exclusive, Collectively Exhaustive.

It’s a way of grouping sub-problems that are distinct from each other; mutually exclusive, and making sure there are no gaps in logic; collectively exhaustive. 

Issue trees use MECE structures to outline a comprehensive map of the problem. There are two main types of issue trees; solution trees and problem trees. Solution trees ask ‘how’, and problem trees ask ‘why’. 

To understand how this works in practice, it’s worth exploring a non-SEO example. 

How does Elon Musk change the world by structuring problems? 

Elon follows a framework called first principle thinking. The thinking behind it is very similar to that of an issue tree. 

“It is important to view knowledge as a sort of semantic tree. Make sure you understand the fundamental principles, ie. the trunk and big branches, before you get into the leaves/details or there is nothing for them to hang on to.” — Elon Musk

Elon founded The Boring Company in 2016, an infrastructure and tunnel construction company. A business that aims to solve the increasing traffic congestion problem in Los Angeles, and beyond. 

Let’s look at how he got there using a solution tree, a how tree:

While this tree looks simple, Elon breaks problems down the right way. Most problems are numerical, and traffic congestion is no different — it’s a supply and demand problem. Fundamentally, you can either lower the demand for cars or increase the supply of roads. Branching out logically in the first layer, makes it easier to reach a feasible solution.

When breaking down the traffic congestion problem, creating tunnels becomes the only viable option. Reducing demand for cars requires a culture shift, and creating flying cars will be noisy, and potentially dangerous. 

Apply Issue Trees in SEO

Problems are problems, whether you’re recovering from a website migration or solving traffic congestion. Granted, some are more complex than others, but we can structure them all in the same way. 

Not only do issue trees make it easier to break down problems, but they get buy-in from your team too. Issue trees are most effective when your entire campaign team is in the room. When each member of the team has weigh-in on your strategy, you get buy-in. And when you have buy-in, each member of your team will be working towards a shared vision. 

Issue trees can be used even in the absence of data. In SEO though, it’s difficult to be problem-specific without at least some data to inform your logic. The problem is, we rely on data too much. To solve SEO challenges efficiently, our hunger for data must be balanced by a trust in our instinct. 

Intuition is as important as facts

There are many sound bites from the book The McKinsey Mind, but none stuck with as much as, “intuition is as important as facts.” and “solve the problem at the first meeting.” 

Gut feeling is ill advised in a data-informed industry like SEO, but you need less data than you think you do. 

Move away from 100 page audits

Move away from 100 page audits, and instead rely on the minimum amount of data you need to form a hypothesis you can validate. I call this MVD; minimum viable data. 

Start with the end in mind and work backwards. In The McKinsey Mind, the author illustrates this point by describing a pen and paper maze you might find in a newspaper. It’s easier to solve the maze by tracing the route from the finish to the start, because by already knowing where the solution is, you can eliminate a lot of paths that lead to dead ends. 

The issue with large audits is that you start at the beginning. It’s common to have multiple audits, from technical, content and outreach, amassing hundreds of recommendations. Smart SEOs will prioritise issues, but that still leads you down paths with dead ends. For example, what if you provided detailed recommendations in your technical audit for a change to your client’s main navigation, only to find that their development team couldn’t implement it?

It’s an inefficient way to work. You can avoid these dead ends by forming an initial view of what the problem is, then asking questions and justifying it with data. 

Recommendations: 

• Automate auditing as much as you can. Be effective, not productive. 
• Use outcomes over recommendations. Don’t waste time recommending something before you understand how it fits within the context of your wider strategy. 

Why did the migration go wrong? 

If we explore our migration problem once more, a problem tree can help you understand why it went wrong. And when you understand why, you can learn how to recover.

I’ve mapped out the problem in the issue tree below. This is a simplified view with only three layers but you can can extend your branches across as many layers as needed. Stop when the branch reasonably explains the root of the problem. 

For the purposes of our example, I’ve only went a level deeper on the ‘content is less authoritative’ bucket. If you can falsify a bucket straight away, there’s no need to go a level deeper. Let’s say our audit highlighted that there were no stray noindex tags, and Google could index all pages. We wouldn’t then need to explore it in more granularity, as we proved the bucket to be false. 

I’ve segmented the first layer into two mutually exclusive buckets. You can usually treat the first layer as expressions in a mathematical equation. 

Lower rankings in search results or less pages in search results, or both, equals a drop in organic traffic. 

You could argue that lower engagement on search results or less demand for search queries may also contribute to a decrease in organic traffic, but I’ve excluded those paths for the purpose of this example. 

Being numerical makes it easier to falsify. If you discovered that rankings for existing queries didn’t drop post-migration, you could eliminate that entire branch from the tree. 

Forming an initial hypothesis

Having reduced the problem to its constituent parts, I am then able to form an initial hypothesis (highlighted in orange). This is part instinct, part fact-based analysis — the perfect combination for effective problem solving. 

Let’s say our brief technical audit on the website highlighted that the vast majority of legacy URLs were not redirected as part of the migration. I could use this information, as well as my experience (poorly managed redirects can cause chaos), to recommend that this assumption be tested further. Like the maze anecdote, I am starting with the solution and working backwards. 

The QDT (Quick and Dirty Test)

The QDT, according to McKinsey, asks “what assumptions are you making that that need to be true, in order for your hypothesis to be true”. 

In the context of our example, what three things need to be true to prove that organic traffic dropped following the migration because redirects weren’t employed. 

They could be: 

1. Rankings dropped for queries associated with old pages that weren’t redirected. 
2. A decrease in rankings led to a drop in clicks for the queries. 
3. A drop in clicks for the queries resulted in a drop in organic traffic for the pages.  

If the first statement is incorrect, we can disprove our hypothesis. If all three assumptions are proven to be true, our hypothesis is true. 

Use the QDT in the same team meeting as your issue tree. Assumptions can often be disproved immediately, and you can quickly move onto another. Or, you will need to justify your assumptions with data analysis. 

Now it’s time for data

Up until now, I’ve recommended using as little data as possible to come up with a hypothesis. But now that you have a set of assumptions that need validated, you can set the data wheels in motion. 

Design your data analysis around your QDT. If we revisit our three assumptions about why poorly managed redirects resulted in a decrease in organic traffic, you can easily identify the data you will need. 

1. Rankings dropped for queries associated with old pages that weren’t redirected. Data: Tracked rankings or Google Search Console (GSC) queries. 
2. A decrease in rankings led to a drop in clicks for the queries. Data: Avg. rankings and clicks for the same queries in Google Search Console. 
3. A drop in clicks for the queries resulted in a drop in organic traffic for the pages. Data: Blended click data for queries and organic traffic to pages from Google Analytics — potentially using Data Studio. 

Always think, what data will be the most effective to prove my assumption true? In your team meeting, data analysis can be delegated out as actions from the meeting. Much like using issue trees to structure the problem solving process, use your set of assumptions to structure the design of your data analysis. 

Recommendations: 

• Use buckets in your issue tree you can falsify. Be numerical. Treat the first layer as expressions in a mathematical equation. 
• Form an initial hypothesis using your intuition and MVD. 
• Use the QDT to form assumptions that need to be proven true, for your hypothesis to be true. 
• Design your data analysis around your assumptions and work out the most effective way of getting the data you need. Delegate data analysis out as actions from your meeting. 

In part 2 of this guide, I will describe how Mckinsey has taught me to tell the story behind data and present it in way that makes sense to clients, no matter what their digital maturity. 

If you‘ve got any questions on the framework, please let me know in the comments below. And if you want to hear more from me, you can subscribe to my newsletter at theweeklyseo.com where I curate my favourite SEO articles, and a short piece of insight every week. I’m also available as a freelance SEO consultant to apply my strategic SEO framework for your own business.