Product Ops: What's all the fuss? - Issue #5
Today’s newsletter was inspired by a status I recently posted on Linkedin, in which I commented on the sudden quantity of Product Ops roles. How often they just weren’t actually looking for a Product Ops professional, but rather trying to fill another role, yet naming it Product Ops.
The status did generate quite some discussion ranging from some agreeing with me, others sharing their opinion on what they think this might be happening, to others asking what would be a valid job spec for a Product Ops role.
Reflecting on that, I realised that a lot of the complexity comes from the varying opinions and mixed messages coming from the industry, so I thought we could dig in a bit more.
Show me the reasons
There was a recent article by Marty Cagan which gave an overview of his opinion of Product Ops. Although I don’t agree with Marty’s general bias towards Product Ops and it’s need/value, there were a few points that Marty made which I think echo a few of the main reasons we're seeing so much confusion around the role.
The biggest one being that much like other trending roles in recent years, recruiters pack roles under the Product Ops title, that in fact are other roles. The question is why? Is it to get more traction and attract more candidates?
If that’s true, they’re actually doing a disservice to both the discipline and to their hiring process. The discipline suffers because it propagates the ambiguity and lack of definition of the role. The hiring company suffers because all the extra traction will in fact bring in the wrong candidates.
Another point brought up by Deborah Causton, is that it is related to the lack of maturity of many product orgs and how most product leaders have never worked in a product setting. Deborah even shared some statistics from the German market.
This brings up another interesting discussion, maybe for a later newsletter on the dangers and challenges of hiring the right people for your product org. But going back to the original topic, this paints an interesting picture, because it means that the product world is being shaped by people who have no idea what being product-led is.
The final point that comes to mind is the lack of a standardised definition of what Product Ops is and does. I would say one can argue much the same about almost any product role and experience has taught me that depending on the country, organisation, leader, context and product type, the definition of most if not all product roles can vary greatly.
I also want to add a counter argument that I brought up in my Ops of Ops article, where I explore that the baseline principles of Ops are already defined and standardised across all Ops roles. The difference then arises on specificity of the related roles and their needs, but not on the baseline principles.
To be honest, I think all of these points contribute in different levels to the confusion and unless we address them we’ll continue seeing the same issues.
How do we get it right?
As a rule of thumb, again related to the status I shared on LinkedIn, I only share open roles for Product Ops when they are in fact looking for Product Ops professionals and not a different role entirely. I would ask others to do the same and if you are unsure, you can reach out to me or another Ops professional, much like João Craveiro did with role specs, asking my opinion.
We as professionals in the area of Product Ops need to do a better job of operationalising the role of product operations (see what I did there?). We need to be stricter when defining our scope. We need to stop doing anything and everything others throw at us, just to try and show our value somehow.
Some companies might not need Product Ops at the moment, while others need it desperately.
Startups with a small product org might not need Product Ops, because they’re scrapier and will be testing and changing their working model a lot. A lot of the operations can be handled by the team rather than a specific person. Usually in these settings, teams work like a community of practice.
Scaling up - When an org is at the phase of scaling up and maybe we start seeing grouping of teams and missions, I would suggest that is probably the best time to introduce Product Ops as a role. Why at this stage? Because there are already some established practises and habits, but there is still space and some structure. These orgs are facing the challenges of scaling without breaking. Basing your growth only on adding headcount reaches a point where it doesn’t work anymore and the value of adding new people brings less and less value.
Again, if at this stage of the org, some baseline principles and guidelines aren’t properly developed, the “practice debt” will only grow until the point where it’s a blocker of agility and innovation.
Large/Enterprise - In large or enterprise level product org, introducing Product Ops is fretted with challenges. In most cases these orgs already have many established practises, both good and bad, as well as potentially negative behaviours or habits that will ultimately affect the org if not handled in time. The mess has grown unmanageable. If Product Ops has been introduced previously and the org has scaled, then scaling Product Ops is another potential challenge.
If, however, you’re looking to introduce Product Ops at this stage, it’s almost like swimming against the current. I would suggest that in most cases the best option would be to bring in an external Ops consultant, because you’re going to need to undo years of habits and ways of working. Someone external can usually affect that change more effectively, because they’re seen as an expert, whereas internal team members may be taken for granted, just because they’re known.
Does that mean you shouldn’t introduce Product Ops at all? Quite the contrary, if you bring on a strong and experienced Product Ops professional who is aware of those challenges and has the right backing from the product leadership, managing the change is still very possible. But I need to highlight that they need the space and autonomy to “break” a few things.
The key in all cases is to be honest with yourself and with the industry. Ask yourself important questions like:
Do we really need this role or am I just trying to show I am connected with what the industry is saying?
What will the impact be if we don’t hire Product Ops?
What value are we needing them to bring / what outcomes do we expect to see?
If I hire the person, can I effectively give them the space to affect the changes needed?
What do we do well that needs to be multiplied or explored more in depth?
How long can we keep going as we are before we lose control completely?
Adding extra layers to the conversation
Myths of Product Operations. Dispelling some of the myths around the… | by Chris Compston | Jan, 2022 | Medium — ndxcc.medium.com This is from my perspective and other Product Operations teams may operate differently. Seeing something different? Comment below or join our Global Product Operations Community and open up the…
The ops of ops. Why the sudden surge in operations… | by Hugo Froes | Medium — hugofroes.medium.com Why the sudden surge in operations related roles across product development disciplines? What is the connective tissue and where do they differ? What can they learn from each other? These are some of…