I recently took on the role of Product Operations at Tanium. Which has been a wild ride and one of my most exciting things I’ve done in product in a long time. Here are some early notes by way of an experience report for others who might end up walking this path.

Some context; when I started this role, I had been at Tanium for two and a half years which is a good amount of time to learn the ins and the outs of the organization. I had spent a fair amount of time back benching on product practice. I had coached a few of the junior product managers and done some rabble-rousing and process suggesting.

We also did not have an existing product ops function at Tanium. Our new CPO opted to create the role in order to help standardize process and practice across the multiple portfolios at Tanium.

Here are some things I’ve learned and done.

Clarify your mission

One of the things that felt important to me at the beginning was to have a clear succinct explanation of what product ops was and what it was doing at the company. This was particularly important because my boss started throwing me into all sorts of meetings with parts of the organization that I knew existed generally but had never interacted with. To this end I have the handy quip of:

I am a product manager whose product is the product management team. My job is to help the other product managers make better decisions, faster, simpler and more consistently.

I’ve also had to make it clear a few times that I’m not the PMO or project management team. I’m not here to set up your meetings or make sure your project hits its deadlines. My job is working on the systems that help you be successful. As with all product jobs sometimes we have to do some things not in my job description, but I try to clarify it isn’t my primary role.

Work in Progress Limits are important

I’ve found it really important to understand what my personal work in progress limits are. I have a whole list of things that I want to help do for the product org, but I can only really manage about three things at once. For me that has been:

  • Purchase a product management tool and get us out of planning in JIRA
  • Run a quarterly planning process
  • Get the product and engineering org better connected to the product marketing team.

Some of the things that I’ve put off, sometimes to my bosses' frustration:

  • Getting all the analytics for all the things. I love analytics, and we need to get there, but it also really needs time and energy to get into all the details to really make a difference.
  • Working on how people made decisions about what got prioritized my first quarter. We needed to get there but both in the first iteration with me running the process and an org shuffle we needed to just work with existing process for the most part.

Really getting aligned with all the other functions. We are getting there, but in the first ninety days I knew we weren’t getting into deep integration and partnership right away. In a lot of cases I wanted to wait until I had improvements to the Product Tool chain. A lot of the asks from these teams were for better visibility into what Product was planning. That was hard to provide in JIRA because not everyone had JIRA access and JIRA doesn’t have the greatest tools for sharing or presenting information to non-technical audiences.

Finding some tools

One of my CPO’s first asks was to find a piece of product management tooling. The product team was working out of SharePoint, Jira, spreadsheets, PowerPoints, emails. It was working mostly but it was inefficient. Our major criteria were something that allowed us work from ideation to a published roadmap with key integrations in JIRA, Salesforce, and SSO with a roadmap publishing tool. We evaluated four different tools, seriously looked at tool and settled on ProductBoard.

Running Quarterly Planning

Quarterly planning is hard and contentious. Some of the things that I learned most were that we needed to do a better job articulating what was important and why it was important early in the process. We worked to cast a wide net to make sure that everyone in sales and marketing felt like they were heard in the things that were selected. Unfortunately this meant that we had to leave a lot on the cutting room floor, and the cutting itself took a lot of mental and organizational effort.

Lesson learned: Ask leaders to make hard choices sooner in the process, some space for evaluation between choices based on level of effort can help you cover the last bit, but it can’t take you from a big list to a small focused list.

Some advice that I’m not going to take

I’ve seen some advice out in the wild that doesn’t jive with me. I’ve read several articles that talk about product teams handing off the menial and repetitious tasks to Product Ops to handle. Some have even said that Product Ops should be responsible for ensuring that QA is done on new products.

I’m early in this but my perspective is that you add Product Ops to your team when you have a scaled product team and you need to make things efficient and consistent. So I see a major role for Product Ops is to refine out the drudgery, but you can’t get high leverage out of your ops team if you are just asking them to suck up the drudgery.

My thinking here is highly influenced by my two years as a company Executive Officer in the Army while deployed to Iraq. XOs make a company run by making sure that everyone had what they needed to do their job, making sure they got their jobs done, then making sure the next time we did the job we did it better. And I did a fair amount of drudgery while in that job, but I was not there to catch drudgery.

More to come

I’m sure there are more lessons that I should have learned, but I haven’t written down. I’ll try to write some more over time. In the mean time, here are some things that I’ve been reading to try an learn this role. Compared with the information that I had available to read about Product Management, I’m finding far less guidance in the world.

References