Product Ops as the engine not the fuel
#Product Operations | #Product Management | #Systems Thinking
1 Jan 2024I had intended to write a big long post on all the things I learned as a Product Ops leader as Tanium for a year, but it got long and rambly, so I’m going to attempt a series of shorter posts that will hopefully get written.
Lesson one, when you are working on process of the product team, you are building engines not fuel. This is a metaphor from my good friend Jack Coates (Part 1 Part 2) that he usually applies to building end user products that need content, and that no one wants to build content and teams want to build engines because they are fun and sexy. Similarly when you are building process for your product management team you should resist the urge to try and do the work of the process yourself.
It will be tempting as you are standing up a product ops function to want to provide value by being the connective tissue. When I first started doing Product Ops I got engaged with our go to market process and helping to make sure that our quarterly launches went well. We had a cross functional team of marketing, technical and sales enablement that ensured that everyone was prepared to speak about new features and products.
At first I was acting as a go between to the PMs doing the work. I was constantly chasing multiple teams for dates and deliverables, just to pass them off to another team. It was slow and not very helpful, I was always behind. What we really needed was to connect the teams doing the work to the GTM team in an effective way. (protip, they just needed a Slack channel).
When we are working on process we always need to apply systems thinking and find ways to shorten and strengthen feedback loops. By putting myself between the PMs and go to market I was lengthening the feeback loop by adding an extra hop in the process. I also started a game of telephone where questions and responses had to be passed and parsed; this weakend the feedback loop.
Lesson: Don’t put yourself in the loop. Build shorter faster loops.
Some context for this advice:
- I was working in an environment where I was the only Product Ops Manager for a team of 30 product managers. If we had a product ops manager in each product portfolio team I might have approached this differently. But we still want product ops teams to be focused on building better systems not being individual processes executors.
- I think if you are working as a product operations analyst, the role is much more of a direct service role to the product team, your role is to help process data into knowledge. Product Ops analysts bring an essential skill set that other team members may not have.