Your team is a cost line. Change that.

I've walked a lot of product teams through their own numbers, and the same thing keeps falling out: something like 80% of the team's time is going into a feature that maybe 5% of the users touch.

Nobody decided that. It accumulates. Something ships, it gets complicated, it generates bugs, the bugs generate fixes, the fixes generate more surface area, and a few years later the majority of your team's week belongs to a thing almost nobody opens. You can't see it while it's happening, because everything on the list looks like real work. It only shows up when you put a dollar figure next to each item.

Most product managers I meet have never done that. They can tell you their roadmap, their velocity, their activation rate, their NPS. Ask what the feature set earns against what it costs and you get a shrug, and I think that's a real mistake.

The math being done about you, without you

Say your product brings in a million a year. Your team – you, the engineers, QA, plus the tooling, AWS, the AI subscriptions, the token spend, the security testing software, all of it – runs about four hundred thousand. That's 40% of the top line going to your group, before whatever other overhead the company carries.

Whether or not you've ever done that arithmetic, someone upstairs has done a version of it. And their version is missing the numerator.

They know what people cost. Payroll is easy, it arrives every two weeks with a number attached. What they usually don't know is what your specific feature set contributes, because revenue rarely gets attributed that finely. So the default picture in the room where budgets get decided is one where your team is a cost with no matching line for what it brings in.

I've been in a lot of companies, and product almost always sits in the middle of a big organizational sandwich. From up top, everybody below kind of looks the same. That isn't malice – nobody at that altitude is sitting there thinking about which individual or which team contributed what, because the resolution just isn't there from where they're standing. You're the one with the resolution. If you don't supply it, the picture stays flat.

You already know how to do this

My undergrad was religious studies and poetry, so let me be clear that I'm not the guy you want building your financial model. That's fine. Nobody's asking you to be an accountant.

You prioritize. You've been doing it your entire career. You weigh reach against effort against impact, you argue about what goes first, you kill things that don't earn their slot. A P&L is that same exercise with the unit swapped – dollars in and dollars out instead of story points and reach scores. You're not learning finance. You're changing the denominator on a skill you already have.

That reframe is what gets people over the hump, because "learn accounting" sounds like a career change and "prioritize in dollars" sounds like a Tuesday.

Getting clean numbers is genuinely hard, especially in a larger business. Maybe you own one feature inside a much larger product and revenue never gets sliced that thin. Maybe you can't see what your team actually costs. Do it anyway, roughly. Ask around, estimate, build a range you'd be willing to defend in a hallway conversation, and then carry it in your head. A rough number you can explain beats a precise number nobody has.

What it actually buys you

Not a spreadsheet. The ability to advocate for your team, which is a large part of this job whether or not anyone wrote it into your job description.

If you can represent the P&L of your feature set, you are much less likely to be in the next round of layoffs. I want to be careful there, because plenty of layoffs have nothing to do with what a team was worth and I'm not going to pretend the people caught in those should have run better numbers. But where the decision does come down to a judgment call, having the numbers is the difference between being a line item and being a case. Your resources are less likely to get cut, too. The fight for tooling and software and support services gets a lot shorter. And when someone on your team wants to go to a conference, you have an argument that isn't "it would be good for morale" – you have one that ties their development to the bottom line, and that argument wins in rooms where the other one doesn't.

The second thing it does is quieter, and over time I think it matters more: it forces you to evaluate the return on everything you ship.

Take a ten-feature product, break it apart, and put a rough P&L against each piece. Then measure the usage. That's where the 80/5 problem surfaces, and once you can see it you can move the team's time toward work that actually pays. That protects their jobs and yours, it grows the company, and it makes all of you more money.

It also takes better care of your users, which is the part I didn't expect the first time I watched it happen. Follow the money and you end up following revealed preference – not what people told you in a survey, but what they actually open, use, and renew. Investing where the behavior already is turns out to be both the profitable move and the kind one.

P&L has a reputation as somebody else's job. Accounting's. The COO's. Finance, down the hall, with the good coffee. I'd push back on that. Learn how it works, run the math for your product and your feature set and your team, even if the numbers are estimates and even if nobody asked you for them.

Somebody is going to tell the story of what your team is worth. It should be you.