Whose job is it anyway? The rise of Product Ops and why it deserves to be an independent function "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs December 12 2022 False Guest Post, product ops, Mind the Product Mind the Product Ltd 1412 Product Management 5.648

Whose job is it anyway? The rise of Product Ops and why it deserves to be an independent function

BY ON

Lately it feels like no matter where you look, there’s always someone talking about Product Ops. What it is, how to hire for it, and how this latest specialist role is definitely the ticket to your company’s success. But few people are asking: Does this role actually need to exist? In this guest post, Antonia Landi, Product Operations Leader provides all the answers.


Despite Product Ops seemingly appearing out of nowhere, the function is far from new. Some companies have been doing it for a decade, and Melissa Perri was already writing about it in her book Escaping The Build Trap back in 2018. Since then, the role gained quite a bit of publicity – and not all of it good. Adversaries are making excellent points: Aren’t our product leaders supposed to do these tasks, and can someone with no prior product experience ever truly succeed at improving the product management experience?

As with many questions the answer is infuriatingly simple: It depends.

What is Product Ops? Nobody Knows

The inherent complexity and breadth of definitions of the role don’t make answering this question any simpler – on the contrary, because Product Ops means so many different things to so many different people, it becomes nearly impossible to answer any question about the discipline with a simple yes or no. From serving product managers exclusively to serving entire R&D departments; from being so-called centralised ‘internal consultants’ to being embedded in specific product teams; from executing tactical product or project tasks to being purely holistic – it seems nobody can agree on one definition of Product Ops. The best we’ve been able to do so far is agree on a broad mission statement: Enable our people to do their best work.

But it’s in this ambiguity exactly where Product Ops’ superpower lies. The reason there are so many different definitions is because at its core, Product Ops aims to remove barriers to great work. What those barriers look like though is different at every company. A Product Ops person at a startup might focus more heavily on process introduction, while someone at a large corporation might need to examine cross-departmental communication. A company with low product-led maturity will need someone with product management expertise that can guide and coach their product managers or offer support with OKR definition, while some companies might never need Product Ops at all.

Role vs Responsibility

“But wait”, I hear you say. “Coaching product managers? OKR definition? Isn’t that something product leadership should do?” Well, yes and no. You see, Product Ops work has always existed. Whether the people doing this work were explicitly aware of it and whether they did it well or badly is besides the point. And this is exactly why Product Ops arose as an independent function. All too often Ops work is invisible, and more often than not it’s done by overly enthusiastic product managers who are frustrated with the way something works (or doesn’t work). So they take it upon themselves to fix their teams’ JIRA workflow, or to set up a monthly newsletter. Sometimes a manager might recognise their good work, and ask them to expand the process or format to other teams, too. Congratulations, you now work in Product Ops.

But no matter how well-intentioned and well thought-out these projects are, they almost always inevitably end up dead in a figurative ditch of ‘oh yeah, we tried that once but then it just sort of fizzled out’. Because guess what: That product manager that just wanted to fix this one small thing? They have a day job (solving customer problems), and that day job will always be of higher priority than ensuring a new process gets adopted, or that it actually fulfils its purpose.

However it is important to make a clear distinction between Product Ops and product work. Product Ops should never call the shots – that’s simply not what we’re there to do. We help facilitate tough discussions and decisions, but their outcomes will always be the responsibility of the people doing the actual work.

Photo by Jackson Simmer on Unsplash

The Danger of not having Product Operations

Marty Cagan wrote about the dangers of Product Ops in what is probably the best known Ops hit-piece to date. He argues that Product Ops is a symptom of poor product leadership that we’re now trying to gloss over by introducing surrogate processes led by people who have never been so-called ‘makers’. But he fails to recognise one very important thing: Product Operations is just as much about enabling product leadership to do their best work as it is about serving individual product managers.

Yes, a lot of Product Operations tasks have historically been led and nurtured by product leadership. But sadly, that also means that the leaders whose job it is to strategise, inspire, and show us the way forward are often more concerned with getting that latest status update from their product managers so that they have something to present at the next board meeting. Without Product Ops you run the risk of having leadership who are so knee-deep in vendor negotiations and tool roll-out that they haven’t had time to think about market dynamics and what this could mean for the product as a whole. You create leaders who are so bogged down with process work that there is simply no room for real product leadership.

