Product Manager vs Product Owner, Ruthless Prioritization, Engineering Archetypes
3-2-1 Mondays - Edition #8
Hello 👋,
Welcome to the 3-2-1 Monday newsletter.
Every Monday morning, start your week with the following:
💡 3 short ideas about working with devs and product teams.
📰 Two articles to explore to help be more effective with product and dev teams.
❓ One question for you to think about this week while working.
To receive articles like this, please subscribe to The SEO Sprint 👇.
💡 3 Short Ideas
Short ideas on how to improve working with devs and product teams.
1) Product Manager vs Product Owner
You might see the title of a product manager or product owner when seeing jobs being advertised in product teams.
What is the difference between these two titles or roles?
Let's define these two titles:
🚀 Product Manager: This is the job.
🎫 Product Owner: This is the role within a Scrum team.
Let me explain my own experience with these two roles. At DeepCrawl, I was a product manager (job) and was also a product owner (role) in the product squad.
Product Manager
As a PM, the job I was responsible for was:
Creating a product strategy for the SEO insights squad that solved impactful customer problems.
Creating a prioritised product roadmap that outlines key customer problems (and why it matters).
Creating a brief or product requirement document that outlines the specifications.
Creating clear OKRs with the team to outline success.
Product Owner
As well as those responsibilities, I was also a product owner within the product squad responsible for:
Being the voice of the customer within the Scrum team
Creating a web development strategy to help create release slices
Creating user stories or bug tickets in the product backlog
Working with developers to break down and estimate user story tickets in refactoring meetings
Agreeing with developers on what work will be completed in sprint planning.
Accepting or rejecting work done at the end of a sprint.
In the product industry, there is a lot of contention between making the product manager and product owner roles separate. The two roles should be separate, to streamline the work. However, others argue against this. For two reasons:
💔 Customer empathy - You can’t empathise with customers if you don’t speak to them.
🚀 Build great products - You can’t build great products if you don’t deeply understand the product.
In fact, I’ve had this argument with my old boss at DeepCrawl. I asked (stupidly) the product team needed to get a product owner to manage the product backlog(s) and tickets. He pushed back and said no. For the reasons, I’ve given above.
Since working in product and development teams for many years, I now understand why it is important for product managers to work as the product owner.
As a product manager, you can speak with customers or internal stakeholders and use these feedback loops to help set the team's direction. As a product owner breaking down your initiatives into tickets allows you to gain a deeper understanding of how the developers build the product.
The two titles are closely linked and are often, in many organisations, two sides of the same coin.
2) Ruthless Prioritization in SEO
In many organisations, prioritization of SEO recommendations usually happens once every 3 - 6 months. When a monthly health check or quarterly large audit is completed.
The reality is that in a product and development team, an SEO needs to be prioritising continuously and ruthlessly to help get things done.
In product teams, the craft of prioritizing initiatives or recommendations is not a one-off exercise but a continuous, never-ending process that happens daily, weekly and monthly.
They continuously ask questions throughout the life-cycle of any product:
🔨 What should we be working on?
📅 In what order should we build our initiatives?
🚗 When can initiatives be executed?
Working at DeepCrawl and now with client teams have taught me that ruthless prioritization is really about applying three principles of prioritization in an SEO Strategy.
If we visualise any strategy, then it would be made up of these building blocks:
📁 Initiatives: The key themes of your strategy; when these are successfully completed, your team can overcome the business challenge and drive results.
📃 Opportunities: These make up your initiatives; when these are completed, your initiative can be marked as done.
✔️ Tasks: These make up your opportunities; they are the details needed to complete each opportunity and initiative.
The three principles of prioritization are used to ruthlessly prioritise work between and within initiatives.
The three principles of prioritization are as follows:
🗼 Principle 1: Prioritize initiatives - Ensuring you sequence your SEO initiatives correctly and maximise the team’s resources to drive results for the business.
🏠 Principle 2: Prioritize opportunities - Ensuring the opportunities within an initiative are always being prioritised, which makes sure the initiatives are executed.
📋 Principle 3: Prioritize tasks - Ensuring tasks are prioritised to get opportunities executed, which in turn allows initiatives to get implemented.
I’ve written in more detail about ruthless prioritization in SEO in a previous newsletter 👇.
3) Engineering Archetypes
At DeepCrawl, I first noticed the unspoken culture of engineering teams.
Each team member had a specific role in helping get things done. A responsibility which helped get initiatives and tasks implemented.
For example:
🕵️ Developers: They were deeply knowledgeable about the tech stack and worked with PMs to discover and implement tickets from Jira.
🚀 Product Managers: They understood the product squads' direction, scheduled and created tickets in the backlog, and updated the roadmap.
✅ CTO/CEO/VPs These team members signed off on projects and gave the whole company a direction or set of goals to hit.
Nobody really mentioned it, but I noticed that the product and engineering team was an engine of delivery that required the right parts to do their job.
How can SEO professionals navigate this unspoken culture of tech teams to ensure their tasks and initiatives get implemented?
The answer is simple. We must learn to identify three engineering archetypes:
💼 Managers - Senior team members signed off on strategies, roadmaps and initiatives for the team to work on.
📅 Schedulers - These team members own a roadmap, manage the backlog and prioritise the week-to-week workflow of the dev team.
👩💻 Owners - These team members can provide deep technical knowledge of the system, execute the work and provide feedback on feasibility.
By understanding these three archetypes, you can understand how each plays a key role in the delivery engine.
This might seem obvious to many who have worked in development or product teams. However, I’ve noticed that many SEO professionals mistakenly think that developers are responsible for the whole delivery process.
They are not.
This is what the three engineering archetypes are all about. Helping SEO professionals identify who they need to approach to get projects implemented.
For example, here are a few scenarios I have seen when SEOs mistakenly bother developers:
❌ Sign-off on strategy - If we try to get the developers (owners) to sign off on an SEO strategy, we will be wasting our time. The developer can’t sign off on a large SEO strategy project, but they can provide feedback on its feasibility.
❌ SEO tickets deprioritised - If there is a problem with SEO tickets being deprioritised in the Jira backlog, then again, we shouldn’t be bothering the developers doing the work. Instead, we should be approaching the product manager or project manager (schedulers) to understand the blockage and how we can get tickets prioritised.
❌ Design missing SEO recommendations - If there are missing SEO elements in the design for a page template, we shouldn’t bother the developers (owners) who are simply implementing the design. Instead, we must approach the designer or UX lead (owners) to implement the changes.
I’ve written in more detail about these engineering archetypes in a newsletter 👇.
📰 2 Articles to Explore
Articles to explore to help be more effective with product and dev teams.
Product Manager vs Product Owner
by Melissa Perri
“Product Owner is a role you play on a Scrum team. Product Manager is the job.”
How to Work Effectively With Engineers
by Cliff Gilley
“The first thing to remember is that the key to building good relationships with any group in your company is to engage directly with that group’s members and to build empathy with them; engineering teams are no different in this way. We need to talk with the teams and team members, on both a group and individual basis, and to work with them to understand what it is that keeps them going and makes them engage.”
❓ 1 Question For You
A question for you to think about this week while working.
Do you ruthlessly prioritise your SEO roadmap, tickets or recommendations when working with developers or a product team?
If you enjoyed reading this article, then consider the following:
📰 Share — Please share the newsletter with your network or colleagues if you think they might find it helpful!
✉️ Subscribe to The SEO Sprint newsletter — if you haven’t already, please consider subscribing.