Every product manager loves to talk about strategy, discovery, and customer value. But there’s one less glamorous skill that quietly determines whether your product strategy ever sees the light of day:

Understanding how your work gets funded.

And since it’s Q4, it’s the perfect time to talk about budget planning.

Yes, budgets can sound boring. But they’re the thing that can kill or enable any strategy.

Many great product ideas die not because of customer indifference. They die because of budget friction.

Most PMs think of “the budget” as one big pot of money. But not all money is created equal.

When you propose an initiative, it matters which bucket the money comes from, and who controls that bucket.

A lot of product work gets stuck not because the idea is weak, but because it’s framed wrong. It doesn’t fit how the business actually classifies and approves spending.

Every business classifies spending in one of two buckets:

Each is a different type of spend requiring different levels of approval.

Not knowing the difference can derail your ability to execute your product plans. Especially if you’re in a product leadership role, or aspire to be in one.

For example, let’s say you propose a new internal tool to improve product development efficiency.

If you get that classification wrong, you might ask the wrong person, from the wrong budget, at the wrong time — and get a fast “no.”

Most of the daily work you do in Product Management is OpEx work. It comes out of the operating budget — the money that funds day-to-day operations.

That’s because most PMs and product teams are working on growing and maintaining existing products. The PMs, designers, and engineers are budgeted for. So, the exercise is largely about ensuring you’re working on the most impactful stuff at any given time.

All that work is coming out of OpEx. In other words, you’re trying to ensure you’re getting the biggest bang for the buck out of current operating spend.

Think of it this way:

Under OpEx, you, the designers, and the engineers are already budgeted for. The total cost is, say, $1M, or $38.5K per 2-week sprint.

So the question for you becomes what product work should you prioritize that gives the max return for that $38.5K per sprint spend?

But sometimes, your projects touch the capital budget (CapEx) — the money used for long-term investments. For example:

Knowing the difference helps you:

This isn’t about becoming a financial analyst. It’s about building enough financial fluency to avoid unforced errors and make your strategy executable.

In today’s essay, I’m going to give you a crash course on CapEx and OpEx, and provide examples of how you can use them in your product work.

The capital budget funds big, durable investments — things that deliver value over multiple years.

Common examples:

If it lasts more than a year and delivers value over time, Finance may label it as CapEx.

Since CapEx is about long-term investment, the money usually comes from:

Because the amounts are often larger, these decisions require senior executive or board approval. That means more time, more scrutiny, and more documentation for approvals.

OpEx covers the ongoing costs of running the business. The stuff you’re most familiar with. Think:

OpEx is usually funded by revenue — the money the business earns each month.

The exception to this is when your startup is not yet profitable and is being funded by venture capital, debt, or other investment until the business is sustainable. In this case, the board will allocate some portion of that investment toward OpEx to fund company operations.

Because OpEx is recurring, it’s tightly monitored, often reviewed quarterly or even monthly. But it’s also more flexible and easier to reallocate in smaller chunks. For example, your VP can decide to allocate T&E budget to training without requiring approvals from Finance.

Let’s make this real.

✅ OpEx.

Most day-to-day PM work — fixing bugs, improving UX, refining features — comes from OpEx. You’re optimizing how that budget gets used, not creating a new one.

The only time this requires a separate budget request is when you’re advocating for additional resources. For example:

Otherwise, the daily work you’re doing here is ensuring the existing OpEx is being spent wisely — on the things that will give you the biggest bang for the buck given the existing spend.

✅ OpEx.

Salaries are ongoing costs. Adding a QA or PM headcount hits the operating budget and will come out of the team’s headcount or departmental budget.

✅ OpEx.

Hiring a UX research firm for a 4-week project? That’s a short-term vendor expense.

If it’s already budgeted for, it likely only needs the approval of the department head.

If not budgeted for, it’s an OpEx budget request.

✅ OpEx (99% of the time).

Subscriptions to Mixpanel, Maze, Kissmetrics, Figma, etc. are recurring operational costs. (Almost all SaaS tools fall here.)

There are exceptions. For example, you want to purchase a major internal analytics platform that requires a big upfront investment, but will improve decision-making for years. That may qualify as CapEx with senior executive approval.

🚧 CapEx.

Redesigning your entire mobile app or rebuilding a core system that will take months or years, but create multi-year value?

⚖️ Mixed.

You want to move the company from an old CRM to a new vendor. It will require a big data migration, custom integrations, and a multi-year contract.

The upfront migration and integration may be CapEx.
The ongoing license and maintenance fees? OpEx.

Finance might decide to split the costs across both.

🚀 CapEx. Engineering spends months building a workflow automation tool for operations.

It saves time for years. That’s long-term value, so Finance may mark it as CapEx.

Understanding these distinctions helps you plan smarter, pitch better, and execute faster.

This is one of the quiet superpowers of senior product leaders — the ability to connect strategy to how the business actually funds execution.

Once you start speaking in budget terms, you stop sounding like someone asking for money and start sounding like someone who knows how to make money work for the product.

That’s all this Saturday.

Have a joyful week, and, if you can, make it joyful for someone else too.

cheers,
shardul

Shardul Mehta
I ❤️ product managers.

​Follow me on LinkedIn
​​Book a Free 1:1 Call With Me