Does everyone need Product Ops?

So if a lack of Product Operations means ineffective teams and poor product leadership, does that mean everyone should be thinking about operations? After having spoken to many product leaders and peers this is the conclusion I’ve come to: Eventually, yes.

As companies scale, complexity grows. As complexity grows, cognitive load increases. Eventually, this cognitive load (in the shape of increased interdependencies, poor communication, and unclear ownership) becomes too high to manage ad-hoc. Long, manual processes need to become simple, repeatable, and purpose-driven. And this is exactly what Product Operations aims to do. Our aim is to equip the people we serve – be that product managers exclusively, or everyone in R&D – with all the required tools, frameworks, knowledge, and processes they need to do great work. And yes – good processes are a prerequisite for great work.

Broadly speaking, all these things can be done by existing product managers and product leadership. But you’ll inevitably reach a tipping point where this work becomes too much for any other role or function to do ‘on the side’ and you need clear ownership. That’s when you need to start thinking about Product Ops.

Photo by Dan Cristian Pădureț on Unsplash

Table Stakes

So back to our original question: Does this role actually need to exist? Well, ‘need’ is relative. Do you need to run like a well-oiled machine to make money? Not necessarily. Do you need to be product-led in order to find product/market fit? No. Does Product Ops need to exist as an independent function in your company? It depends.

It depends on what you as an organisation want to focus on. It depends on whether there is enough Ops work to justify a full-time person. It depends on whether you want to invest in operations early so that you don’t need to retroactively fix your ways of working, or whether you’re happy taking your chances. To put it succinctly: It depends on how much pain you’re willing to tolerate.

All I can say for sure is that I wish I had had Product Ops when I was a Product Manager.

I would’ve been able to focus solely on the problem at hand instead of having to run around to fetch things (like product data, research information, experimentation results) that I believed to be table stakes for me to do my job well. The departments around me wouldn’t have felt like Product was a black box they had no insight into. And most of all: I could’ve seen my leaders focus on the things that mattered the most: A coherent product strategy that allowed us all to work on the right things, at the right time.

There’s more where that came from! Access more insights below

 

Lately it feels like no matter where you look, there’s always someone talking about Product Ops. What it is, how to hire for it, and how this latest specialist role is definitely the ticket to your company’s success. But few people are asking: Does this role actually need to exist? In this guest post, Antonia Landi, Product Operations Leader provides all the answers.
Despite Product Ops seemingly appearing out of nowhere, the function is far from new. Some companies have been doing it for a decade, and Melissa Perri was already writing about it in her book Escaping The Build Trap back in 2018. Since then, the role gained quite a bit of publicity - and not all of it good. Adversaries are making excellent points: Aren’t our product leaders supposed to do these tasks, and can someone with no prior product experience ever truly succeed at improving the product management experience? As with many questions the answer is infuriatingly simple: It depends.

What is Product Ops? Nobody Knows

The inherent complexity and breadth of definitions of the role don’t make answering this question any simpler - on the contrary, because Product Ops means so many different things to so many different people, it becomes nearly impossible to answer any question about the discipline with a simple yes or no. From serving product managers exclusively to serving entire R&D departments; from being so-called centralised ‘internal consultants’ to being embedded in specific product teams; from executing tactical product or project tasks to being purely holistic - it seems nobody can agree on one definition of Product Ops. The best we’ve been able to do so far is agree on a broad mission statement: Enable our people to do their best work. But it’s in this ambiguity exactly where Product Ops’ superpower lies. The reason there are so many different definitions is because at its core, Product Ops aims to remove barriers to great work. What those barriers look like though is different at every company. A Product Ops person at a startup might focus more heavily on process introduction, while someone at a large corporation might need to examine cross-departmental communication. A company with low product-led maturity will need someone with product management expertise that can guide and coach their product managers or offer support with OKR definition, while some companies might never need Product Ops at all.

Role vs Responsibility

