How to Make a Technical SEO Recommendation
The author's views are entirely their own (excluding the unlikely event of hypnosis) and may not always reflect the views of Moz.
After you've put in the work with technical SEO and made your discoveries, there's one thing left to do: present your findings to the client and agree on next steps. And like many things in our industry, that's easier said than done. In this week's episode of Whiteboard Friday, Benjamin Estes from Distilled presents his framework for making technical recommendations to clients and stakeholders to best position you for success
Video Transcription
Hi. My name is Ben. I'm a principal consultant at a company called Distilled. Welcome to Whiteboard Friday. Today I'd like to talk to you about something a bit different than most Whiteboard Fridays.
I'd like to talk about how to work with clients or bosses in a different way. Instead of thinking about technical SEO and how to make technical discoveries or see what problems are, I want to talk about how to present your findings to your client after you've done that discovery.
Problem
What's the problem that we're dealing with here? Well, the scenario is that we've got a recommendation and we're presenting it to a client or a boss.
Easy enough. But what's the goal of that situation? I would argue that there's a very specific goal, and the best way to look at it is the goal is to change the action of the individual or the organization. Now, what if that wasn't the case? You know, what if you worked with a client and none of their actions changed as a result of that engagement? Well, what was the point?
You know, should they have even trusted you in the first place to come in and help them? So if this is the specific goal that we're trying to accomplish, what's the best way to do that? Most people jump right to persuasion. They say, "If only I could something, the client would listen to me." "If only I could present the forecast."
If only I could justify the ROI, something, some mysterious research that probably hasn't been done yet and maybe can't even be done at all. My argument here is that the idea of persuasion is toxic. When you say, "If only I could this," really what you mean is, "If only I had the evidence, the client would have to do as I say." You're trying to get control over the client when you say these things.
It turns out that human beings basically do whatever they want to do, and no matter how well you make your case, if it's made for your reasons and not the client's, they're still not going to want to do the thing that you recommend. So I've introduced a framework at Distilled that helps us get past this, and that's what I'd like to share with you right now.
Approach
The key to this method is that at each step of the process you allow the client to solve the problem for themselves. You give them the opportunity to see the problem from their own perspective and maybe even come up with their own solution. There are three steps to this.
1. Suggest
First, you suggest the problem.
When I say "suggest," I don't mean suggest a solution. I mean you plant the idea in their mind that this is a problem that needs solving. It's almost like inception. So you first say, "Here is what I see." Hold up the mirror to them. Make the observations that they haven't yet made themselves.
2. Demonstrate
Step two, demonstrate, and what demonstrate means is you're allowing them to emulate your behavior.
You're demonstrating what you would do in that situation if you had to deal with the same problem. So you say, "Here's what I would do if I were in your shoes."
3. Elaborate
Finally, you elaborate. You say, "Here's why I think this is a reasonable activity." Now I've got to be honest. Most of the time, in my experience, if you use this framework, you never even make it to elaboration, because the client solves the problem somewhere back here and you can just end the meeting.
The key, again, is to let the client solve the problem for themselves, for their own reason, in the way that they feel most comfortable.
Example
Let's look at an example, because that is, again, kind of abstract. So let's say that you've made an observation in Google Search Console. The client has all these pages that Google has discovered, but they shouldn't really be in the index or indexable or discoverable at all.
Start by suggesting
So you start by suggesting. "I see in Search Console that Google has discovered 18 million pages,"when it should be, let's say, 10,000. "This is from your faceted navigation." Now notice there's no judgment. There's no hint at what should be done about this or even the severity of the problem. You're just presenting the numbers.
Now we're already sort of at a turning point. Maybe the client hears this and they do a sort of a head slap and they say, "Of course. You know, I hadn't seen that problem before. But here's what I think we should do about it." You reach some sort of agreement, and the problem is solved and the meeting is over and you get that hour back in your day. But maybe they sort of have some sort of questions about what this means, what this implies, and they want to hear your solution.
Demonstrate what you would do
Well, now it's time to demonstrate what you would do when presented with that fact. You say, "This would be fixed by adding 'nofollow' to links to that faceted content." Maybe they see how this is an obvious solution to the problem that's completely compatible with their tech stack, and again you get 50 minutes back in your day because the meeting is done.
You've done your job. Or maybe they don't. Maybe they don't understand why that would be a good solution.
Finally, elaborate
So finally, you get to this stage, which is elaboration. "Here's why I think this is a good idea. These pages are important for user experience. You don't want to get rid of the faceted navigation in your e-commerce store, but you do want to not link to those pages for SEO reasons, because maybe there's no search volume for related terms."
So for a particular cost range for an item or something like that, there's just no associated search activity. You need the pages still. So you say, "These pages are important for user experience, but they don't satisfy any search intent." At that point, the client says, "Of course. You've come up with the ideal solution, and I'm going to implement your recommendation exactly as you've given it to me."
Or they don't. If they don't, you're no worse off. You can basically walk out of that meeting saying, "I've done everything possible to get the client on board with my recommendation, but it just didn't work out." That feeling of being able to know that you did the right thing has been a very powerful one, at least in my experience. I've been consulting for about eight years, and just going through this process helps me sleep better at night knowing that I really did my job.
We've also found that this has a really high success rate with clients too. Finally, you'll discover that it's much, much easier to put together presentations if you know that this is the format that you're going to be presenting in. So if you think that your job is to give the evidence to the client to convince them of something, there's really no end to the evidence that you could gather.
You could always gather more evidence, and when you get to that final meeting, you can say, "Oh, it's not because I saw the problem in the wrong way or I communicated it in the wrong way.It's that I didn't justify the ROI enough." There's no leaving that. That rabbit hole just keeps going, just keeps going. So again, this method has been extremely successful for Distilled. If you're interested in engaging with this more, you can read at this URL, dis.tl/present, where I give a more thorough write-up on this.
Of course, I'd love to hear any thoughts or experiences that you have with this method. Thank you very much.
Comments
Please keep your comments TAGFEE by following the community etiquette
Comments are closed. Got a burning question? Head to our Q&A section to start a new conversation.