Clare Hawthorne

Given that it’s such a nascent function, I think there’s a lot of flexibility – I see that as a good thing! But I know the flexibility can also be daunting, so here’s how I talk about it with my team. Once you’ve been a Product Operations Manager, I think there are four primary paths: 1) Stay in Product Operations – “level up” within Product Operations and find a way to increase the scope or complexity of what you’re working on. At Oscar we have 6 levels for Product Ops, from Associate to Director and we promoted someone this past performance cycle! If your company has only one Product Ops role or title, make the business case for expanding your scope and a title change. Or look externally – many companies are building Product Ops and prior experience can be a huge asset. 2) Transition into Product Management – a benefit of working closely with Product Managers is that you get exposure to what they work on day-to-day. There are overlapping skill sets between Product Ops and Product Management, including translating needs into actionable requirements, strong prioritization skills and a deep understanding of the product you work with. I’ve had folks on my team successfully transition from Associate Product Operations Manager to Associate Product Manager – they enjoy that they’re working earlier in the Product Development Lifecycle. Note: I would be cautious if you are planning to use Product Operations as a stepping stone into Product Management. It can be a very different role from being a Product Manager and you may not get an opportunity to demonstrate Product Management skills in your day-to-day. For most folks on my team, they’ve had to take on side projects or volunteer for work outside of their swimlane to build those PM skills. 3) Transition into another Operations role – if the thing that gets you out of bed in the morning is improving processes or how things function, you may want to consider another Operations role after Product Ops. This could be within Product and Engineering – large Product Design teams are starting to build out Design Ops and/or User Research Ops. Engineering teams can have Engineering or Tech Ops (distinct from DevOps), to focus on optimizing the Software Development Lifecycle, improving Engineering onboarding and/or evaluating tools to increase developer productivity. You may want to get more creative and look beyond the Product and Engineering – the skill sets of organizing chaos, making playbooks, putting structure around things that are ad hoc, etc. are invaluable and very transferable. 4) Transition into Program/Project Management – I believe there is a big distinction between Product Ops and Program Management (I answered another question about the differences!), but there are overlapping skill sets as well. In both roles, you need to make sure people are delivering on their commitments. If your company does not have a specific Program or Project Management function, it’s likely that these responsibilities are bundled with another role – maybe even Product Ops! If your favorite parts of Product Ops are when you are coordinating across teams, tracking dependencies or chasing follow-ups, you might want to consider transitioning into a Program Management role. This can take the flavor of Technical Program Management (which may require specific technical skills) working with engineering teams or more general Program Management, which can span across all lines of business. If this career path is exciting to you and Program Management doesn’t exist at your company, define the opportunity and make a business case for these new responsibilities. There may be an opportunity to incubate the role within Product Ops, maybe as a component of your day-to-day. In talking to other Product Operations leaders, some have had Program Management teams organically form within Product Ops and before spinning them out into their own team.

My “north star” vision for the Product Operations team is to “unlock Oscar’s ability to ship more product, better and faster.” While this is a pretty broad statement, I want to highlight a few elements. 1. Product Operations is not a function to make the life of a Product Manager better or easier. We do not “support” Product Managers. Our focus is unlocking Oscar’s capacity to ship software. In our context, this means that Product Ops focuses on the goals and delivery of our engineering pods. If there are opportunities to increase efficiency of engineering or design, those are on the table. 2. Product Operations adds value in a few different ways. Here are a few examples: * Ship more product - We can maximize the time each member of the pod is spending at their “highest and best use.” This may mean that Product Ops takes on execution oriented work while we advocate for automation or create an operational process. * Ship product better - We can improve product quality by ensuring that we follow necessary testing protocols, or ensure downstream teams are fully enabled before product releases. * Ship product faster - We can create efficiencies by building repeatable processes and playbooks, both for ourselves and for other stakeholders. In real life, this might manifest as a Product Ops Manager taking on the product launch process for a particular pod, which frees up capacity from the Product Manager and the Tech Lead (ship more product). Product Ops can ensure that their operational counterparts have visibility into the feature work and are communicated about launches in a timely manner (ship products better). Product Ops then codifies this improvement by creating a product launch checklist for themselves and other feature teams, thus avoiding “recreating the wheel” for each team (ship products faster).

