How to escape work that shouldn’t be yours in the first place
I’m a solo product ops manager supporting 14 PMs across several product lines. Half my time goes to triaging support tickets that escalate to product—I’ve automated what I can and cut volume from 300/month to 80, but the remaining tickets require deep product knowledge and nuance.
The other half of my time gets split across too many initiatives: rolling out opportunity solution trees, enabling our new product management tool, tracking OKRs, coordinating metrics, fielding questions from every team in the company. I can build processes and training, but with my attention scattered, nothing gets the focus it needs to actually stick.
I know there’s higher-leverage work I should be doing. Strategic improvements that would reduce those tickets in the first place. Process changes that would actually get adopted if I had time to build proper buy-in. But I can’t get to any of it because I’m constantly reacting to whatever’s on fire today.
How do I break out of the reactive cycle when the reactive work genuinely needs to get done?
—Buried in Tickets
Dear Buried in Tickets,
You already know what your highest-leverage work is. You can see it clearly. You also know that you can’t get to that high-leverage work while ticket triage is in the way.
The problem isn’t insight about what you should do—it’s permission. Even though it’s uncomfortable to say no, it’s time.
The reactive cycle you’re stuck in is a symptom of lacking organizational permission to focus. Without that permission, you’ll stay trapped between initiatives, never able to get any of them to a truly healthy place where they don’t need constant maintenance. You’ll keep building processes nobody follows, because you don’t have time to build the buy-in that makes processes stick.
Meanwhile, your leadership will get frustrated (if they haven’t already) that the things they hired you for aren’t progressing. You need to make sure that your leadership is aware that there is a focus issue, and then get permission to actually solve it.
The way out isn’t to work harder or hope leadership notices you’re overwhelmed. The way out is to bring it to their attention so you can drop some things on your plate and return to them later.
Here’s how.
Track your time and do the math
Before you can ask for permission to focus, you need evidence.
This week, spend five minutes at the end of each day logging where your time went. Don’t overthink the categories: Tickets; Meetings; Fielding questions; Roadmapping program; Opportunity-Solution Tree Buildout; etc.
At the end of the week, do the math. Let’s walk through what yours will look like:
Start with 40 hours. Subtract the meetings that have to happen regardless—let’s call that 10 hours. You’re down to 30. Half of that goes to tickets. Remove 5 hours for general answering questions, eating, and task switching. Now you’ve got 10 hours for everything else: opportunity solution trees, tool enablement, OKRs, metrics, answering questions from every team in the company.
Split 10 hours across four or five initiatives and you’ve got maybe 2-3 hours per week on each one. That’s not enough time to make real progress on anything. It’s certainly not enough to build the buy-in that makes change stick.
This math is your evidence. When you bring it to leadership, you’re not saying “I feel overwhelmed.” You’re saying “here’s why none of these initiatives are getting traction — I have 2 hours a week to spend on each of them.”
Write down your strategy
Your evidence gets you a discussion about time management. A strategy gets you permission.
You can’t ask leadership to deprioritize things without offering an alternative. “I’m overwhelmed” isn’t a strategy. “Here’s what I’d focus on, why it matters, and how I’d make time for it” is.
You can’t get product ops work done in short bursts. Product ops work is almost always about building systems that require adoption: Rolling out opportunity solution trees; Getting PMs to actually use the new tool; Making OKR tracking consistent.
Those initiatives won’t succeed if you aren’t actually changing behavior. Behavior change won’t happen in 2-hour weekly increments. You need sustained attention to build the buy-in and iteration cycles that make processes actually stick.
Ticket triage isn’t helping change behavior—it’s support work that happens to require product knowledge. The fact that it landed on your plate doesn’t mean it belongs there.
Start by identifying what you believe is your highest-leverage problem. Write down why you think it’s the most important thing you could work on—and what outcomes you’d expect if you had real time to focus on it.
Escaping the tickets
Then comes the hard part: your strategy has to include how you’ll escape the ticket trap. This work ended up on your plate because someone needed to do it—but “someone needed to do it” isn’t the same as “this is product ops work.” Without solving that, any plan for “higher-leverage work” is wishful thinking.
There are a few ways to approach getting tickets off of your plate:
Automate yourself out. You’ve already cut ticket volume from 300 to 80. What would it take to cut another 50%? Maybe you spend four to six weeks focused exclusively on building a solution to reduce inbound ticket volume to under 10 a week. The goal would be to get ticket time from 50% of your week to 10%—then you’ve got real capacity for transformation work.
Find another home for triage. You mentioned the remaining tickets require deep product knowledge. But just because you have that knowledge, should it be your job? At one company I worked with, QA handled triage on escalated tickets. They had capacity, they knew expected behavior, and they could determine whether something was a bug, a configuration issue, or expected functionality.
Tickets don’t have to flow through you—and frankly, they shouldn’t. Your 14 PMs and the teams they’re on have product knowledge too.
Reduce the volume coming in. This is the boldest option. What if you only took tickets from customers above a certain revenue threshold? Or paused ticket intake entirely for four weeks while you focused on strategic work? The reactive work feels essential, but it’s worth asking: what would actually break if you weren’t doing it? This experiment might also help the organization get a sense of how important these tickets actually are.
Once you’re clear on how to escape the tickets, put all of this in a document. Your highest-leverage problem. Your plan for escaping the ticket trap. What you need from leadership to make it happen.
A strategy that lives in your head won’t be able to convince everybody that a new direction is needed. A strategy that is written down can be circulated, debated, and approved.
Get organizational buy-in
Once you’ve got your strategy written down, treat it as a conversation starter.
Before you bring it to your EVP, think through who else needs to be on board. If your plan involves QA taking over ticket triage, you need the QA lead bought in. If it means changing how support escalates issues, you need support in the loop.
For each person you need to influence, ask yourself: What are their incentives? What’s in it for them? What do they need from you to say yes?
Your QA lead might be worried about capacity. Your support manager might be relieved to have clearer escalation paths. Your EVP might just want to know that the transformation work they hired you for will actually get done. Understand what each person cares about, and frame your chat with them accordingly.
Then circulate the document. Don’t just present it in a meeting and ask for approval. Send it ahead. Let people read it, poke holes in it, ask questions. Their pushback makes the strategy stronger and helps them invest in your mission. Their questions reveal gaps you hadn’t considered.
By the time you’re asking for formal approval, the people who matter should already understand what you’re proposing and why. The meeting becomes a confirmation, not a pitch.
When the answer is no
Sometimes you do everything right—data, strategy, buy-in conversations—and leadership still says no.
This is information. Understanding that they’re happy with the status quo means you’ve got buy-in for your split attention approach today, which is confirmation you didn’t have previously.
Even so, there might be space to improve your current workload. A few paths forward:
Make the tradeoffs explicit. If leadership won’t let you deprioritize the tickets, ask them to choose what gets your time. “I have 10 hours a week for these five initiatives. Which one or two should I focus on?” This forces them to own their contribution to the challenges you’re facing.
Shrink your ask. Maybe a six-week focus sprint is too big. Can you get two weeks? A clear timeboxing on tickets to 5 hours per week? Sometimes a small win creates the opening for bigger ones later.
Accept the signal. Some organizations don’t actually want transformation work right now. They want someone to keep the plates spinning. That’s a legitimate choice, even if it’s disappointing. If the role you were hired to do isn’t the role they need filled, that’s worth knowing sooner rather than later.
The goal is to get clarity on what’s actually possible so you can make informed decisions about where to invest your energy. Any progress on this is better than no progress.
One win at a time
You probably won’t get everything in your strategy approved. Leadership has competing priorities, and your ask is one of many.
But you’ll likely get at least one win. Maybe it’s permission to focus exclusively on reducing ticket volume for six weeks. Maybe it’s agreement that QA should handle first-line triage. Maybe it’s just taking OKR tracking off your plate for now.
That one win matters more than it seems. It buys you space to actually make progress on something. This is the start of the strategy flywheel.
More importantly, it builds trust. You made a specific ask. You delivered results. You demonstrated that you can prioritize and execute. Leadership now knows you’re not just complaining about being overwhelmed, but actually trying to do something about it.
That trust becomes leverage for your next ask. And the ask after that. Perhaps at some point they’ll even realize that one product ops person supporting a 14-person team isn’t the right ratio for the amount of change they’re trying to lead.
Over time, you’re not just earning permission to focus on one thing. You’re establishing yourself as someone who thinks strategically about where to invest their time—which is exactly the kind of thinking product ops should be modeling for the rest of the organization.
The reactive cycle won’t break itself. But with data, a strategy, and one win at a time, you can break out of it.