Skip to main content

Product ops process - optimisation


The product ops process I've described here is an attempt to give folks a high-level framework and a way to look at improving product management at their organisations.

I've covered the first two stages of the product ops process - surveying and experimentation. In this post, I'll talk about the last stage - optimisation.


This is not a distinct stage as such, but rather a general state of mind for a product ops person. Whatever you do - you're always on the lookout for optimisation opportunities.


After conducting an experiment and finding a new approach to work, you now need to make sure it is tailored for your product team and that you're running the best version of it.

What could you do

Further tinker with the process, tool or behaviour you're improving. You need to find a version that is best suited to the people who are meant to do the work. It should be obvious, but you're not creating change for yourself, your customers are your colleagues in a product team and it's their needs you need to prioritise.

It's experimenting all the way 

 If you wonder how exactly you should optimise in product ops, the answer is already known to you. It's experiments, only smaller. During the second stage of the product ops process, you defined an experiment, executed it and analysed the results using the metrics you defined in the beginning. In the optimisation stage, you might use the same metric and keep running smaller experiments to see if you can make this metric move further to the beneficial side. 

Measure all the things

Don't forget to regularly check your main product metrics when optimising your processes. You need to make certain further changes are beneficial and not just tinkering for the sake of tinkering. Your Northstar metric should be at your glance so as particular measurements related to a process, tool or behaviour you're optimising.

Mind the people

Certain changes you'll introduce will work for one group but might not bring similar improved results for another. When this happens you'll need to understand the personal differences and work with the affected individuals to come up with the version best suited to them. It is helpful for product teams to share their experiences with one another. This way you'll find it easier to convince more traditionally minded folks to try a new thing you've been working on.

Encourage continuous feedback

Depending on the size of your organisation, odds are - you'll not be able to attend to every survey, experiment or optimisation effort. You'll need to delegate some of your responsibilities. And the most useful is to create and reinforce the culture of continuous feedback. Chances are high that within your product teams you'll find people who are more interested in product ops. Those are your natural allies, they will help you enormously if you can engage them in the process early on. Having those champions within the product org will also allow you to get feedback from every team, compile it and analyse it. You should keep getting feedback and optimising until you reach the best version of the thing you've been working on.

No end in sight

That ideal state, the best version, it might never realise. And that's fine. You want to keep wondering if there is an even better way, a slightly more clever tool or a novel behaviour you can try. It's this "never quite finished" state that is both scary and exciting that you'll need to adopt and fall in love with. There always will be new things to try, a few additional changes, and some tweaks here and there.


Optimisation is the last stage of the product ops process. However, it's more of a state of mind than a distinct activity. You can always find things to optimise and you already know how to do it - using the previous two steps of the process, surveying and experimentation.

While optimising you need to be mindful of the people you're working with and their personal preferences. You'll also need to appreciate the ever-changing nature of product development and accept that something that worked yesterday might not necessarily work tomorrow.

Lastly, the product ops process I described here is a high-level framework that itself is bound to be changed and adapted. Don't be afraid to tinker with it to find the version that works best for you. And also - share your experiences so we can all learn and get better at creating products our customers love. 

Popular posts from this blog

Product management and operations tools - Jira Product Discovery review

  JPD is a new player in the market of product management software. Jira (and the whole Atlassian suite) has been one of the most popular tool stacks for teams to deliver software products. Now they're adding a missing piece - product discovery.

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.

2 simple but powerful filters for your problem and product ideas

Nowadays lots of people and companies want to innovate. They want to generate new ideas and turn them into profitable products. But how would you separate good ideas from not so good ones? How would you make sure you invest only in good ideas?