It’s more accurately 505,440 minutes as I write this but I’m confident that any developments within the next two weeks will remain in line with the past year.

I spent over a decade in Product Management and moving to the burgeoning discipline of Product Operations has, from a functional perspective, been manageable. With building a role from the ground up, it’s natural to take a moment and reflect on a year of new construction.

Of course it’s obviously a work in progress. But nevertheless, there are some noticeable patterns in the construction.

Behind the scenes

Product Operations for me falls into four categories:

  1. Roadmap planning.
  2. Cross functional orchestration.
  3. Site analytics.
  4. Strategic support.

All these responsibilities have clear outputs but none outwardly reflect the direct contributions made by Product Ops.

Take roadmap planning for example...

The planning process was loosely defined and a single artifact existed. Speaking with stakeholders and researching what was done before; I identified problems, refined the process, established reliable rhythms and comms, centralized information, authored processes, and even designed a visual companion.

Planning sessions are now more efficient and teams are attuned to the same frequency yet the spotlight remains on the actual roadmap. None of the production work in service of the roadmap goes noticed nor should it.

The same unseen activity rings true for my other responsibilities. Recognition is absolutely not required but memorializing my actions into processes creates a repeatable framework that can flex and grow with the role. By doing my job well, the Director of Product Management can remain focused on her teams and lead them to build magical products in a way only she can.

Catch all

There is always an element of the unknown when assuming an entirely new role and this is doubly true when the tech industry as a whole is bearing witness to the emergence of Product Operations. While some still don’t fully understand what a Product Manager is, the discipline at least has definition. Product Operations has a nebulous definition at best and runs the risk of being the catch-all for work that may or may not be tangentially related to Product Management. Frustrating at the outset but much less so with some reframing.

If not for Product Ops, many of the catch all requests would fall to Product Managers. The Product teams are certainly equipped to take on this work but doing so would take them away from their core tenant of solving customer problems.

Another byproduct of serving as a catch-all is that the unexpected is your only constant. Plan for the week ahead but know that it will be thrown askew with random asks. Whereas in prior

Product roles, where my scope of work was mostly contained to consumer web experiences, the past year yielded a menagerie of initiatives. An interesting find is that the rubric used to survive a year in Product Ops is the same as that in Product Management:

- Talk to every stakeholder to gain a firm understanding of the problem.

- Research what has been done before.

- Assess the costs, trade offs, and opportunities.

- Data, data, data.

- Stitch every point together to illuminate the way forward.

Clear the skies

Red plane flying in clear skies

This applies especially to former Product Managers and leaders. While fulfilling my Product Operations duties, I noticed spare cognitive cycles defaulting to A/B tests, designs, and features for our site and started recording ideas to a small but steadily growing list. It’s of paramount importance to respect the shared boundaries between Product Operations and Product Management.

Product Managers openly welcome ideas but prioritization remains exclusively their purview. This is not to say that Product Operations is regulated to just backlog contributors. Affording Product Managers clear skies to fly remains our exclusive purview. Removing cross functional blockers, building repeatable constructs, and maintaining consistent comms ultimately improve velocity.

In all honesty, my motives are not entirely altruistic. By increasing the speed by which Product Managers cycle through their backlog, my selfish hope is that they’ll eventually pick up one of my ideas. One does not simply stop being a Product Manager.

The year ahead

An open road, running past some fields with mountains in the distance

What remains certain is the construct used to measure success as a Product Manager doesn’t yet apply to Product Operations. There is neither a web analytics platform for instantaneous KPI recall nor a user research group where I can harness qualitative feedback.

Measuring work that goes on behind the scenes is the polar opposite of the world I most recently came from but this doesn’t mean a wholesale abandonment of the skills needed to succeed as a Product Manager. The ability to reframe a situation again applies here.

That we are able to identify trends is the first step in measuring success. Playbooks now exist for work that goes on behind the scenes. Rubrics were constructed with the intention of protecting Product from distractions. Processes exist where none were before in service of velocity. When looked at holistically, these parts form a foundation from which I can measure, iterate, and harden in the 525,600 minutes ahead.


After more inspiration and insights on all-things Product Operations? Check out the Prod Ops portal, the go-to place to get your learnings on this emerging function. 🤓