Unfortunately there’s no perfect ratio – each Product Ops team I’ve run or learned about has a very different structure and mandate! I’ve heard of successful models with Product Ops to PM ratios of 50:1 and of 1:1, so it’s less about the number and more about working with what you have. If you understand the pain points of product leadership and front line PMs, you’ll be able to develop a strategy that delivers value to the Product team regardless of the number of resources you have. That being said, I do have two rules of thumb I’ll share about resourcing: * If you are embedding Product Ops within pods, target 2-3 pods per Product Ops resource. While it’s not a perfect science, I’ve noticed other embedded functions (like Program Managers, QA Analysts, Scrum Masters) try not to go beyond 3 pods. It makes sense – more than 3 pods and sprint ceremonies alone would take up most of the calendar! If your pods are especially big or complex, you may need to stick with a 1:1 ratio, but this can be a very tough resourcing ask if you don’t have a track record for results. * If you are a Product Ops team of 1-2 and have a PM team of ~7+, you should be looking for work that can impact the whole Product organization – you do not have enough resources to embed with specific pods! These may include things like optimizing the Product Development Lifecycle or creating a standard Go-To-Market checklist. Remember to engage stakeholders early and often and I highly recommend piloting your recommendations with a subset of the department!

Great question! As I’ve spoken to other Product Operations leaders, I’ve found that the team structure and role varies widely from company to company. Coming into Oscar Health, I initially assumed I would organize my team around different skills sets – data & analytics, product enablement, etc. – but ultimately, that structure didn’t address the business need for having deep domain expertise within Product Ops. After a few different experiments, we decided that most of the Product Ops team would be embedded within 2-3 engineering pods. (Overall we have roughly 40 engineering pods and generally each has 1 Product Manager.) By embedding within the pods, Product Ops feels invested in the goals and success of their pod-mates. This focus also allows Product Ops to learn their domain area deeply, rather than working with more pods at a surface level. About 85% of our roles are of this type and it’s a mix of Associate Product Ops Managers and Product Ops Managers. However, this structure doesn’t address activities that impact all pods – such as our roadmapping process or our monthly product release communication. For our first year (2021), we federated these activities across several different people. In 2022 we’re hiring for a dedicated Product Ops Process Improvement Manager to take on these activities and implement process improvements. Over time, I see these roles working in a very complementary way – the embedded Product Ops Managers can surface things that are working well (or things that are broken) to the Process Improvement Manager. And when the Process Improvement Manager wants to test a new process they can work with an embedded Product Ops Manager to pilot their ideas before ultimately leveraging the full Product Ops team for implementation.

As mentioned in another question, my “north star” for Product Operations is to “unlock Oscar’s ability to ship more product, better and faster.” The majority of my team does this by embedding within engineering pods, but everyone can contribute to this goal. As an example, in the last year I took on an outsourcing project, tech-wide coordination for our peak selling season and (partially) redesigned our roadmap process. While measuring success is important, it’s more important to actually do the work that adds value. Sometimes it’s hard to measure outcomes, but people should be able to feel the value you’ve unlocked for the team! Instead of stressing about metrics, I’d focus on establishing Product Ops’ reputation as a team that gets-s***-done and contributes to the department (and company) results. So, in our first year of Product Ops at Oscar, I was less focused on capturing quantifiable metrics and more interested in building our brand within the Product Team. Each quarter members of my team would agree to a “roadmap” of high value work with their PM counterparts, using a prioritization framework we had developed. At the end of each quarter, each team member would summarize the impact of their key projects, usually focusing on the amount of PM or Engineering time saved. Even though we didn’t have a universal success metric, PMs and Engineers saw the value we brought to their pods and started advocating for additional Product Ops staffing in 2022. In 2022, I’m growing our team by more than 2x, but we will only have ~70% coverage of our feature pods (and no Product Ops allocation to our ~10 Infrastructure pods). I’m currently working on ways we can quantifiably measure the impact that Product Ops has on the pods that we are allocated to. This will also help us decide as a Tech Leadership team (Product AND Engineering) whether we want to continue to grow the team further. While I haven’t put it into place yet, my plans are to survey the key stakeholders on each pod (Product Managers, Engineers, Product Designers and Product Ops) and to capture how much time each group is spending on their “highest value.” My hypothesis is that when a pod has a fully-ramped, embedded Product Ops team member, everyone will spend a greater percentage of time on “high value” work – including Product Ops. Note: My definition of “highest value” is still a work in progress, but here are a few examples: * Product Managers – Industry Research, Product Vision & Strategy * Product Designers – Prototyping, User Research, * Engineering – Technical Design, Systems Architecture * Product Operations – Process Optimization, Enabling Self-Service