“But wait”, I hear you say. “Coaching product managers? OKR definition? Isn’t that something product leadership should do?” Well, yes and no. You see, Product Ops work has always existed. Whether the people doing this work were explicitly aware of it and whether they did it well or badly is besides the point. And this is exactly why Product Ops arose as an independent function. All too often Ops work is invisible, and more often than not it’s done by overly enthusiastic product managers who are frustrated with the way something works (or doesn’t work). So they take it upon themselves to fix their teams’ JIRA workflow, or to set up a monthly newsletter. Sometimes a manager might recognise their good work, and ask them to expand the process or format to other teams, too. Congratulations, you now work in Product Ops. But no matter how well-intentioned and well thought-out these projects are, they almost always inevitably end up dead in a figurative ditch of ‘oh yeah, we tried that once but then it just sort of fizzled out’. Because guess what: That product manager that just wanted to fix this one small thing? They have a day job (solving customer problems), and that day job will always be of higher priority than ensuring a new process gets adopted, or that it actually fulfils its purpose. However it is important to make a clear distinction between Product Ops and product work. Product Ops should never call the shots - that’s simply not what we’re there to do. We help facilitate tough discussions and decisions, but their outcomes will always be the responsibility of the people doing the actual work. Photo by Jackson Simmer on Unsplash

The Danger of not having Product Operations

Marty Cagan wrote about the dangers of Product Ops in what is probably the best known Ops hit-piece to date. He argues that Product Ops is a symptom of poor product leadership that we’re now trying to gloss over by introducing surrogate processes led by people who have never been so-called ‘makers’. But he fails to recognise one very important thing: Product Operations is just as much about enabling product leadership to do their best work as it is about serving individual product managers. Yes, a lot of Product Operations tasks have historically been led and nurtured by product leadership. But sadly, that also means that the leaders whose job it is to strategise, inspire, and show us the way forward are often more concerned with getting that latest status update from their product managers so that they have something to present at the next board meeting. Without Product Ops you run the risk of having leadership who are so knee-deep in vendor negotiations and tool roll-out that they haven’t had time to think about market dynamics and what this could mean for the product as a whole. You create leaders who are so bogged down with process work that there is simply no room for real product leadership.

Does everyone need Product Ops?

So if a lack of Product Operations means ineffective teams and poor product leadership, does that mean everyone should be thinking about operations? After having spoken to many product leaders and peers this is the conclusion I’ve come to: Eventually, yes. As companies scale, complexity grows. As complexity grows, cognitive load increases. Eventually, this cognitive load (in the shape of increased interdependencies, poor communication, and unclear ownership) becomes too high to manage ad-hoc. Long, manual processes need to become simple, repeatable, and purpose-driven. And this is exactly what Product Operations aims to do. Our aim is to equip the people we serve - be that product managers exclusively, or everyone in R&D - with all the required tools, frameworks, knowledge, and processes they need to do great work. And yes - good processes are a prerequisite for great work. Broadly speaking, all these things can be done by existing product managers and product leadership. But you’ll inevitably reach a tipping point where this work becomes too much for any other role or function to do ‘on the side’ and you need clear ownership. That’s when you need to start thinking about Product Ops. Photo by Dan Cristian Pădureț on Unsplash

Table Stakes

So back to our original question: Does this role actually need to exist? Well, ‘need’ is relative. Do you need to run like a well-oiled machine to make money? Not necessarily. Do you need to be product-led in order to find product/market fit? No. Does Product Ops need to exist as an independent function in your company? It depends. It depends on what you as an organisation want to focus on. It depends on whether there is enough Ops work to justify a full-time person. It depends on whether you want to invest in operations early so that you don’t need to retroactively fix your ways of working, or whether you’re happy taking your chances. To put it succinctly: It depends on how much pain you’re willing to tolerate. All I can say for sure is that I wish I had had Product Ops when I was a Product Manager. I would’ve been able to focus solely on the problem at hand instead of having to run around to fetch things (like product data, research information, experimentation results) that I believed to be table stakes for me to do my job well. The departments around me wouldn’t have felt like Product was a black box they had no insight into. And most of all: I could’ve seen my leaders focus on the things that mattered the most: A coherent product strategy that allowed us all to work on the right things, at the right time.

There's more where that came from! Access more insights below

 

Leave a Reply

Your email address will not be published.