The product team's responsibility for revenue

Most product teams have never read a P&L statement. They can tell you about activation rates, task completion times, NPS trends, and sprint velocity. But ask them what their product contributed to revenue last quarter, and you will get a pause. Then a redirect. Then something about how revenue is really a sales and marketing question.

It has been a sales and marketing question for a long time. That is changing.

The comfortable distance

For years, product teams operated with implicit permission to stay upstream of money. Build the thing. Ship the thing. Measure whether people liked the thing. Then hand it to someone else to figure out whether the thing made money. Designers design. Engineers build. Product managers prioritise. Sales sells. Revenue belongs to the people whose bonus depends on it.

But that arrangement only works when the company can afford the gap between what product builds and what the business needs commercially. Fewer companies can afford that gap now.

I call this the accountability shift. The moment when product teams move from being measured on outputs (did you ship it?) and satisfaction (did users like it?) to being measured on outcomes (did it make money?). It sounds like a subtle change in language. It is a structural change in identity.

At Adobe, I lived inside the comfortable distance for longer than I should have. The enterprise product team I was part of operated in a protected space. We had user research budgets, design sprints, and organisational respect. Our satisfaction scores were strong. But we had almost no visibility into how the product actually performed commercially. Revenue conversations happened in different rooms, with different people, using different language. Nobody walked into our sprint review and said: this feature you shipped last quarter, here is what it contributed to the bottom line.

Then a reorg changed everything. Product leads were suddenly expected to sit in quarterly business reviews, to present not just what they shipped but what it earned. The first time I sat in one of those reviews and watched a product lead struggle to explain why a feature that scored brilliantly in usability testing had produced no measurable lift in expansion revenue, I understood something I had been avoiding. We had been building for users without understanding the business those users sat inside.

That is the most expensive form of empathy a product team can practise.

The chef who sees the bill

Think of a chef who has spent fifteen years perfecting her craft. Sourcing the best ingredients, refining techniques, earning praise from critics and diners. But she has never once looked at the restaurant's finances. She does not know the margin on her signature dish. She does not know that the appetiser she considers beneath her accounts for forty percent of the profit, or that the tasting menu she spent six months developing costs more to prepare than customers will ever pay.

Now imagine someone hands her the keys and says: run the restaurant.

That is roughly what is happening to product teams across the industry right now. The GM model, where product leaders are expected to operate like general managers who own the full commercial picture, is moving from a concept people discuss at conferences to an expectation written into job descriptions. But most product leaders were trained as chefs. They know craft. They know users. They know quality. They were never trained to read the bill.

The moment the question changed

At Freshworks, I watched the question change in real time. For years, the metric that mattered after a release was adoption. Did users engage with the new feature? Did support tickets go down? Did the satisfaction score hold? These were reasonable questions. They were also insufficient ones.

But the shift did not arrive as a grand strategic announcement. It arrived as a single question in a product review that nobody had asked before: did it move the number?

Not the NPS number. Not the adoption number. The revenue number.

The room handled it the way rooms always handle uncomfortable questions. People looked at their laptops. Someone offered a vague answer about indirect impact. The product lead talked about long-term value creation, which is what product people say when they do not have a short-term answer.

But the question did not go away. It came back the next month, and the month after that. And slowly, the team started building differently. Not worse. Differently. Features started getting evaluated not just on whether users would adopt them, but on whether they sat in a part of the product that connected to expansion, retention, or conversion. The team started caring about packaging, about where features landed in the pricing tier, about whether a capability would pull a customer from a free plan to a paid one or from a mid-tier to an enterprise contract.

I watched a designer on that team, someone whose instincts were impeccable, struggle with this for weeks. She kept saying: I did not get into product design to think about pricing tiers. And she was right. She didn't. But the product she was designing existed inside a business, and the business needed her to understand that the best feature in the world is worthless if it lives in a tier nobody pays for.

Product teams that don't understand revenue don't understand their product. They understand the experience. They understand the user. But they don't understand the thing that determines whether the experience and the user continue to exist next year.

The GM instinct

The shift I am describing is not about turning product people into salespeople. It is about developing what I call the GM instinct: the ability to hold craft and commerce in your head at the same time.

The GM instinct means knowing that the most important product metric is the one that appears on the P&L. Not because revenue is more important than user experience. But because revenue is the condition that allows user experience to continue. A product that delights users and loses money is a hobby. Most of us are building businesses, whether we talk about it that way or not.

But this instinct does not come naturally to people trained in user-centred design, and it should not. The discomfort product people feel when asked to think about revenue is healthy. The danger is not caring about revenue. The danger is caring about revenue to the exclusion of everything else, which is what sales-led organisations already do.

The product team is the only group in most organisations that can see both the user's problem and the business model simultaneously. Sales sees the deal. Marketing sees the funnel. Finance sees the spreadsheet. Product sees the moment where a person encounters a feature and decides whether it is worth paying for. That intersection is where revenue actually lives. Not in the contract. In the product.

When the kitchen runs the restaurant

The accountability shift is uncomfortable. It should be. Product people who resist revenue accountability are not wrong to feel uneasy. They are protecting something valuable: the instinct to build for the person using the product, not just the person paying for it.

But the best product leaders I have worked with hold both. They care about the craft and they read the P&L. They build beautiful things that also keep the lights on.

There is a version of the chef story that ends well. She takes the keys. She learns the numbers. She discovers that the appetiser she dismissed is the dish that funds the kitchen. She does not stop caring about the tasting menu. She just learns to care about the restaurant too.

That is not a compromise. That is the whole job.