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.

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.

Goal

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.

Summary

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 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 ?