In my experience, it’s worked out extremely well to have Product Operations report directly to the Head of Product. Here at Oscar, I directly report into Jesse Horowitz, our Chief Product Officer and sit on his leadership team. This allows me to have full visibility into and alignment with Product’s priorities and staffing, which allows me to make global trade-offs. I’ve found this structure to be extremely effective. Other alternatives I’ve seen: * Product Ops rolling up into Operations – this can work and be effective if the primary focus of the Product Operations team is to enable and educate the company’s internal operations team & customers. * Benefit: Product Ops is deeply aware and empathetic of the operations teams, their processes and workflows. * Risk: Product Ops loses touch with the Product Managers and is viewed as a downstream stakeholder, rather than an embedded member of the team. * Product Ops rolling up within a central “Biz Ops” function – this can work and be effective if the primary focus of Product Operations is to develop best practices and coach Product Managers. * Benefit: Product Ops can drive departmental changes and efficiencies in close partnership with other Operational teams (Sales Ops, Marketing Ops, DevOps / Engineering Ops). * Risk: Product Ops is viewed as a consultant who doesn’t understand the day-to-day context of Product Management. * Product Ops rolling up within Product Areas/Verticals – this can work and be effective if each domain has specific needs and requires subject matter expertise. * Benefit: Product Ops can tailor their work to the priorities of their specific domain area. * Risk: Product Ops becomes locally optimized and inflexible. Down the road, Product Ops may be incentivized to create (or hold on to) tasks that they could otherwise work themselves out of.

Oscar Health is the first company I’ve worked in with both Product Ops and PMO (Program Management Office), so I can share how we think about the distinction in our context. As I shared, the bulk of Product Ops is embedded within specific engineering pods – my team is expected to be subject matter experts of the domain areas they cover. So, if the work is domain specific and execution related, chances are high it will go to Product Operations. In contrast, our Program Managers are aligned to wide-reaching company initiatives – our PMO teammates need to have the “big picture” in their head and can’t go particularly deep in any one domain. So, if the work is domain agnostic and ensuring others execute on their tasks, we expect it to live with PMO. An example of this relates to Open Enrollment (OE), Oscar’s yearly “busy season” when individuals can select health insurance on the public exchanges. Open Enrollment touches more than half of Oscar’s 40 pods – there are a lot of discrete tasks that need to be executed on to ensure that we are ready for OE. Coming up with the plan for our Tech pods and tracking to validate that we will hit key milestones is the responsibility of PMO. Ensuring that a pod executes on their assigned work is the responsibility of Product Ops.

I can’t answer this question specifically, because I haven’t worked closely with a revenue operations function. But here are a few thoughts about aligning on priority and company goals more generally. First, acknowledge that strategic alignment is hard – the frequently adopted OKR framework attempts to align teams around common objectives and goals, but it is no easy feat! If you’re having a hard time agreeing with your partners in business ops and product ops, it might be worth resetting the conversation. What is each person’s understanding of the company goals? How do they see their actions as contributing to that goal? Some of you may be making assumptions or may have blind spots. You also mention agreeing on how to prioritize product enhancements – that sounds like you need a prioritization rubric or framework! It doesn’t have to be fancy, but spend a bit of time (I’d recommend with your colleagues) and figure out the dimensions on which you’re evaluating priority. I’d target between 3-7 different elements – these might include things like cost / level of effort, number of customers it will reach, alignment to company priorities, change management or training required. The nice thing is that if you can all agree on a common prioritization framework, you can then apply it consistently to any new requests that come in.

My go-to resource for Product Ops right now is PLA They have great blog posts and a Product Ops Summit (at least once per year, maybe twice?). My favorite aspect is their PLA Slack community – they have a specific Product Ops channel and folks are very generous with their time to share thoughts and best practices. I’ve also used it to set up 1:1 networking chats, which were invaluable as I was defining the Product Ops strategy at Oscar. Many of the prolific Product blogs (like Pendo.io, Product Plan, Mind the Product, Product School) also have Product Ops resources; however, some of those have a very defined point of view about what Product Operations ought to be. Given that I believe Product Ops can (and should) be tailored to what the company needs, I’ve found it more helpful to to engage with people in the PLA Slack community and have live discussions.

Here at Oscar, we’re fortunate to have a robust Product Analytics team that sits within our Data function. Our Product Managers work directly with Product Analytics and build dashboards. As a result, Product Ops doesn’t have specific analytics or data responsibilities, which is different from how some Product Ops teams are scoped. (Pendo’s definition of Product Ops, for example, likes to include product analytics/usage within the scope of Product Ops: “Product ops pros are often responsible for helping product management make more reliable decisions by equipping them with relevant usage data.“) Over time, I could see Product Ops’ relationship with Product Analytics evolving at Oscar – after a PM defines metrics with the analytics team, Product Ops could take over the monitoring, reporting and insights. But we’ve got a lot on our plate already, so until it’s identified as an urgent pain point, I’m going to let our Product Managers continue to take the lead there!