Skip to main content

The ultimate goal of product ops - making yourself redundant?

 

Product operations, like any role that focused on processes and improving productivity, should dissolve itself when the desired state is reached. Or should it? What's the ultimate goal of the product ops?

My first ever computer-related education was network administration. I went for it because I saw those guys (and at the time it was 99% guys), they were chilled, never in hurry, never stressed, and it looked like they weren't doing much. What I didn't know back then is that they appeared like doing nothing because they did a whole lot before. 

The biggest sign of a successful "ops" function is that gradually they have fewer and fewer things to do. A good system ops team can play games the whole day if their networks are secure, fast and all their gear working flawlessly. A good finance ops team can write their investment books while their colleagues have the right tools, processes and knowledge to do their jobs well. Similar story with the product ops. 

In the beginning, depending on the state of the org they enter, product ops tend to be super busy. There are hundreds of things to do, often similarly important. You have to talk with numerous people, design countless experiments, and dig into piles of data. Then you need to synthesise the knowledge and do it all over again, and again, and again. 

If you do the job well - things will start to improve. You should see it reflected in your core metrics and in the job satisfaction of your colleagues. Your tasks will get more nuanced and peculiar - no groundbreaking changes, rather small tweaks and optimisations. It's still more than enough work - often the margin between good and best teams is in the details.

So does it mean that eventually comes a moment when the product ops team will have nothing to do? And the short answer is no. The process of building products is always evolving, it changes so do your team, your competitors, the technology, and the finances. You could find a perfectly fitting tool, a brilliant process and revealing data but any day something new might appear in the world and you'll need to adapt again.

Moreover, every new employee could and will change your company's culture. In the advanced stage, product ops should be mainly occupied with hiring, onboarding and coaching. There should be a strong bond between product ops and product leadership in order to support the high-performing culture they've jointly created. 

Summarising all of the above, a good product ops team should strive to make themselves redundant, but a forward-thinking organisation should never fully dissolve their product ops team. The environment, personnel, and your product are constantly changing and so your organisation needs to adapt. Having a mature product ops team is like having an adaptive superpower that might appear like not doing much but is actually vital for your company and product success. 

Popular posts from this blog

Product Vision: an elevator pitch for your product

On this blog, I write a lot about making data-driven decisions . But what if you just starting to think about your product? You have a vague idea and nothing more. No point to go for prototyping or even talking to customers as you don't know yet who to talk to and what to talk about. In such situation - start from creating a product vision.

7 steps of Product Discovery

Before building a product - how do you know what product to build? While building a product - how do you know what features are the most valuable? After you've built a product - how do you know if to tune stuff or add a new one?

3 ways to prioritize a Product Discovery backlog

Discovering the right product is a vital part of a product development process. To do that effectively best product teams use a Product Discovery process. This process foresees you having a Discovery Backlog with a list of ideas, concepts, and hypothesis in need of validation. But how to decide what ideas to validate first ?