The job description nobody sent you

There is a version of product management that most people entering the field were trained for, and a version that is quietly becoming the job. The gap between them is widening. But most PMs are discovering the new version not through a job description or a promotion conversation. They're discovering it through a gradually increasing list of meetings they weren't in two years ago.

The revenue review. The pricing discussion. The conversation about whether a particular segment is worth the cost to serve. The board question about unit economics that gets forwarded to the product team because nobody else in the room had a credible answer.

This is why the shift matters, and it's worth being direct about it before getting into how it plays out.

Product management was designed, in its modern form, for a world where the product team's job was to ship. Shipping was the output. Revenue was someone else's problem. The PM owned the roadmap. The commercial team owned the number. Both sides were evaluated on their own lane, and the two lanes ran in parallel, occasionally merging at a QBR and then diverging again until the next one.

That model made sense when software was sold annually, in large contracts, by sales teams who owned the customer relationship from first call to renewal. The product team's job was to make something worth selling. But selling it was a different department's problem.

The model broke down as distribution shifted to self-serve, as products became the primary channel for their own growth, and as the line between what the product does and what the business earns became impossible to separate cleanly.

A product that fails to convert a free user isn't a UX problem. It's a revenue problem. A feature that increases engagement but doesn't contribute to retention isn't a success metric. It's a cost. A roadmap that doesn't account for what it costs to serve a particular segment isn't a product strategy. It's a wish list with a due date.

The PM who understands those distinctions is operating as a general manager. But the PM who doesn't is operating as a well-intentioned feature factory, and the organisations that have figured this out are starting to staff and evaluate accordingly.

I've worked with two PMs in the past year who are navigating this transition, in very different ways.

The first one resisted it. She'd been in product for eight years, was genuinely excellent at her craft, and felt that being pulled into commercial conversations was a distraction from the work that actually mattered. Every time a revenue question landed in her team's direction, she redirected it. That's a commercial question, she'd say. She wasn't wrong. But she was losing influence every time she said it, because the organisation was starting to evaluate her team on commercial outcomes whether she accepted the brief or not. Being right about the boundaries of your job description is a strange way to lose a seat at the table.

The second one leaned into it. He had no formal background in finance or commercial strategy, but he started asking a specific question in every roadmap conversation: what does it cost us if this doesn't work, and who bears that cost? Not to become an accountant. But to understand which decisions had commercial stakes and which ones were purely craft decisions. Over eighteen months, he became the person leadership called when a pricing conversation needed someone who understood how users would respond to it. Not because he was the best commercial thinker in the room. Because he was the only person who knew both sides of the equation.

The difference between them wasn't skill. It was appetite for scope.

The PM-as-GM model asks things of the role that the traditional version didn't.

It asks for ownership of the revenue contribution, not just the feature set. Which means understanding CAC and LTV well enough to know whether the product decisions being made are building toward a sustainable unit, not just a growing one.

It asks for accountability on cost, not just velocity. Which means knowing what it costs to build and maintain what the team is building, and whether the value being created justifies that cost. Most PMs have never been asked to think this way. But the ones being asked now are finding it uncomfortable and clarifying in equal measure.

And it asks for a point of view on profit, not just growth. This is the hardest shift. Growth has been the dominant language of product thinking for a decade. But profitable growth is a different question, and it requires tradeoffs that growth thinking is specifically designed to defer.

None of this requires a PM to become a CFO. But it does require caring about the business at a level of specificity that most product training doesn't prepare people for.

The title of General Manager is being used loosely in this conversation. It's worth being precise about what it actually means.

A GM doesn't just run a function. They run a business. They're accountable for the inputs and the outputs. They hold a P&L. Most PMs are not in that position, and most organisations aren't asking them to be. But the direction of travel is clear, and the gap between where PMs are being asked to operate and where most of them were trained to operate is closing faster than most people expected.

The PMs who will have the most influence over the next few years are the ones who can speak the full language of the business their product operates in. Not just the language of users and features, which they already speak fluently. But the language of revenue, cost, and the relationship between them.

That's a learnable set of skills. It just requires accepting that learning them is part of the job.

The description didn't arrive in your inbox with the rest of the onboarding materials. But it's the job.