Why I'm writing about this
About 6 months ago, my product almost got dismantled.
The org was restructuring. What used to be a funded, high-priority area in integrations was suddenly no longer hot. And my product was on the list. Kill list.
To save it, I had to go back to basics: what does this product actually cost in total? And how do we cover that cost?
I had to design two things at once.
A strategy to cover the "keep the lights on" cost. Pure maintenance, nothing new being built.
And a strategy to cover the cost of innovation, so we could eventually grow again.
That pressure made me get very good, very fast at understanding TCO.
Because if I got the numbers wrong, my budget would go negative. Resources would be reallocated. And my reputation as a PM would take the hit.
What Is TCO and Why Internal PMs Ignore It
TCO stands for Total Cost of Ownership.
It's the full picture of what a product costs to exist: build it, run it, maintain it, keep the lights on.
Most internal PMs don't think about this. And it makes sense. When you're not selling to external customers, "cost" feels like someone else's problem.
But here's the reframe: your internal product is a business.
Think of it this way. Imagine you run a small ice cream shop with three employees. Someone proposes bringing in a new HR system. It costs more per year than the revenue your shop generates.
Would you keep it?
Of course not. But in large organizations, these decisions get murky. They get delegated. Eventually, they land on you.
The PMs who thrive are the ones who already have the answer ready, because they've done the math.
TCO Components
Here's how I break it down. Two buckets: people, and everything else.
People Costs
Usually the biggest line item and the easiest to underestimate.
→ Product Manager
→ Delivery Manager
→ Developers (senior and junior)
→ Operations Manager
→ QA / Tester
Don't just count headcount. Factor in location. A senior developer in Germany costs very differently than the same role in India. Both are valid, but you need to know the actual number.
Software & Infrastructure
→ Infrastructure
→ Operations
→ Software and tool licenses
These tend to be smaller, but they're easy to forget until an invoice shows up.
Hidden Costs
This is where most PMs leave money on the table.
→ Acquisition cost: what it takes to onboard new users or teams
→ Downtime cost: what it costs the business when your product is unavailable
Downtime is worth calculating seriously. If 50 users lose access for a few hours a week, at an average hourly rate, it adds up fast. (If you read the technical debt issue, this kind of math will feel familiar.)
An Example Breakdown
To make this concrete, here's what a typical internal product team might cost, based on market estimates for roles split across Germany and India.
This is the kind of model I built for my own product. The specific numbers will differ for you, but the structure is what matters.
Keep the Lights On (KTLO)
Estimated grand total: ~€410,000/year.
With 3,000 users, that's roughly €137/user/year all-in.
Strip out the innovation budget and you're at around €87/user/year. Just the cost of keeping the product alive.
Plug in your actual salaries and team size, and you'll have a number you can walk into any leadership conversation with.
Recovery Strategies: How to Cover the Cost
Knowing your TCO is step one. Step two is figuring out how to recover it.
I covered different pricing approaches in a previous issue HERE.
Here are four models worth knowing. I'll start with the one that actually worked for me.
Model 1: Flat Fee per User (KTLO)
The simplest baseline. You divide your KTLO cost by the number of users and charge a fixed annual rate.
At €87/user in the example above, 3,000 users covers the core running costs.
Before you think about growing the product, you need to know this number is secured.
Model 2: Flat Fee per User (KTLO) + Chargeback for Innovation
This is my actual strategy, and it was two-fold.
Users pay the flat KTLO rate. Then separately, the teams that benefit from new features get charged a share of the innovation budget.
For me, this varied year to year. Some years we were in pure KTLO mode. Other years, we received innovation funding because we could clearly show what we were building, for whom, and why it was worth it.
The key shift: you stop asking for budget and start presenting a business case. That's a completely different conversation.
Model 3: Usage-Based (Flat Rate)
Instead of charging per user, you charge per unit of consumption. That could be API calls, transactions processed, integrations running, or whatever makes sense for your product.
This model works well when usage varies widely across teams. A team using the product heavily pays more than a team that barely touches it. Fairer, but it requires you to have usage tracking in place.
Model 4: Tiered Usage
The same idea as Model 3, but with volume bands. The more a team consumes, the lower their per-unit rate.
Think of it like a phone plan. Light users pay a higher rate per call. Heavy users get a discount because they're driving the volume that justifies the product's existence.
This is the most complex model to administer, but it's also the most honest reflection of value delivered. If a team is sending millions of transactions through your integration layer, they should be contributing more to the cost. And they'll accept that logic, because the numbers tell the story.
Download the TCO Calculator
I built a free Excel file so you can plug in your own numbers.
It includes:
→ A full TCO breakdown with your team's actual costs
→ All four recovery models with formulas that update automatically
→ A comparison table to help you pick the right model for your situation
[Download the TCO Calculator HERE]
All the blue cells are your inputs. Everything else calculates for you.
