Skip to content

Beyond headcount: Three proven patterns for investing in product ops

How leading companies accelerate product ops without hiring for the role

You’ve got a product team to run and don’t want to (or can’t) hire for product operations. You’re not alone – NVIDIA and Cisco, Retool and Replit all got to where they are without product ops.

I’m hearing hesitation about hiring product ops from the product leaders I’m talking to nowadays. Some of the reasons why:

  • Your budget is tight (isn’t everybody’s?
  • Your team isn’t quite big enough for dedicated ops
  • You’re not yet ready to introduce a new function

Despite being a product ops obsessive, I believe it’s totally okay to not have a product ops team. 

What matters isn’t dedicated headcount—it’s having systems and processes that help your product managers thrive.

For the teams out there that don’t want to hire a dedicated product ops manager, what are your options? I see these three formats most frequently: 

  1. Leadership-owned: Product leadership runs product ops on a permanent basis. 
  2. Rotational system: The product leader delegates product ops responsibilities to their leadership team. They switch who has responsibility for what every 3-6 months. 
  3. Management training: Product leadership coaches individuals to execute on product operations. This grows the IC’s leadership know-how.

Leadership-owned

Welcome to the default choice for most companies. Leadership owns product operations alongside their other responsibilities. 

At smaller companies, the head of product takes it all on. At larger companies the VP- or Director-level product leaders take ownership of product operations as a team. Sometimes they each take ownership of ops for their own domain; sometimes they each take ownership of one area or activity. 

Domain-owned product opsHorizontally-owned product ops
The Director or VP owns product ops for her area. In this case, product ops for the payment infrastructure team will look different from product ops for the ecommerce team.The product leader owns one area, such as roadmapping, analytics, or OKR tracking, across all product teams. There isn’t a connection between the leader’s operational responsibilities and the domain they lead.
Two different styles of leadership-owned product ops

Pros

Product leadership has the most touchpoints with other functions such as marketing, finance, and HR. This gives great organizational context that they can bring to the operational side. 

Looking internally, they already focus on growing the team’s skill sets. They are setting product strategy. This makes leadership best-positioned to know which product ops investments will have the greatest payoff. 

Pitfalls

Product leaders’ have many responsibilities. Ops frequently drops to the bottom of their list. This means the work might not get done at all.

If the product leader only runs ops for their domain, they can also create inconsistencies. A leader on team A does things one way, and a leader on team B does things differently. This can create scaling challenges.

If you choose this approach, be honest about whether you can give operations the time and attention it needs. Otherwise, you might find individuals across the company trying to build out product ops support on the side, unrecognized  – I call this shadow product ops.

Rotational system

In a rotational system, different product leaders take ownership for a pillars of the product ops strategy for 3-6 months at a time. The leaders might choose their own pillar or be assigned one by the head of product.

This is how Sanchan Saxena ran his team at Airbnb when he was leading product through a massive period of growth:

“The way to scale [product operations] was for me to turn my leadership team into part product leadership and part product operations team. Every quarter I would have this ‘happy gifting ceremony’ to my direct reports. I’d say, ‘This quarter you’re going to run quarterly planning.’ A bunch of those mechanisms that typically happen through the help of product operations were happening as part time voluntary exercises, or rather ‘voluntold’ exercises, volunteered by them, told by me.”

Pros

The rotational system can be especially effective at larger organizations where there’s value to consistency across teams. It forces leaders to focus across the whole PM team.

The leaders get a chance to know more of the product team as they go through their rotations because their work will touch so many people. It provides the head of product a chance to measure their team across an operational dimension. A product leader that quickly improves an especially challenging area demonstrates great leadership potential. 

It also forces more documentation. Knowing that you won’t be hanging on to your area incentivizes you to write things down and automate as much as possible. (You want your peers to do this for you too, so you don’t get thrown a hot flaming mess to clean up every quarter.)

Pitfalls

There is a risk of inconsistent execution – one leader might go in one direction, while the following leader switches course. Changes like that will frustrate the team.

Another disadvantage is the context-switching. Each time the rotation happens, every product leader needs to learn something new. That could become an advantage – it gives everyone opportunities to get familiar with the entire product development process. 

To succeed with this approach, there need to be enough product leaders to rotate through the various operational tasks and strong camaraderie to support the handoffs. 

Management training

Product operations work provides an ideal training ground for developing future product leaders. It’s a two-for-one: train up your high-potential individual contributors and get ops work executed. 

This is the approach we used at SpotHero – my CPO told me that he wanted me improve our roadmapping processes. As a small product team of 6 at a VC-backed startup, we didn’t have a middle management layer. He detailed how our lack of process was hurting our ability to make resource allocation decisions. He then asked me to move it forward, train the team, and get ready for next quarter’s planning process. 

Pros

I had to learn what strong roadmapping processes looked like at other companies. Once I learned more, I had to get better at influencing my peers.

As I dug in, I also learned a lot about the limits of product ops. The system I designed didn’t work at all for the innovation team. 

This project also happened to be where I developed my love for product ops generally.

Through this experience I got managerial training in how to influence others. I practiced systems thinking. It allowed me to grow critical skill sets and demonstrate ways in which I was ready for promotion. 

Pitfalls

It took me longer to do than it would have taken my CPO. He’d built roadmaps before and it was my first time. But my doing it freed up his time to focus elsewhere.

He started me off by providing a template he had used in the past, so I wasn’t flying blind. And continued to coach me with feedback and guidance.

This wouldn’t have worked well without that initial briefing – he provided a clear product ops strategy that I was fitting into. ICs will struggle to get the right solution in place without strong context and vision.  

Which pattern makes the most sense

Before choosing a pattern for getting the work done, you must have a solid foundation in a product ops strategy. Once that’s established, you should have several pillars of your strategy. For each major pillar of your strategy, pick the pattern that makes the most sense.

The tradeoffs to weigh between each pattern includes: 

  1. Org-wide consistency: How likely is it that one product team works similarly to other groups?
  2. Knowledge-sharing: Do you want everyone on the team to have equal knowledge of what’s going on across the organization from a product ops context?
  3. Leadership burden: How much work is it for leadership to support
  4. Speed: Is there urgency around getting this infrastructure into place?

Based on these questions, you can think about which pattern might make sense for each pillar of your strategy as follows:

FactorLeadership-OwnedRotational systemManagement Training
Org-wide consistency: How likely is it that one product team works similarly to other groups? Consistent if horizontally owned. Different across teams if each leader runs their own operations.Consistent around the organization, but will change from one rotation to the next. Consistent to the degree that the IC can influence their peers. 
Knowledge-sharing: Do you want everyone on the team to have equal knowledge of what’s going on across the organization from a product ops context? The leaders should share their processes and procedures internally, but there isn’t a built-in mandate requiring it.Knowledge gets shared by default throughout the rotations. Documentation encouraged by nature.Can be well-documented if the IC is encouraged to lead through a written culture. 
Leadership burden: How much work is it for leadership to supportLeadership has to do the work themselves or delegate it out, but responsibility ultimately lies with them.Some rotations will be more work and others will be less; this can help smooth the burden. Coaching takes less time than executing it yourself. 
Speed: Is there urgency around getting this infrastructure into place?Leadership has the knowledge to execute more quickly, but might not have the time to do it.There’s a ramp-up period with each rotation, but the way that each person will build upon the work from a previous rotation can be helpful for speed. Individual contributors have the least experience getting operational changes implemented. This can slow them down. On the other hand, they likely have more time to execute.
Patterns of Product Ops Comparison

What to do if no pattern works

Even the best-structured product ops approaches occasionally hit a wall. Some initiatives require dedicated focus that side-gig attention simply can’t provide.

Signs that none of these strategies will work: 

  • Projects requiring specialized expertise: the above strategies all use generalists to get the work done. But sometimes you need a particular type of background or skill set. 
  • Initiatives needing concentrated effort: When doing work on the side, you can expect someone to devote 10-20% of their time. Sometimes an initiative needs more time over a shorter period. 

An example of this is installing product analytics suites. Installing product analytics isn’t a part-time job. When someone can only dedicate 10-20% of their time, what should take weeks stretches into months. Instead, someone with the experience and know-how should partner with the teams on the ground. The specialist can move the project forward, while the teams can provide domain expertise and help execute. 

Meanwhile, your team operates without crucial data insights.

In these instances, there are a few different options: one is pulling someone off their day-to-day work and moving them specifically into this special projects role for a period of time. A second is finding someone on a different team who wants to grow their product skills who can dedicate a larger percentage of their time – at SpotHero we enlisted a QA Analyst to take a leadership role in managing our analytics implementation. A third is to bring in some outside help via a consultant or coach. 

Bringing on a product operations coach to help work through the kinks can also be a cost-effective way to move this forward. The coach can advise leadership or help take some of the coaching and mentoring responsibilities off of leadership’s plate. 

Sometimes you just need to hire for it, even if it’s temporary. 

The work needs to get done

Let’s be honest: product operations work isn’t optional. Whether you’re tracking it or not, your team is spending time on operations—probably more than you realize. The question isn’t whether to invest in product ops, but how to do it intentionally and effectively.

Pick a pattern of how you want to move your operations function forward and go for it. If, after six months, it isn’t working, try a different one. 

  • Leadership-Owned: When speed and consistency are crucial and you have experienced leaders who can dedicate time to ops
  • Rotational: When knowledge sharing is priority and you have a stable team that can handle regular transitions
  • Management Training: Best for nurturing future leaders when you can afford a longer-term investment.

As your company grows, you will find different structures make more sense. And at some point you may realize that it’s time to go and hire for product ops

Ultimately, align your tactics with your operational strategy. Mix and match as needed—what works for one pillar might not suit another. If you start with a clear product ops strategy that aligns to company goals, it will be easier to figure out how to get the ops work done within the company. 

Now, it’s time to take action. Choose your pattern, commit to it, and watch your product team flourish.

Thank you so much to Brian Gibson, Greg Stoutenberg, and Shivam Malhotra (#openToWork) for your feedback on the draft. My table would have been especially disastrous without your comments, and you helped me bring more focus and clarity to many other places as well.