Getting product ops off the ground when you don’t have the authority
Our new CPO keeps asking how our product organization works—how we use data, collaborate across teams, and measure success. Reality is, we don’t have good answers.
Everyone operates differently, with minimal shared tooling or processes. Releases get rolled back because customer success wasn’t well prepared. Work gets duplicated because roles aren’t clear. While our program management team handles some operational tasks, no one has the mandate to drive systematic improvements. We need product ops.
How do I get leadership to consider a formal product ops team when I don’t have all the answers? And how do I move this forward without stepping on people’s toes?
—Prod Ops in Limbo
Dear Prod Ops in Limbo,
A new leader asking probing questions about how your product organization works presents a perfect opportunity. They’re likely discovering gaps between their expectations and reality—gaps that product operations can help fill. More importantly, they’re probably looking for ways to demonstrate product leadership in the organization to deliver some early wins.
I’ve talked with dozens of product leaders about whether to invest in product ops, as well as many first product ops hires across different companies. One pattern stands out clearly: product ops tends to be most successful when it’s positioned as enabling leadership’s vision rather than fixing broken processes.
Your CPO is asking about data, collaboration, and measuring success. These are exactly the areas where strong product operations can help a leader be more effective. The key is showing how dedicated operational support will help them execute their strategy—and how the current decentralized approach is holding them back.
Here’s how to build your case:
Document the hidden product ops work
Your first step is mapping out all the product operations work already happening—both official and unofficial. Product ops work often exists in the shadows, with various team members picking up operational tasks alongside their core responsibilities. In addition, you’ve got your program management team taking care of some of it. Taking inventory can reveal where your organization most needs operational support.
Categorize your audit across the four pillars of product operations:
- Data & Analytics: Who’s maintaining dashboards? Setting up experiment frameworks? Defining metrics? You might find your most data-savvy PM has become the unofficial analytics guru.
- User Research & Insights: Look for who’s managing research repositories, scheduling customer interviews, or creating synthesis templates. Often this falls to individual PMs who each develop their own approach.
- Team Collaboration: Watch for who facilitates planning sessions, maintains documentation, or creates process templates. Program managers frequently fill this gap, but not systematically.
- Cross-Functional Communication: Notice who handles release communications, stakeholder updates, and go-to-market coordination. This work often gets distributed across multiple roles without clear ownership.
Use the shadow product ops worksheet to systematically identify who’s doing what.
As you find areas where product ops work is happening, document:
- Current owners (official and unofficial)
- Frequency of issues
- Impact (time wasted, risks created, opportunities missed)
- Previous attempts to fix the problem
Watch especially for:
- Work being duplicated across teams
- Critical tasks falling through the cracks
- “Extra” operational work people have taken on
- Inconsistencies in how different teams handle the same processes
This inventory will demonstrate to leadership that product ops work is already happening— just inefficiently and without proper support or coordination. More importantly, it shows how these inefficiencies are actively holding back execution of their product strategy.
Run a focused proof of concept
Choose a pilot project that connects directly to your CPO’s product strategy. This demonstrates how product ops can be a strategic partner, not just a fix for operational headaches.
Look for problems where:
- Success can be clearly measured
- The pain is felt across multiple teams
- Leadership is already asking those questions (like “how is Feature X performing?”)
- You can show results within 2-3 months
For example, if your CPO keeps asking about feature performance and no one can give clear answers, your pilot might focus on establishing consistent measurement practices. This addresses an immediate need while building infrastructure for better decision-making.
Frame your pilot in terms of outcomes, not just activities. Instead of “implement a release checklist”, say “reduce customer-impacting rollbacks by 66% within 90 days”.
The goal is to prove that dedicated product ops can drive systematic improvements, not just temporary fixes. Pick something meaningful enough to matter, but contained enough to execute well.
Find your change partners
Product ops transformations work best when they’re collaborative efforts, not solo missions. You need allies who understand both the current pain points and the potential for improvement.
Partner with Program Management
Partner with Program Management by identifying a program manager who’s already handling product ops-adjacent responsibilities.
Many program managers are effectively doing product ops work without the formal title, making their experience invaluable in adding credibility to your initiative.
By collaborating closely with them, you can demonstrate how product ops complements and enhances program management rather than trying to replace it. Their partnership will be crucial in showing how these two functions can work together to create more value than either could alone.
Build a Coalition
- Share ownership of the initiative across roles and teams
- Create opportunities for others to contribute ideas and shape the vision
- Be transparent about your goals and progress
- Give credit generously – this builds trust and reduces resistance
Remember: trying to drive this change alone risks both burnout and resistance. The goal isn’t to be the hero who fixes everything, but to create sustainable, systematic improvements that everyone feels invested in.
Set the Right Narrative
The story you tell about product ops will shape how the organization receives it. Focus on enabling strategy and improving execution rather than adding process or control.
Frame it as Evolution, Not Revolution
Frame your product ops initiative as evolution, not revolution. You’re not creating a new function—you’re formalizing and focusing work that’s already happening. This is about making existing investment more effective, not asking for big new budgets. The goal is to reduce chaos and confusion, not add bureaucracy. Program management isn’t going away—product ops helps them be more effective.
Lead with Evidence, Not Theory
- Use examples from your documentation of current state
- Show concrete ways product ops could improve execution
- Highlight the cost of not having coordinated product ops
- Share stories of what’s worked at other companies
The key is positioning product ops as a strategic enabler that helps teams execute better, not as another layer of process or bureaucracy. Keep the focus on outcomes—better products, happier teams, faster execution—rather than the mechanics of how you’ll get there.
Product ops might not be the answer
Sometimes the conversation about product ops reveals deeper structural issues that go beyond operational challenges. As I talked more to Prod Ops in Limbo, it became clear that the organization faced fundamental questions: Do we have the right number of product managers for our company size? Are roles and responsibilities clearly defined? Is our current structure helping or hindering delivery?
These larger organizational challenges often surface during product ops discussions because operational friction frequently stems from structural misalignment. While these issues might be outside your immediate capacity as an individual contributor to fix, acknowledging them helps frame the product ops conversation appropriately.
Consider suggesting a broader product ops assessment if you notice these patterns. This can help leadership understand whether product ops is the right starting point or if more fundamental organizational changes are needed first. I’ve got a guide on when you might want to create a separate product ops team that can help with this evaluation.