We Know the Product Ops Pillars. The Hard Part is Everything in Between.
The role is growing. The pillars are established. The people are respected. So why does the work still feel this hard?
Product Ops folks: Have you noticed something rather paradoxical recently?
Our role is more talked about than ever. More job listings. More LinkedIn posts (yes, I appreciate the irony of writing one more). More conferences with “Product Ops” on the agenda.
And yet, it can still feel like an uphill battle in earning that trust, gaining that buy-in, for the work you have been asked to do.
Sound familiar? You are not alone, as many conversations, interviews and survey results can attest to. A byproduct of building this newsletter and the Product Ops podcast is that both also act as a funnel for such information.
This article is, in a small way, also a reflection of the journey of Product Ops, as well as a reflection of the deep thinking Antonia published earlier this week on the creation of the Product Ops Manifesto. One of the great things we enjoy working together on this newsletter is the ability to curate independently, and yet riff off each other’s ideas!
We Are Still Explaining What We Do
This one stings a bit, but it is true. Despite the growth in awareness, Product Operations still lacks a universally understood definition. Now, this in itself is a nuanced issue, because as we all know, Product Ops is different in every business. Not different like ‘oh we do Product Management differently here' (you don’t, you just pick and choose what from Scrum you like), but in fact building on top of that to focus on what the business needs, needs first, and provides maximum value to a business selling its own USP. A standard definition is not applicable.
And yet, there are key and common pillars of the role that do apply more abstractly, more wavey-handy. This helps to align both operators on the responsibilities and measures of success, without being prescriptive and restrictive. Because a key aspect of the role is often problem-solving new challenges that have not been solved before. Which could literally be anything.
I’m not advocating for a prescriptive, fixed responsibilities list. BUT, a job description has a purpose in life still, and so when we call a role Product Operations, we should be talking about the same thing.
I monitor Product Operations job listings as part of the Roles Database we recently launched — and the variation in what companies mean by the title is staggering. One role is essentially a project manager embedded in a product team. Another is a data analyst building dashboards. A third is a strategic leader owning the entire product operating model. A fourth is a catch-all for “things the product team needs done that nobody else wants to own.” I refer you to ‘What Product Ops is NOT’ written 2 years ago and is still true today.
The inconsistency is not just a branding problem. It creates real pain for professionals trying to navigate the discipline. When the same job title can mean wildly different things at different companies, how do you benchmark your skills? How do you know if a role is a step forward or sideways? How do you explain to a hiring manager what you actually did in your last role when their frame of reference for “Product Ops” is completely different from yours? And how do you spot the ‘this isn’t Product Ops’ roles on the job boards?
For product management roles, leaders will typically want a product manager to add capacity. For Product Ops roles, leaders want someone to fill their specific gaps, which may or may not be what we, as professionals, identify as part of the role.
So do we have a role identity problem? I think until the industry converges more meaningfully on what Product Operations actually is, and what it is not, this will continue to create friction for the people doing the work. And until now, this has been down to the people in role educating their managers and their businesses on how Product Ops brings most value.
The Pillars Are Established. The Tensions Within Them Are Not.
The Product Ops Pillars: Strategic Support, Business Alignment, Data-informed Decision Making, Valued Communications, Iterative Improvement (of processes), Cross-functional Collaboration.
And underpining all of this is change management, of the people the role works most closely with. Because Product Ops is a people role first and foremost.
They appear in job descriptions, conference talk slides, and probably in most of our LinkedIn profiles. There is variation in the nonclamenture, but overall these are the role guardrails, the territory. Notice there is no mention of AI… because AI as a sticker is not a focus, but the application of it as a tool to make teams more efficient, is.
The pillars are not wrong. But the real story is not in the pillars themselves — it is in the tension between what those pillars promise and how the work actually plays out.
Let me walk through some.
Iterative Improvement (of Processes): The Pillar Everyone Sees — And the One Most Likely to Backfire
Process design and improvement is the most visible pillar of Product Ops. It is often where new hires are pointed first: “Can you sort out our planning cycle?” or “We need a standardised way to do roadmap reviews.”
And there is genuine, valuable work here. Designing planning cadences. Building templates that actually reduce cognitive load rather than adding it. Creating frameworks for prioritisation that help teams make decisions rather than just documenting them. Streamlining workflows that have calcified over years of “we have always done it this way.”
But process work is seductive because it feels concrete and deliverable. You can point to a new template and say “I built that.” You can show a streamlined workflow and measure the time saved. The danger is that Product Ops becomes synonymous with process, and specifically, with adding process. There is nothing inherently wrong with this if the overall improvement is a net-positive impact on value or effort or time taken to complete the task the process focuses on. Does it take 10 minutes to write a report for each squad vs 20 minutes per squad to go and find and unpick the information a leader needs.
The best Product Ops professionals I have encountered are as focused on retiring the process as they are on creating it. They ask “What can we stop doing?” as often as “What should we start doing?” They recognise that every template, every cadence, every reporting requirement is an expectation placed on someone else’s shoulders, and those expectations accumulate.
If the only thing your Product Ops function is known for is introducing new processes, something has gone wrong. You are not enabling the product team. You are burdening it with red tape. And in the age of AI, you will quickly become obsolete as Claude and co can take on those processes and either fully automate, to just provide the outcomes (who cares how it does it) or guide product leaders directly.
Data and Insights: Where the Strategic Potential Is Highest, And Most Underutilised
The data pillar is where Product Ops has the most untapped strategic leverage, and it is also where I see the widest gap between aspiration and reality.
At the tactical level, this pillar involves building dashboards, aggregating customer feedback, centralising product metrics, and making sure teams are looking at the same numbers. All necessary. All valuable.
At the strategic level, it means something quite different. It means being the function that connects the dots across the product portfolio, identifying patterns in customer feedback that no single Product Manager would see, surfacing insights about how different teams’ roadmaps interact (or conflict), and providing the data-informed perspective that shapes product strategy rather than just reporting on it.
The pain point? Most Product Ops professionals get stuck at the tactical layer. Not because they lack the capability, but because the infrastructure is not there.
Customer feedback is scattered across a dozen systems. Support tickets in one tool, sales call notes in another, NPS responses in a third, feature requests buried in Slack threads that nobody will ever find again. Product metrics are defined differently by every team; “active user” means one thing to the growth squad and something else entirely to the enterprise team. The data is dirty, incomplete, or locked behind access permissions that take three weeks to resolve.
You end up spending 80% of your time getting the data into a usable state and 20% actually doing anything useful with it. This is not a skills problem. It is a maturity problem. And it is one of the reasons the data pillar consistently underdelivers relative to its potential.
Collaboration and Stakeholder Management: The Pillar Nobody Lists on Their CV — And the One That Matters Most
I have long said that so much of what we do in Product Ops is people-focused - not tech or even process-focused, but people. How do we help others, guide others, enable others, and improve the working lives of others?
This is the pillar that does not fit neatly into a framework or a slide deck. It is the work of understanding why a particular Product Manager resists a new process — not because the process is bad, but because of how they respond to expectations and change.
It is reading the room in a planning session and knowing when to push for alignment and when to let teams find their own path. It is building credibility with an engineering lead who has been burned by “operational improvements” that just meant more admin for their team. It is navigating the politics of a quarterly planning cycle where three VPs want conflicting things and nobody wants to be the one to say so out loud.
The pain point here is that this work is largely invisible. You cannot put “navigated three weeks of political tension between the platform team and the growth team to unblock the Q3 planning cycle” on a dashboard. But it might be the most valuable thing you did that quarter.
Product Ops professionals who excel at this rarely get credit for it in the metrics their organisations care about. And that invisibility creates a vulnerability, because when someone asks “What does Product Ops actually do?”, the answer “I spend a significant portion of my time on stakeholder relationships and change management” does not land the same way as “I built a dashboard that saved 200 hours.” Not just because it’s numbers, easily converted into money, but because it surfaces the unsavoury reality of the business.
Both are true. Both matter. But only one is easy to measure.
Change Management: The Pillar That Underpins Everything — And Exhausts Everyone
Every pillar I have described involves change. New processes are change. New data practices are change. New tools, new cadences, new ways of working — all change. Product Operations is, in many ways, a permanent change management function. This doesn’t mean we just change things all the time, but we manage colleagues through changes when they occur in the short, medium and long term.
And change management is exhausting. Not because the changes are bad, but because resistance is constant, varied, and deeply personal.
The same initiative, communicated the same way, lands completely differently depending on who you are talking to. One Product Manager embraces it immediately and has it running by the end of the week. Another asks seventeen follow-up questions before they will even consider it. A third nods along agreeably but never quite gets around to implementing it. And a fourth seems to resist it purely because you asked them to do it.
This is not a failing of your communication, your process design, or your change management skills, although we can always improve those. It is, at least in part, a fundamental difference in how people respond to expectations. And understanding why people respond differently, and adapting your approach accordingly, is arguably the most important skill in Product Ops.
Most Product Ops professionals learn change management through trial, error, and the occasional bruising experience. Very few organisations invest in building this capability deliberately or provide any training or guidance to those on the front line. And yet it is the skill that determines whether all the processes, data, and tools you design actually get adopted — or just sit in a Confluence page gathering dust. Sadly, I will admit, I have a few myself right now.
I strongly recommend you review The Four Tenencies & Product Ops for a deep dive into how people react differently to change and expectations.
The Strategic-Tactical Divide
And then there is this…
You were hired, or you positioned yourself, to be strategic. To design the product operating model. To build the systems and feedback loops that help product teams make better decisions, faster.
And then Monday morning arrives, and you are chasing a Product Manager for their roadmap update, fixing a broken Jira workflow, reconciling two teams’ definitions of “active user,” and preparing a deck for a quarterly review that nobody will read properly.
None of that tactical work is unimportant. It is often where trust is built and where the function proves its value in its early days. But the gravitational pull toward the tactical is relentless, and if you are not deliberate about carving out space for strategic work, you will look up in six months and realise you have become a very expensive project coordinator. And here is the thing, the tactical work is always needed to some degree; if you are giving people more time and focus back onto their primary role, the part of their job that is most valuable at driving the business forward, then this is no bad thing. But, this can just push the less valuable work downstream
The organisations that get the most from Product Ops treat the tactical as a means to the strategic; you earn the right to shape the operating model by demonstrating that you understand the operational reality. The ones that struggle treat the tactical work as the entire job description and then wonder why the function feels replaceable.
The Organisational Pain Points
Beyond the work itself, Product Ops practitioners are navigating structural challenges, and I think we need to talk about them more openly.
The perception gap. Product Ops is fundamentally a people discipline, if I have not already made this clear! But the people who hire us, and the people who evaluate us, often see us through a purely operational lens. They want processes documented, tools rationalised, dashboards built, workflows standardised. None of that is wrong; it is all part of the job. But the hardest, most impactful work in Product Ops is almost always human. The organisations that recognise this get the most from the function. The ones that reduce the role to its most mechanical components eventually question why it exists.
The career ceiling. In theory, the Product Operations career path runs from Junior/Associate all the way through to VP. In practice, many professionals hit a wall at the Senior or Lead level. Our annual State of Product Operations data tells part of this story; the number of Director-and-above level Product Ops roles remains small relative to the mid-level. Many organisations hire their first Product Ops person, see value, but never build a team around them. No team means no upward path, no progression, and eventually, no retention. Businesses are losing experienced practitioners because the progression problem has not been fully solved.
The redundancy question. When we designed the Product Ops Confidential salary survey, we included a question about redundancy. Not because we wanted to be alarmist, but because the community was already talking about it behind closed doors. Product Operations roles, particularly in companies where the function is small or new, are vulnerable when budgets tighten. The logic, from a leadership perspective, is brutally simple: if it is not directly building the product and it is not directly selling the product, it is overhead. We know that framing is wrong. But knowing it is wrong does not make you redundancy-proof. And the professionals who have experienced it, sometimes more than once, carry that uncertainty into every subsequent role.
AI is reshaping the landscape. The current narrative around AI and Product Ops tends to focus on automation: AI will build your dashboards, summarise your feedback, and generate your reports. And some of that is happening. But the more interesting shift is strategic. If AI can handle more of the mechanical, operational work, the data aggregation, the process documentation, the tool administration, then what is left?
The answer is the human stuff. The change management. The stakeholder navigation. The judgement calls about what to standardise and what to leave alone. AI might actually accelerate the transition of Product Ops from a process-centric function to a people-centric one. Which is where I think the discipline’s real value has always been, we are just getting better tools to prove it.
Where Does This Leave Us?
It would be hard to argue that I am anything but optimistic about Product Operations as a discipline. But I am also pragmatic. The pain points I have described are real, and they are felt most acutely by the people doing the work every day. But they are also, in many cases, the pain points of a function that is still maturing. Still finding its shape. Still working out what it wants to be when it grows up. We have to remember that the Product Ops role has pretty much been built on the fly by the people doing it - the ‘Build an Aeroplane while in Flight’ adage (which is ironically how we tend to approach Product Ops when evolving our product teams! Read about that here).
The pillars are established. We broadly agree on the territory. The challenge now is navigating the tensions within that territory: strategic ambition vs. tactical gravity, process creation vs. process burden, data potential vs. data infrastructure reality, people work that is essential but invisible, and change management that underpins everything but drains everyone.
This newsletter is always honest about the role. It’s not about blindly evangelising Product Ops, but takes a microscope to what we do. Not just celebrating the growth narrative, but interrogating it. Not just sharing best practices, but admitting where the practice is still uncertain, and learning collectively by sharing what others try out.
The message to Product Ops Professionals:
Your experience matters. The frustrations you feel are not yours alone; they are shared across a global community of people trying to build something that did not exist a decade ago. Talk about them. Share them. The more honest we are about where the friction sits, the better equipped we are to do something about it.
The message to Product and Business Leaders:
The Product Ops professionals in your organisation are probably carrying more ambiguity, more scope, and more existential uncertainty than you realise. Invest in their career paths. Define the role clearly. And recognise that the most valuable work they do is not always the most visible.
4 years ago, I pulled together the Product Ops pioneers of the time to recognise that the function is evolving, and the need to make sure it evolves in a direction that serves the people who chose it as well as the organisations that benefit from it. This is as true now as it was back then.
Graham