Keith says: “My insight is that SEO product management is the natural progression from technical SEO.”

Shall we define SEO product management, to begin with? What is that?

“Sure. I think it's a fairly new role, comparatively speaking. We've been doing technical SEO for decades at this point, but SEO product management is a role that is specifically designed to take all of your technical findings from whatever crawl you've done – the analyses of your site – and actually push it through the product process at companies.

Whether you're using an agile methodology, hopefully not Waterfall, or whatever methodology you're using, it is actually taking those insights from your crawls into production at these companies. It is a fairly specific discipline within product management. It's also a fairly specific discipline within SEO as well. So, it's like a marriage of two different types of roles.

Product management is essentially taking whatever insights you have, whatever findings you have, and building stories around those insights. For example, say you want to automate the way that your page titles are constructed across your site. Then you would have to build a story so that your developers know how to actually develop that.

It's really more of a process of understanding what your technical capabilities are, how long it would take to get these things implemented, what the outcome would be, and what the benefit would be – what the ROI is for that. It's a much deeper business-focussed, development-focussed role beyond technical SEO.”

Should every technical SEO be looking to develop these skills? When you said ‘building stories’, it made me think that some technical SEOs are probably a little bit too scientific to be comfortable building stories.

Should some technical SEOs just stay technical?

“Yeah, we should probably get the nomenclature down here real quick. When I mentioned stories, I am truly talking about agile methodology.

Agile methodology is the process for development teams (it started out as a development framework), where they essentially break down your technical asks into what they call ‘MVPs’ or Minimally Viable Products, which means they can develop it, and maybe it comes out as an imperfect product at first, but then they iterate on that.

This is a big difference from what Waterfall was as a development process, earlier in the 2000s, in which you basically have an end goal in mind, and that's what you work towards until you release. The idea in Waterfall is that you release the perfect product (it's never the case, by the way. It's never perfect), and then you move on to the next product.

The problem with that methodology was that you would release a product, something would be broken, and then it would take you another 6 to 12 months to fix it and to get the product that you actually wanted – and even that might be imperfect. It was a very laborious process, and a long process, and it just required so much perfection on the part of the developers that it was a frustrating process.

With agile, it's an iterative process where you start out at a starting point and then you iterate upon it until it becomes the product that you want it to be, and that may just be a perpetual process. A website, I would say, is a perpetual iterative process because it's always going to change. There's always going to be new standards. There's always going to be new technologies. So, you continually iterate on the perfect website. Amazon is a perfect example of that. They have iterated for decades now.

With SEO product management, it is a matter of deepening your knowledge of technologies: the technologies, the frameworks, the databases, the storage, and the bandwidth of your website. It's also a matter of being really good at working with your business stakeholders as well.

Technical SEOs don't necessarily have to progress to this. They can stay technical SEOs. They can be looking for potential problems and then just hand the list off to someone else. But, as you are in larger organisations and much more complex organisations, you do need to develop these skills, so it is a natural progression.

One of the benefits of this is that, as you may or may not be aware, you can be in a job market that’s terrible. Right now, I would say that the SEO job market is not great. I've seen some SEO director roles where the starting pay is 70,000 US dollars, and I'm thinking, ‘A director of SEO? 70,000 US dollars? That's not a lot of money.’ Two or three years ago, that would have been 140,000.

Corporations are getting a lot more comfortable with paying less for these roles, if the roles are even available. We've seen a lot of our colleagues in this industry sit on the sidelines, unable to find a job because of the use of AI in the applicant tracking systems, or the ATSs, out there that are just immediately sending out rejections. No human is looking at these well-qualified resumes, and people are getting thrown to the side.

Another benefit of becoming an SEO product manager is that, if SEO is suddenly being perceived as not valuable to corporations, you can just move straight into product management, because that is a discipline in and of itself. If you're working for an e-commerce site, that might be the payment process. It might be developing a frictionless user experience.

You may have to move away from SEO for a while, for the time being, so it is a great benefit to learn these skills.”

It sounds like one of the key aspects of being an SEO product manager is to determine what to focus on, as well as being able to articulate what to do.

Would you say it's an SEO product manager's role to actually determine the item of SEO that is likely to be of the biggest financial benefit to the business to implement first?

“Absolutely, 100%. It is a discipline in and of itself, to be able to look at something that you're trying to get done – any ask that you might have of the development team – and determine its impact.

I regularly use the LOE-LOI matrix: the Level of Effort-Level Of Impact matrix. In that, I'm plotting out all of the technical findings that I have, in the audits that I've done, and it is my job to take a look and see, ‘What is going to be the impact of this and how much effort is it going to take?’

This is why learning how your developers work really matters because you can say, ‘Oh, that's going to take them four weeks to do, but it's going to have a very small incremental impact on traffic – or revenue for that matter.’

To keep yourself from looking like a fool and bringing up all of these really small, maybe unimportant tasks to the development team, by plotting out your requests into the LOE-LOI matrix, you're able to say, ‘All right, I know this one is going to have a big impact and it’s going to take a very small amount of effort.’ Then, suddenly, you can start reporting back to the development team, to your business stakeholders: ‘Hey, we've driven more traffic because of these five fixes we put in in the last month.’

