Product Operations

I 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....

I’ve been working on implementing Product Management tools for the last year in one way or another. Both Productboard and JIRA Product Discovery allow you to rate the level of impact that a piece of customer feedback has. If your ratings are all over the map it can be hard to really understand what signals you are getting in your prioritization process. In the interest of having some consistency I’ve come to like this scale for rating customer interest....

I recently had a conversation with several Product Managers at work who wanted me to step in and set a standard for how and who was responsible for triaging bugs reported to their teams. The question was mostly focused on who inside of the team was responsible. Was that the engineering manager, the PM, the TPM? Between the four folks who came in mass to my office hours, there were five different ways of managing bug triage. This was causing some challenges because there was a RACI being built to set expectations. I had a very firm “No I won’t create this standard for you”. And I’m here to caution other product leaders and product operations teams not to do it either. When you are operating a dynamic adaptive system with multiple independent teams. It is important to be very thoughtful about where and when you set and enforce standards. Some questions you should ask yourself before establishing a standard that everyone must follow. ...

The OODA loop(Observe Orient Decide Act) is a concept originally coming out of the Air Force for pilots conducting air to air combat. It’s now applied to many different systems thinking and design contexts. This week I was preparing to explain Product Operations to my new CEO and it occured to me that the role of Product Ops is to help power and accelerate the OODA loop for product management teams....

I’ve been working with Productboard a lot in the past few months. Purchasing and helping Tanium implement it has been one of my primary tools to help improve our prioritization, process, and transparency with the rest of the organization. One of my favorite things about Productboard is the ability to super easily document what fields are and how they are supposed to be used immediately inside of the product. I use this all the time to both make my life easier as the person building systems, and it lowers the adoption curve quite a bit for my users. It also feels like a good example of your process being open source. Where it is clear it is easy update your process documentation. ...

I’m in the midst of reading Thinking in Systems: A Primer(affiliate link) to my list of recommended reads for Product Managers. It is one of those books like Principals of Product Development Flowthat show you why things work at a deeper systemic level that you’ve just been emersed in. It’s a book that points out the water for the fishes. I had a moment of illumination when reading her description of the reinforcing and balancing feedback loops that drive physical systems....

I think my core challenge with Product Ops, particularly standing it up from scratch, is the tension for modeling systems and processes as they are now vs how I want them to be. Paired with the tension between how much we need to change and how fast the organization is able to absorb change. Especially as the guardian and manager of the product tool stack. I know that if I set up the tools the way we work now, then everyone will continue the way we are now....

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