Product Ops as an enabler

The role of product operations has been receiving growing attention in recent years, but much like many roles working towards reaching maturity, a lot of confusion and uncertainty arise.

One of the biggest doubts is around where product operations sits within the organisation, what they drive/own and where they can bring value. Especially challenging when introducing Product Operations in an organisation that has never worked with Product Operations.

Considering the adaptability of the role and function dependent on the organisation, we could potentially argue that anything and everything is game and potentially within our scope.

It’s my opinion that if we keep the baseline principles straight, the role is easily adaptable to any organisation and the scope easy to define.

But what does that actually mean?

The key word is enabler

Even the experts have varying opinions and points of view on the subject, but one word that keeps coming up is being an enabler or enabling the team.

As Antonia Landi so eloquently put it in a recent Linkedin update:
“I’ve learned something important recently: Not to explain Product Ops as ‘making people’s lives easier’.

As an enabler of work it’s easy to want to be helpful at all costs, and it’s an easy story to ‘sell’ to new peers and stakeholders. After all, I’m here to make your life easier, why wouldn’t you want me around?”

And then summarises her final view nicely with: “My job is to enable the people in our department to do great work.”

I think the important takeaway is that by being clear about our role as enablers, it helps us define a clearer purpose and scope.

As enablers, we will be the Force Multipliers as suggested by Marty Cagan in his article rather than a filler role.

But in practical terms, what does that mean and how do we apply that logic when thinking about the role and scope?

Enabling not owning

As much as we would like to be able to present a standard answer about the scope and responsibility of Product Operations, we can’t because it will need to adapt, depending on various factors:

• The specific needs of the organisation
• Where product operations sits within the organisation
• The maturity of the product organisation

This is where it becomes important to focus on the enabling part of the work.

When we enable, we unlock opportunities. We help connect people to build the right relationships. We create the infrastructures to support the team rather than forcing the team.

Let’s look at the practical example of customer feedback. Whether the company has research, customer success, sales, customer operations or none of the above, we understand that customer feedback is an important part of the product development process.

The challenge is that customer feedback comes from various sources and each wants to be sure that customer feedback is reaching the right people to make the right decisions.

At this point, product operations could easily see it as their responsibility to oil the machine and make sure that’s happening.

The truth is, that there are multiple ways to approach the situation, depending on factors mentioned above.

How do we make it work without stepping on anyone’s toes?

As a rule of thumb, I personally suggest the following incremental approach.

Step 1: Start with connecting the dots

The first step is about identifying the key people, departments and information to connect.

• Who owns what?
• Who will help us drive things forward?
• Who needs to consume the information and how?
• Who can provide the information and how?

At this stage, it’s important to not assume anything about the process or governance process.

Sometimes, we are able to uncover already existing solutions and bring them to light. If those supporting systems and practices are working well enough, we may be able to step back without much intervention.

In other cases we may realise that there are too many missing links between existing solutions and we will need to provide more support in mitigating those shortcomings.

Potentially we may reach the conclusion that there is no real infrastructure and we will need to be even more active than the previous two versions. However, and this is important, this does not mean we need to take on governance. It may be an early indicator, but still not written in stone.

Step 2: Support the infrastructure

In all three instances presented in the previous step, we will need to now provide some support, but will vary greatly for each.

In the first case, it’s about supporting that connectivity until it’s able to support itself. Not as owners, but as facilitators or connectors.

The second case presents a little more complexity, where we need to support the connectivity, but we also need to help in defining the working models of the missing pieces. In this case, whether we own the work or just support will depend on whether we have existing owners that make more sense than us.

In the final case, we need to have a more active part and sometimes need to be the drivers. Here we are the owners at least during the process of ideation, definition and launch. But not necessarily owners in the long run.

Step 3: Owning only what makes sense, when it makes sense

This is where we need to be really strict on whether we take ownership of something or step back and let the teams take ownership themselves.

In the first case, it’s easier, because they already have the existing infrastructure to own everything. We help unlock the efficiency in those relationship and working models. That’s it.

In the second case, we need to be sure who should own the solution. Product Ops could own it temporarily until the needed team or infrastructure exists. In the customer feedback example, if there is a customer success team or customer operations, it makes much more sense for them to own it. Keeping it in Operations wouldn’t make sense in the long run and “fighting” for it, would be a wasted effort.

In the last instance, similar to the previous option, we need to be clear on whether the solution sits within the Product Ops scope in the long run. If it does make sense, than Ops should own it and evolve it.

If however, it’s not in the scope defined for product operations, then we should be prepared to let it go once it is ready.

We should be happy to pass it onto the owners that make the most sense. We should be supporting them in taking ownership. Their success is part of our success and not letting go of our “baby”.

That is an important part of being the enabler. We want to support the teams through the complex challenges and then help them be prepared to own those solutions moving forward.

Final Thoughts

Probably one of the hardest things about taking on a Product Operations role, is knowing that you’ll be working on many things that you potentially won’t own in the future.

It’s about investing our time and efforts into producing our best work and then sometimes handing it over to others.

The reward is in seeing how others benefit from your intervention and how they themselves mature and evolve thanks to your support and coaching.

By having an incremental approach, we are able to better understand our level of intervention and avoid wearing too many hats or taking on more than we can chew.

We ultimately want to unlock the superpowers of the product organisation. By wanting to own everything, we could potentially show great impact initially, but in the long run, would become blockers of innovation and evolution of the organisation.

Don’t be the gatekeeper, be the enabler!

Useful Links and Resources

• Product Ops Overview — Marty Cagan
• Linkedin Status Update — Antonia Landi
• Product Ops is Building your car — Chris Compston
• What is Product Ops? — John Cutler

Originally published at https://hugofroes.substack.com on November 10, 2022.