The Product Manager <> Product Ops Relationship

The flexibility afforded to the product operations role is beneficial in so long as the overlapping responsibilities with other roles, primarily the product manager, are kept to a minimum. This article is focused on disambiguating the relationship between product operations and product managers.

1. Product Manager, meet Product Ops
2. What is Product Ops?
3. The Cost Paid for Flexibility: Overlapping Responsibilities
4. Divide and Conquer: Proposed Division of Responsibility
5. Disambiguating Shared Areas of Responsibility
6. Final thoughts

Product Manager, meet Product Ops

The product manager will typically be the owner of the product and all its deliverables. Anyone who has ever worked as, worked with, or read about a product manager can tell you that they typically are responsible for all aspects of the product development — from roadmapping to the roll-out. And that’s true. Especially in small and mid-size companies, product managers can and should own all aspects of their product development, or partner with analysts/operations where appropriate.

Increasingly, however, many large company product organizations are finding that pairing their product managers with product operations can drastically improve the outcomes of the product team. Product managers are reporting that stakeholder communication, bugs, user feedback, and product audits are consuming so much of their time that they hardly have the necessary time to spend on strategy — enter product ops. As I like to say, as a general rule of thumb, product ops prioritizes the urgent so that product managers can prioritize the important. Put another way, the purpose of product ops is to enable product teams to achieve better outcomes

What is Product Ops?

Product operations is still a relatively new role, but one that many expect to grow in popularity and relevance in the near future. Although product ops roles may manifest themselves differently on different teams within the same company or across companies, the purpose of the role is typically to enable product teams to achieve better outcomes. This article by Blake Bassett does a great job at laying out what the role is and the key tasks and competencies associated — but this isn’t the topic I’ll dive deeply into in this article. I would summarize to say that product operations typically focuses on …

1. Ensuring the highest product quality, through bug triaging, dogfooding, product audits, and data analysis.
2. Acting as the driver of change management, by ensuring ops strategy is informed of and aligned to product strategy, by driving and leading roll-outs including developing strike-teams where appropriate, and by regularly communicating updates and feature expectations.
3. Informing product roadmapping/strategy, by accumulating user pain points, generating hypothesis across product teams and features, and by facilitating feedback amongst core stakeholders within and across product teams

The Cost Paid for Flexibility: Overlapping Responsibilities

Anyone who has worked in a product operations role, however, will tell you that the role is more ambiguous than most. Ambiguity is priceless for product ops in that it gives us the ability to flex as needed, ensuring the highest team quality and velocity at all times. This flexibility enables us to not only fill in for the roles on our immediate product teams as necessary (e.g. data analyst, product manager), but also to take on roles/responsibilities that may not have been foreseen (e.g. strike-team leader). I for one, wouldn’t trade the ambiguity for the world.

But the ambiguity does come at a cost: overlapping responsibilities with others. There is the occasional overlap with data analyst, program manager, and ops manager — but the undisputed source of the most frequent overlap of responsibilities involves the product manager herself.

The overlap can happen for a few reasons: priorities or team structures may change, responsibilities may be implied rather than defined from the start, or swim lanes may degrade over time as the team gets comfortable. Maybe certain individuals have more expertise and then narrow in on a specific set of responsibilities without much thought. Regardless of how it may happen, it typically leads to redundancy, a lack of velocity, and uncertainty over who the decision maker is….what to do?

Divide and Conquer: Proposed Division of Responsibility

As a rule of thumb, product ops prioritizes the urgent so that product managers can prioritize the important. Of course, no one should be prioritizing the less important and, as the Eisenhower Matrix taught us, urgent and important tasks should still be done first while less urgent, less important tasks should not be done at all.

More important but less urgent tasks are typically ones that are difficult to prioritize if your day is taken up by fire drills and meetings. When product managers, who are typically hired for their strategy and vision amongst other qualities, can spend more time on these tasks, the team as a whole benefits. These tasks include roadmapping, story creation, backlog prioritization done in conjunction with the development team, identification of where the team needs more analysis/deeper research, leading discovery alongside designers, and competitive analysis.

Less important (but still important), more urgent tasks are prime for product operations, with their skilled execution and stakeholder manager skills, to take on. This includes outages and/or bug triaging (working closely with engineering), feature audits to ensure quality of new or existent features, roll-out plans and facilitation, regular gathering of user feedback, and regular communication to stakeholders alongside feature expectations.

You’ll notice that high urgency, high importance tasks are typically shared evenly by product ops and product managers, but that product managers take those tasks that are relatively more important and less urgent. I also think that tasks across these spectrums can be equally impactful contributions to product outcomes; paradoxically, just because something is less important, doesn’t mean it’s less impactful — at least according to this framework!

Disambiguating Shared Areas of Responsibility

Of course, product managers and product operations will still have shared responsibilities when it comes to many of these activities. Here again, we benefit from defining what each responsibility looks like to a product manager vs to product operations.

Generally speaking, the product manager will be the one responsible for more strategy focused work within certain tasks, while product ops will be responsible for execution and communication focused work. For more strategic tasks, this manifests itself in the product manager doing most of the work while product ops supports and ensures stakeholders are informed and aligned. For example, while developing product roadmaps, the product manager will be responsible for the hypotheses, the alignment across product teams, and identifying where additional research is needed, while product ops will share user problems/feedback to inform the approach of the product manager while facilitating conversation between stakeholders. For more execution oriented tasks, this manifests itself in product ops doing most of the work with the product manager being accountable to the metrics that must be met and the prioritization of tasks to meet those metrics. For example, during roll-outs (especially longer, months long roll-outs) product ops typically owns timelines, expectations, training, and gathering feedback, while the product manager is accountable to the KPI set.

This division generally aligns with the skill set that product ops vs product managers are hired for: product managers tend to have more vision and technical depth, while product ops is relatively better at stakeholder management and execution — see the visual on the right.

Final Thoughts

As the product ops <> product manager relationship continues to evolve, so should the division of responsibility. The flexibility afforded to the product operations role is a benefit in so long as the associated cost (the overlapping responsibilities) is kept to a minimum. Is there anything you would add or disagree with in the above framework? For smaller companies that have embraced the product operations role, does this still apply? If not, how would it differ? Product ops is often a gateway to a product manager role — how have you seen product ops responsibilities evolve as they grow towards a product manager?

I created the visuals and frameworks in this article — if you’d like to use them for yourself, please do!