Product manager vs product owner: UK edition
If you take nothing else from this article, take this: your official title does not need to constrain the activities you undertake and the impact you have in your role. What it comes down to is the needs and expectations of your leaders and your team, the skills and ambitions of you and your team, and the context of your product and problem space.
Preamble
There have been many articles that have covered this over the last decade or so.
A few of my favourites:
- Ant Murphy’s The Collision of Product Management and Product Ownership (2019)
- SVPG’s trilogy of Product Manager vs. Product Owner (2011), Product Manager vs. Product Owner Revisited (2016), and Two in a Box PM (2022)
- David Pereira’s Difference Between Product Owner and Product Manager Explained (2020)
- Melissa Perri’s Product Manager vs Product Owner (2017)
- Rich Mironov’s Agile Product Manager/Product Owner Dilemma (2009!)
But I’d never seen a UK take on this. Until I ChatGPTd it (is that a verb nowadays?) and found Roman Pichler’s Product Manager vs Product Owner (2017).
And whilst this take is as solid as any of the above, it still wasn’t quite reflective of my experiences throughout my 20+ years in UK tech.
So to that end, I thought I’d offer another perspective. Product owner vs product manager: UK edition.
A tale of two titles
First, I’ll reluctantly outline the typical shape of each role and, by extension, their differences, based on my experience. Caveats apply, take with a pinch of salt etc.
And as often happens, I’ll kick off with a John Cutler image:
I’ve always liked how John frames the levels at which practitioners and teams operate as 'mandate levels', and I think this is what really matters. It transcends titles. As teams mature, it’s an awesome thing to see how it transcends individuals.
It focuses on the outcomes that the individuals contribute towards, which ultimately shapes the activities they undertake, and therefore the skills that they flex and develop.
See TBM 27/52: Mandate Levels (2021) for further info.
If I had to outline the mandate levels that product owners and product managers have typically operated at, it would be something like this:
Note that I’ve added in a few example activities (in the third column) to help bring this to life a little.
In essence, the product owner role is a subset of the product manager role, leaning more into the sharper end of “product delivery”.
If I were looking for a different way to visualise this, it might be against the seven key areas of strength that Jeff Patton outlined in 2023:
All this said, I come back to the opening statement: Yes, the title hints at the shape of the role, but I’ve never seen two roles the same.
I’ve seen product managers with a mandate limited to the lower mandate levels.
And I’ve been a product owner that's covered the whole lot.
And this is okay.
Context is a huge factor. All organisations are different. Fintech vs SaaS. D2C vs B2B. Startup vs enterprise. And all teams are different, and constantly evolving - adapting to the problem space they find themselves in with each renewal of focus.
Discount legacy at your peril - it’s probably like it is now because that’s the way it was before. And there may be good reason for it.
To lean into the nuances of my personal experiences, I’ve seen a fairly even split between the official titles of product owners and product managers, whereas LinkedIn would have you believe that it’s 2:1 in favour of product manager.
And I’ve never seen a place with both product owners and product managers working in tandem, but I know it does happen - check out Jason Knight’s Back To The Future parody if you need confirmation. In my experience, wherever the PM/PO hasn’t operated at those higher mandate levels, those gaps have been filled in a hatful of different ways e.g. sales directors, account managers, heads of engineering, founders, or customers, with varying degrees of lossiness.
So what do I think of the two titles? Which is the best one? Which is the right one?
Neither. They’re both a bit bobbins.
Product manager means nothing to most, and is probably more befitting of my first job as a 16 year old filling the shelves at my local supermarket. Product owner portrays a false sense of ownership that brings with it at best no authority, and at worst a huge target on your back. Product manager is synonymous with project manager. Product owner was coined by Scrum and then bastardised by SAFe.
At Hyperact, we tend to use “product manager”, purely due to its prevalence, and the general consensus that “product management” is the all encompassing sweetshop of skills that product managers, product owners, and even agile BAs take from. But we’re not precious, and will normally fall in with the terminology of our partners.
As product practitioners embedded in our partner organisations, we do all that we can to foster this mindset.
What matters most from an individual contributor (IC) and team perspective is that the team as a whole understand the mandate levels that they need to operate at, and are capable of collaboratively undertaking the activities required to deliver on them.
The collective capability of the team is key here, with the capabilities and responsibilities of the product person very much secondary.
And surpassing all of this is the organisation’s ability to operate effectively at all mandate levels. So often, the biggest wins lie at those three highest mandate levels, which are often owned by heads of, directors, c-suite, and CEOs/founders, and also often the most difficult area to affect change as individual contributors.
Whilst Hyperact’s bread and butter is embedding individual contributors in cross-functional teams to rapidly deliver on outcomes, we’ve helped many organisations develop their strategic capability and focus. Check out our product strategy service to learn how we can help here, or get started right now with some of our other, more strategic articles:
- How to shape a product function
- Managing 11 common product constraints
- Product metric frameworks: AARRR vs HEART vs North Star
- Diagnose and overcome common barriers to scale
In summary
Those with a title of product owner tend to focus more on the delivery, execution-focused elements of product development, but this is far from a standard definition.
"So what?" you may well ask.
For individual contributors:
When eyeing up a new role, look beyond the title, and consider the mandate levels that you and your team would operate on, the expectations that others would place on you, and how your skills and experience would marry up with those of your team members.
Preconceptions based on titles can affect the hiring process, so be sure to highlight your skills, experience, and the mandate level you operated on in previous roles in your CV and during interviews.
And if you’re frustrated with either your title, or the mandate levels on which you operate, I assure you of two things:
- You are not alone, and dare I say probably in a majority
- The grass is rarely greener elsewhere!
You can try to affect change in your current role in this regard, but firstly ask yourself whether it’s worth the effort. Teresa Torres thinks not in her experiences. I think you can chip away in some areas, and it may help to tell yourself that “this will pass”. Contexts shift. Organisations evolve. Sideways or upwards moves often present themselves.
Take heart that the skills that you hone in the delivery / execution space - especially delivery management - are the cornerstone of being a good product development professional, regardless of role, and will stand you in good stead for your next role, whatever the shape of it may be.
For leaders:
Could you do more to homogenise titles and strip away some of this confusion? Look to be up front with the mandate levels on which we expect product people and their teams to operate.
Ask yourself whether you put too much weight on titles as opposed to experience and skills when assessing potential hires.
And could you do more to support your product people (and non-product, for that matter) by being clearer on mandate levels within your teams? Maybe even using mandate levels and a capabilities model to help you to develop practitioners, assemble teams, and hire for success?
