Stop Asking For Budget to “Improve Collaboration”
You're never gonna get it
“I could solve soooo many problems if I just had more budget!” 😩
Nearly every coachee tells me this at some point. The exasperation is palpable. The frustration is real. They genuinely believe that if leadership would just listen and give them the resources they’re asking for, everything would be so much better.
And I get it. I really do.
So I ask them: “Great! What problems specifically? How would you solve them? What’s the ROI?”
The response is almost always some variation of: “Well... we’d improve collaboration for starters. And communication! You know, make things run smoother.”
And that’s when I have to break the harsh news to them: That that’s exactly why their budget requests are being denied.
The Uncomfortable Truth
Everyone with whom I’ve had a variation of this conversation has had one thing in common: They’re all smart, capable ops practitioners who are genuinely frustrated that leadership doesn’t “get it.” After all, these are the same leaders who hired them! Why would they now stand in the way of better tools and a bigger team who can actually deliver on the promises of a strategic Product Operations function?
These people know exactly what’s up. They’ve identified the real problems. And they have ideas about how to fix them. They care deeply about making their teams more effective. All they need is a little more budget.
But here’s the thing: Leadership “gets it” just fine.
They get that you’re asking for headcount without being able to articulate exactly why that financial investment is a no-brainer.
They get that “better collaboration” isn’t a business case.
They get that you’ve positioned yourself (through varying degrees of fault of your own) as a nice-to-have support, not a must-have strategic capability.
And so they say no. Not because they don’t care about operations - they do. Not because they don’t value your work - they do. But because you haven’t given them a reason to say yes.
Both Sides of the Chasm
I’ve built Product Ops in-house and had to justify every cent. I’ve sat in budget meetings defending why we needed additional team members or a specific new tool to no avail. I’ve had to make the case for my own role’s existence before.
But I don’t think I ever really cracked it. Until I went freelance.
I was really taken with the idea of being able to help many companies improve how they operate instead of just one. Of seeing many different contexts, adapting my skills and expertise to each one, and helping organisations of all shapes and sizes get better at what they do.
But even before ever thinking about how I’d get my first clients, one thing was crystal clear to me: In order to be successful, I needed people to understand what I did and the concrete value I bring to their organisation.
Gathering support from the PMs by showing them how better Product Operations can improve their working lives is great - but they’re not the ones signing the check.
Since going freelance, my entire livelihood has depended on convincing executives that what I do concretely improves their bottom line - enough to more than make up for my consulting fees. Enough that engaging me is a no-brainer.
Every single engagement starts with someone deciding whether what I offer is worth what I’m charging.
That meant that I’ve had to dramatically change how I talk about what I do.
Nice to Have vs Strategic Capability
When I first started in Product Ops, I’d tell people “I’ll make your life easier!”
Because I felt like that was the best way to get those snarky PMs on my side.
Eventually I went a level higher. “Things’ll run smoother! We’ll be more aligned!”
Surely no leader could argue with that?
It turns out, they could. Having happy PMs who are aligned with one another is great, but let’s be honest - in the vast chaos of your organisation’s operating model, is that your top priority?
If you were a leader in your company and you had 100k to solve your biggest bottlenecks, how would you spend it? Would you give it to HR so that they can hire better talent faster? Would you give it to DevOps to ensure a more reliable infrastructure? Or would you give it to someone who promises fewer meetings (hopefully)?
Any product executive deals with a vast amount of burning dumpsters every single day. Most of which you’ll never even see! Dumpsters that are full to the brim with acute, meaningful threats to the bottom line - and that clearly state financial pressures, because someone did the maths.
There is no way in hell your collaboration initiative alone can compete with that.
This is the harsh truth: Nobody cares about “enablement” as a concept. They care about solving expensive problems.
And it’s not because executives are shortsighted or don’t understand the value of those things. It’s because they’re running a business, and businesses run on money.
When you say “I need budget to improve collaboration,” what they hear is “I want money to do something fuzzy that perhaps might make people feel better.” Real money that needs to be taken away from another dumpster fire.
But when you say “I need budget to reduce the average time from idea to shipped feature from 12 weeks to 8 weeks,” what they hear is “We could be 33% faster at getting to market.”
Under the hood, it’s exactly the same work. But it’s a completely different conversation.
And I know this feels unfair. I know it feels like you shouldn’t have to “sell” the value of making teams more effective. But that’s the reality of the job. If you’re in operations and you can’t articulate the business case for your work, you’ll always be fighting for scraps - and you’ll never reach your organisation’s full potential.
What “Expensive Problems” Actually Look Like
Let me get concrete about what I mean by “expensive problems” because I think this is where a lot of folks get stuck.
If you’re a good Product Ops manager, you already have all the building blocks. You already know what doesn’t work, and you’re probably quite aware of the ramifications. All you need to do is stop talking in problems - and start talking about money or opportunity left on the table.
Here are some examples from my own work:
Cheap: “Teams don’t have easy access to customer data”
Expensive: “Product Managers are making prioritisation decisions without usage data, and in the last six months we only shipped 3 features that more than 15% of our users actually use. We’re wasting roughly 6 engineering months per quarter building things nobody wants.”
Cheap: “We don’t have a good onboarding process for new PMs”
Expensive: “New PMs take 4 months to become productive, and 40% leave within their first year. At a cost of €120k per PM, we’re burning €200k+ per year on preventable attrition and lost productivity.”
Cheap: “Our roadmapping process is chaotic”
Expensive: “We commit to delivery dates we miss 70% of the time, resulting in strained customer relationships and sales pushing back on renewals. We’ve lost at least €500k in revenue this year to roadmap credibility issues.”
See the difference?
The first version describes a problem. It’s true, it’s there, but it’s not acute.
In one word, it’s dismissible.
The second version describes what it’s costing the company.
And it’s far more than your salary 💡
Only Solve Expensive Problems
By this I don’t mean “try to crowbar any minute annoyance into a 200k problem”. You can try, but the thinner your business case is today, the more scrutiny the next one will be under.
Done right, framing your Product Ops problems in terms of missed opportunities, sunk cost, or time sinks actually helps you focus on your biggest levers. Because once you start honing that muscle and you start thinking in outcome-first terms, you’ll quickly realise that not all organisational problems are worth your time.
Your goal is to focus your finite energy on what will make the biggest difference. In order to do that, try to answer the following questions:
Where are decisions being made poorly or slowly? Are teams building features without talking to customers? Are interdependencies constantly surprising people? Is every decision escalated because there’s no clear framework for who decides what?
Where is the organization burning money on preventable issues? Failed experiments that were obviously doomed. Features nobody uses because there was no discovery. Attrition because the PM experience is terrible. Technical debt because teams never have time to pay it down.
What’s the gap between where leadership wants the organization to be and where it actually is? They want to be data-driven but PMs can’t access data. They want to be customer-centric but there’s no systematic way to collect feedback. They want teams to be autonomous but every decision requires three layers of approval.
What are teams spending time on that they shouldn’t have to? Not “what’s inefficient” but “what’s actively wasting hours every week?” Meetings that could be async updates. Manually creating reports that could be automated. Hunting for information that should be centralised.
These questions will lead you to expensive problems. And remember - expensive problems get budget.
Working Backwards
I know that some of you might think that you don’t have time for this. Or that you can’t put a monetary value on what’s going on in your company.
And look, I get it. I’ve been a team of one before, and it can really suck big time. You’re probably drowning. You’re fighting fires while new fires are being dumped on your doorstep. You’re barely keeping up with the constant stream of requests and emergencies. And if you had the time and space and mental capacity to build solid business cases, then sure, that’d be wonderful. But you don’t, so you can’t.
But here’s the thing: That’s exactly why you need to do this work.
Because if you can’t articulate your value, you’ll always be underwater. You’ll always be understaffed and under-resourced. You’ll always be fighting for scraps.
The work of building a business case is strategic Product Operations work. It’s arguably the most important operations work you can do, because it creates the conditions for everything else to succeed.
So start small. Pick one problem. Quantify it. Build a case. Get the win. Then do it again.
Here’s something you can do tomorrow:
Pick 2-3 of your biggest concerns (you already know what they are) and work backwards:
If we solved this, what would change?
How would we measure that change?
What’s the estimate of value created or saved?
What resources would we need to solve it?
And then - and only then - do you talk about budget and headcount.
Because now you’re not asking for resources to “do operations.” You’re asking for resources to solve a specific, expensive problem. You’re making an investment case - not a support request.
The Necessary Mindset Shift
If you’re in Product Ops, Design Ops, Research Ops, or any other operational role, your job isn’t to “support” teams. It’s to identify the systemic bottlenecks costing the company time and money, and fix them.
That’s not a semantic difference. It’s a fundamental shift in how you think about what you do.
I’ve been talking and writing about Product Operations for over five years now. And in the beginning there was a lot of buzz. But there was also a lot of “so what” - especially from executives who viewed what I did as a nice to have.
Honestly, it took me a long time to understand that that was partly my fault. It might sound harsh, but the way I spoke about what I brought to the table set the tone for every conversation after it. And I’d often leave those challenging conversations feeling absolutely astounded - “How can they dismiss what I do when it’s so obviously a good thing?”
But something being “a good idea” isn’t nearly good enough. And I think a lot of folks in enabling roles resist that reality, because we’d like to live in a world where making each other’s lives easier and more meaningful is enough for someone to sign a check.
But I think this framing does us a disservice. Because even though we might strongly identify with the “helper” or “shepherd” persona, we’re much more than that.
We’re not a service function. We’re capability builders. We’re not there to make people’s lives easier (though that’s a nice side effect). We’re there to make the business more effective at achieving its goals.
And when we start framing our work that way - when we talk about outcomes instead of activities, when we quantify impact instead of describing improvements, when we connect our hard work directly to business objectives - that’s when budget stops being a fight.
And that’s how we ensure our role never lands on the chopping block.
I’m giving the closing keynote at Design Ops London on March 13th about exactly this: what it takes for operational roles to stop being optional. If this article resonated with you, consider joining. Use code ANTONIA100 at checkout to save £100