Four definitions of product operations
I recently attended a product operations meetup that showcased a challenge that’s been on my mind. We went around the room and shared what our scope is for our various roles. Answers ranged from focused specialists handling launch readiness to generalists juggling analytics to release notes and everything in-between.
I’ve been wondering if we’re in the middle of a product ops identity crisis: there is no one clear definition of what product ops actually is. We all use the title “product operations”, but what we actually do varies from one company to another.
Whenever I’m asked “what exactly is product ops?” (happens a lot), I don’t have one tidy answer. Instead, I find myself weaving through multiple definitions, each capturing a different facet of what we do. And honestly, that’s exactly how it should be.
Let’s reframe this “identity crisis” as something positive. When you’re forced to question who you are and what you do, you dig deeper. You have those crucial conversations that sharpen your understanding. You challenge your assumptions. In product ops, this multiplicity of definitions isn’t a weakness – it’s a strength that reflects the dynamic nature of our work.
Rather than demand a unified definition of product ops, I look at the range of definitions as an opportunity to gain a clearer view of what product ops actually is and isn’t.
For example, none of these definitions demand a product ops team. These definitions focus on the work that needs to be done to support a product team. That doesn’t require having people with the job title of “product operations” to get the work done. As you’ll see in the examples I pull in below, some show a product ops team doing the work and others show product leadership taking responsibility.
I’ve noticed something interesting in my consulting work: companies tend to choose their product ops work based on which definition resonates most with their current needs. As we explore these different definitions, consider when each one might be most valuable for your team.
Product strategy enablement
In this definition, the purpose of product operations is to make it easier to turn your product strategy into a reality.
This definition requires a clearly articulated product strategy. I see it at companies that are growing quickly and still building out some of the foundational product management infrastructure.
Product strategies often require developing new capabilities on the team – whether improving the use of analytics, tightening collaboration with marketing, or identifying and going after a new customer segment.
Product ops, when done right, looks at the product strategy and identifies the capability gaps. Closing those gaps helps the team accelerate and improve execution on that strategy.
Example: Making customers feel listened to
One coaching client I was working with was struggling with her product ops strategy. We started digging into the product strategy for the next year. She pointed out that a major goal was reducing churn by improving a particular type of client sentiment about the company.
She observed that product management had set up an ideas portal for customers to submit product suggestions and ideas in, but it was a black hole. There were 3,000 suggestions that hadn’t been replied to or acknowledged in any way.
We realized that this was an excellent opportunity to enable this strategy. Fixing the ideas portal would help customers feel listened to and improve product managers’ user research. Product managers weren’t making good use of this user feedback today, and product ops was perfectly situated to turn that around.
While this one narrowly focuses on the product strategy, the next one is more about how the right data encourages a better product strategy.
The discipline of helping your product management function scale well
Within this framework, product teams go through growing pains, and product ops helps minimize those pains.
This definition comes from Melissa Perri and Denise Tilles’ book, Product Operations. They argue that product strategy needs the right inputs around quantitative and qualitative data.
Small product teams rarely struggle with product ops. When you’re a small group, everyone can keep the context of the product team’s work in their heads. There are relationships supporting communication and collaboration.
Large product teams almost always struggle with product ops. It becomes harder to understand what everyone is working on. Not everyone knows everyone else or all the features of the product. As a product and a team grow, product ops makes helps ensure everyone has the right data to make the most important decisions.
Product ops surfaces that data to the company, then creates the systems that help everyone decide how to pick a direction and execute on it.
Example: Annual planning as the team scales
The product ops team at one SaaS social media company does this quite well. They support a robust planning cycle across multiple teams.
The company went public a few years back, leading to further team growth. It could no longer support ad-hoc communication around what product was working on.
The product ops team coordinates quarterly and annual planning via strategy document reviews. They make sure everyone aligns on where the company is going and aware of how product strategy is playing out at different levels.
Focusing on getting the right information to the right people makes a lot of sense as a way to think about product ops. The next definition looks at it through a slightly different lens by thinking more about the frictions within life as a product manager.
Product managing the product manager experience
Using this lens, product ops are the product managers to the product management experience.
This definition focuses more inward on the functioning of the product team itself. It might touch on the other teams that product partners with, but its focus will be more internal.
In the same way a product manager builds a product, product ops builds a product management organization. We make the product managers more successful. This increases the likelihood that teams are shipping the right things and driving company metrics forward.
Example: Finding the frictions in the product management role
When I was working on an organizational redesign project, I primarily thought about how I could be a PM for all the people doing product work at their company. Their product team was struggling because the product management role had been split between two job titles.
I conducted user research to create a process map of their experience. It revealed how challenging it was to be a product manager when you only had half the role to work with. When I brought this observation back to the product leadership, it helped us define what a better product management function could look like.
I brought my product management skills to this project – user research, ideation, and stakeholder management. I saw the people doing product management work as my users. This allowed me to to focus on their experience and redefine it in a way that dramatically increased product managers’ morale and impact.
While a product mindset is critical, I look at the product culture as the vision behind the product. The next definition doubles down on the culture side of it.
Designing the company’s product culture
This definition looks at how product leaders use product ops to design a product culture that supports the broader company mission.
This definition takes a systems design approach – product ops creates a system in which team members operate. For this definition to work well, the product leader needs a clear vision of what kind of culture they’re trying to build.
A company’s product culture informs how they make decisions, how they build product, and ultimately what they ship. Product ops shapes this culture by making it easier to build products in the ways you want and harder to do the ways you don’t.
Example: Creating a customer-centric culture
SpotHero wanted a very customer-centric product culture, and invested in it. We made sure it was easy to look up any customer’s contact information, gave everyone access to the customer support system, and asked every new employee to work the customer support line in their first few weeks on the job.
These various forms of infrastructure made it exceedingly clear – customer centricity was at the heart of what we were doing. The message was loud and clear – this is what we want to be, and these are the ways we’re going to help you do it.
The abundance of definitions is a good thing
You know what’s beautiful about our product ops identity crisis? It’s not really a crisis at all – it’s a gift. Each definition we’ve explored represents a different way we can drive value, and that’s something worth celebrating.
Think of these definitions as tools in your toolkit rather than competing philosophies. Sometimes you’ll need to be the strategy enabler, other times the culture architect. Just like a product manager shifts between customer interviews and data analysis, we adapt our approach based on what our teams need most.
I encourage you to look through these various definitions and try them on. See which one feels right for your team, right now. It might be that as your mission changes, a different definition will start to make more sense.
These definitions aren’t mutually exclusive – they often work in harmony. For instance, when you’re product managing the PM experience, you’re naturally positioned to enable strategy and scale the function. It’s about finding the right mix for your context.
Having so many different definitions is a sign that we have broad scope and impact in our work. We can touch so many different aspects of a company and a product team.
Nobody at the meetup worried about how different each person’s role was. There wasn’t a concern that someone was doing it “wrong”. Instead, there was a sense of awe that we could be working on such different initiatives and still have so much to learn and share from each other.
Many, many thanks to Kevin von Gillern (#OpenToWork), who found a dozen places where I was being unclear, and to Joshua McLaughlin, who helped me focus in on what I was really trying to achieve with this article.