So, yes, it is a matter of really understanding priority and understanding impact and effort.”

How do you determine the level of impact that an SEO activity is going to have?

“Yeah, that's always the challenge, isn't it? Because SEO, in and of itself, is really an additive type of discipline, right? Everything that we do has an additive effect, and it may not necessarily have a revolutionary effect on the site.

We can say, ‘Alright, if I modify my meta descriptions to include the appropriate keywords…’ or whatever. Maybe 10 years ago, that might have had more of an impact than it does now because we know that, if Google doesn't find what it needs in your meta description, it will build its own meta description right now. It'll do the same thing with your titles as well. 10 years ago, I might have been able to say that would have an impact, or maybe even 15 years ago it might have had an impact. Today, I can't say that.

It is understanding the additive nature of SEO, but it's also understanding where the snags are. Where are the crawlers running into a problem going through your site? Where are users having a usability problem on your site? Then, you can begin to understand what the impact would be.

It's breaking out: is this a benefit to the Googlebot and Bingbot crawlers, or is this a benefit to the users? Is it a benefit in traffic, or is it a benefit in revenue? You really have to understand the business needs that you have and then understand how your efforts are going to fit into that.”

What about determining the amount of effort required by developers to help you out? Is it as simple as having conversations with them?

“You know, it's really interesting. By just talking to someone, you can have a better understanding of what it's going to take to accomplish something. You might say, because you worked for a previous site, ‘We need to do this’, and you might talk to a developer and they go, ‘We're going to have to do a complete refactoring of our code on the site in order to do that.’

At your previous job, that might've been easy. At the current job, that might not be a possibility because of the number of staff you have, the resources that are available, and the amount of budget that you have. Having those conversations is vital. It's getting you out of your own head, out of your own spreadsheets, talking to your developers, and understanding their pain points – and that will also help you build better stories for them.

So, within agile, you build what are known as ‘user stories’, and sometimes you have groups of user stories that lead up to what is known as an ‘epic’. As you're writing up these stories, you know that you've broken it down to the smallest possible piece that you can, but you're also building toward the Minimal Viable Product that will actually be acceptable to your business – and then also understanding what technologies are involved in making this fix.

You can write a story that says, ‘I am looking to implement changes to our sitemaps’, for example. That's not going to involve all of your developers. That's going to involve some people who are working on your database and some of your front-end folks, and that's it.

It is a matter of the conversations. It is a matter of learning the technologies yourself a little bit. I know more now about JavaScript than I've ever known in my entire career because I've had to work with so many websites that use JavaScript frameworks to build out the experience for their users.”

Has being an SEO product manager changed the way that you view SEO, with regard to what you would include in an SEO training session for general marketers?

Would you incorporate different elements in there and articulate the value of SEO differently?

“Yes, mainly because I have had much grander visions of an impact that something would have than what actually happened. This has been a real big challenge in my career because I'll say, ‘If we do this, this is going to really make a big difference.’ and then the change is implemented, and nothing happens. It's a big flash in the pan, if nothing else.

So, yeah, it has changed my perspective on SEO. I have gone from seeing changes as having huge impacts to having additive impacts, understanding how my roadmap should look each year, and breaking down everything that I need to have happen across the site into doable chunks of tasks – but also topically related tasks as well.

If I were to build a new training program for technical SEO folks, there would be a lot more of me urging folks to actually learn more coding, just even getting a basic introduction to things like JavaScript and SQL.

This becomes valuable because you can speak the language that the developers understand. They aren't your business stakeholders. With your business stakeholders, you can use flowery language. You can use language that's exciting, and you can sell them, and that's fine. You can do that all you want. But when you talk to a developer, they're much more pragmatic, they're much more practical, and they speak a different language than your business stakeholders and you need to be able to speak that in order to get your stories pushed through.”

If an SEO is struggling for time, what should they stop doing right now so they can spend more time doing what you suggest in 2025?

“Struggling for time oftentimes has to do with prioritisation of your efforts. SEOs can (and have in the past) basically run an audit and consider everything on that audit important.

I think the most important thing that an SEO can do is understand the additive nature of SEO in general, and then prioritise efforts based not only on what's going to have the most impact, but the kinds of efforts involved.

Within the LOE-LOI matrix, for example, there are the high-effort, high-impact items, and then there are the high-impact, low-effort items that are the ideal portion of the matrix to be in. A lot of SEOs might have a high-impact, high-effort list of items that they really want to get pushed through, without understanding the effort that's involved with that. What they'll do is they'll find themselves being frustrated and having development go, ‘No, we can't do that. No, we can't do that.’

I can't tell you how many quarters I've sat through where I just didn't have the budget and the resources to get things done that I knew needed to happen because I didn't provide them with the low-effort, high-impact items as well.

It really is a matter of understanding the additive nature of SEO. Don't oversell things to people. Another thing that they can do is not sit there and magnify the potential impact of something if that's just not practical or even possible. Then, also, be willing to admit when you're wrong so that you can learn and listen to the folks who actually know how to get things done. Then you can change your approach and get more things done.”

That’s a good life lesson as well as an SEO lesson.

“I think so. I think so.”

Keith Goode is the SEO Product Manager at the Permanente Medical Group, and you can find him over at KeithGoode.com.