How product management principles can make you a better SEO
Updated: Aug 20
Image generated by Bing Image Generator using “drafting a feature on a webpage like a sketch” prompt
The infamous “it depends” follows SEOs everywhere. Search engines are secretive about their algorithm, with reason (well, to some extent). When I became an SEO Product Manager at Indeed, I couldn’t say this phrase so much anymore. I learned that if you couldn’t prove the impact, I wouldn’t take much credit for it.
Now, if you’re wondering what an SEO Product Manager does, this is my own definition:
An SEO Product Manager discovers, builds, tests and iterates product features that support your audience, humans and bots, to achieve a given goal. These are usually technical features built together with engineers and other teams.
So for software like Screaming Frog, a hypothetical product feature would be to natively support the new Googlebot-Inspect. They could track the user-agent feature and find out it’s necessary because a lot of people are creating a custom bot rule to use this new bot.
For a website and an SEO Product Manager, anything that’s built for SEO would fall into you. Some examples are:Link modulesCategory pagesAuthor pagesProgrammatic pagesCMS features supporting SEOAPI connections
It’s also part of your job to test the impact of the features above and run SEO A/B tests* such as:Page titlesFeatured snippetsStructured dataCTAs
*SEO A/B tests are different from UX tests – we test different “equivalent” pages instead of presenting two versions of the same page to different users.
These will vary in each company, but you get the gist. There’s a lot of technical SEO involved, but you must know how to deal with content, UX and decision-makers. Also important to know that tech audits and fixing bugs is a small part of the job, but it’s very different from building features. And the most important skill of all – connect your SEO roadmap to business goals.
While websites are made for humans, our audiences include Googlebot and Google’s algorithm as well. We have to prove that our content, structure and user experience are stellar to all of them.
Here are some reasons why I had to adapt my SEO mind to think like a PM and how these things can make you a better SEO:
Initiative vs tasks
It’s great to see your requests being picked up by engineers or devs. However, many SEO tasks are small improvements or bug fixes – Unless they’re part of an initiative. If your “small” requests are not getting completed, perhaps turning them into a wider initiative will give them the visibility you desire, because they become more broad, more important.
ExampleYou made a request to minify CSS and JS to improve your PageSpeed scores. That’s good, but will this alone solve your page speed issues? Probably not. So instead of fixing little things here and there, creating an initiative for this might be a better approach. There are many reasons why:
An initiative or project is more important than a task
The initiative has a name (“Speed Improvements v1”) you can always refer to
Your boss will pay more attention about fixing your “slow loading pages” more than some CSS (who?) thing.
You can circulate the initiative across the company to gather feedback and find allies (in this case, UX is one of them)
Building features and MVPs
Creating new features for humans and bots is one of the most exciting parts of being an SEO PM. You usually start with a Minimum Viable Product (MVP) to prove impact and then expand and tweak it to find your most effective strategy.
Even an MVP tends to take months to get completed, so you should have a few initiatives being built at a time. The bigger the company, the more complex it becomes due to accessibility, security and sometimes just team capacity to focus on so many initiatives.
One way to plan and pitch your MVP is through a product requirements document (PRD). It may contain headers such as:
SummaryAn overview of your initiativeTechnical DebtWhat has to be done (tasks, tickets or steps)ObjectivesWhat do you plan to achieveTraffic and Conversion EstimateYour traffic and conversion expectationsMeasurementHow you’ll measure the impact
Do your research, write a draft and start circulating the document. This last part is also essential for your success because while you might have it very clear why something has to be done, other stakeholders might not. You wouldn’t believe how many silly things get lost here. Takes time to write a crystal clear PRD.
If they’re not on board and don’t why what they’re building, your initiative probably won’t get done as you envisioned.
This is the opportunity to gather feedback, and perhaps make some concessions so include their views and only then your initiative is ready to kick off. While circulating your document, chances are you’ll find out that things aren’t “that simple” or that other teams can also benefit from this new feature.
ExampleCreate author pages to highlight the website’s EEAT. This is a cross-functional collaboration initiative – UX, engineering and editors must be on board to avoid an unused feature. You need design, coding, but most important of all, you need the reassurance of your editors’ availability to collect author details and manage the ongoing work on these pages. Some tasks you might have to answer are:
How do you ensure these pages really show EEAT?
Who gets an author page?
Do author bios load on articles?
Where are they linked from?
Do you need localization for each language?
How long until you can find and optimize all data?
How will you prove traffic and conversions impact?
Cross-functional collaboration
SEO is highly dependable on cross-functional collaboration – Writers, PR teams, and engineers are always top of mind to get things done and achieve results.
It goes beyond them, though. To stick with one example, an often hidden best friend of SEO is UX. If you tend to think of UX as visual design only (like I also did for a long-time), there’s a lot more. UX is a great partner to get page speed fixed, internal linking initiatives and classifying content (per intent, stage, etc). Business acumen is necessary to know who’s the best to own a project.
ExampleYou need to classify content to build an internal link feature that connects different page types at scale. Let’s say you got a large list of gym exercise pages and want to interlink them based on difficulty, body area and calories burned. UX can help you to create a taxonomy (or use an existing one) to tag all your articles before you build an internal link functionality. While SEOs tend to think of links as a way to improve rankings, UX will look at the user already on the website. Maybe some exercises tend to convert better (e.g. more paid users) according to your sales team, so a combination of search traffic * conversion reveals the business priority. It has to work for all.
Ongoing improvements
Let’s say you’ve optimized a group of articles. A new title, refreshed content, internal links at scale and some new fancy structured data. Is your work done? If you think like a PM, it’s not.
While the building has been completed, you yet have to prove the impact. That comes in many ways, depending on your goals. Traffic, rankings, conversions, indexing, bot visits, SERP features, CTR and other ways.
Some goals are early signs (more impressions, bot visits, pages indexed) and then you move to directional signs (SERP features, better rankings, CTR, more traffic).
These improvements are great but limited to the SEO bubble – Ultimately, they all need to connect to business results. When you can translate that into sales, leads or other business goals, then your initiatives will stop being just tasks on a backlog (and you’ll have a higher chance to score that promotion!).
Causal Impact Analysis
To go a step further, I’ve been questioned many times: “How do we know that this particular initiative is responsible for our success?”. As SEOs, we often don’t know for sure. My best way to measure this is by using causal analysis – a model created by, guess who? – Google!
My TL;DR definition of causal impact analysis is:
A comparison between an intervention group (e.g. pages with updated titles) vs a control group (no changes) to find out the incremental impact one initiative had. This way you can say “Our conversions grew X% because of this initiative”.
JC Chouinard also has a good definition:
Causal Impact uses predictive analytics to estimate what would have happened to a variable in the absence of an event (such as an SEO experiment)
I’m lucky to have data scientists to make this type of analysis for me at Indeed. Some important things to keep in mind are:
Results are as good as your data, so you should try to run one test at a time for the pages on the intervention and test groups
Avoid including Google algorithm updates during your test periods
Have months (or years) or historical data to find the ideal control group
These great articles by Wordlift and Seer Interactive will give you some good direction. You can also try this drag-and-drop SEO A/B testing tool made by Koen Leemans – I haven’t had a chance to test myself yet, but should make it easier for you to find the control group for your tests.
Act like you belong
Product Manager is not a title that comes along with SEO quite often (yet). This doesn’t prevent you from thinking like one or trying to answer questions as they do. There are plenty of resources out there just to put you in the right mindset, such as LearningSEO, The SEO Sprint and Search Pilot.
Test, improve and document what you do, even if you think no one is reading it at this stage. This will allow you to back up your current and future ideas – After all, if Google Search is testing things all the time, why shouldn’t you too?