Why a Product Manager in an Ad Network Is a Commercial Role

If your ad network has a product manager, chances are they sit in the tech department. Their day is backlog prioritization, the roadmap, Jira tickets, and calls with engineering. At the planning meeting you see how many tasks went to release, and it all looks like progress.

I spent about four years as a product manager in adtech, and I can tell you this is the most boring part of the role. Anyone can do it, and an AI agent now does it better. It doesn't explain why a company needs a product manager at all. It also doesn't answer the question a CEO actually cares about: why is turnover growing slower than expected, given how much we release?

The interesting part of the role exists. It just lives somewhere else.

The Product Manager Owns Core Metrics

I've been lucky to work in very different setups: a company with well-oiled processes, a company with no processes at all, and one where the process mattered more than the result. Almost everywhere the same thing repeated. The product manager was part of the technical department. You know exactly where your ticket is right now, much better than you know what should be written in it before it goes to development.

The reason is easy to see. Everything is built so the development conveyor never stands idle, so the focus inevitably shifts to keeping the resource busy. That's convenient for a CTO. A network owner should look at it from the other side: you're paying someone whose main output is measured by engineers' utilization.

A product manager should focus on the company's core metrics. For an ad network that means the number of active advertisers, activation rate, LTV, average check, retention, and churn. All of them come down to money in the end.

Which raises a question: should a product manager be part of the tech department if their decisions affect turnover? In my view, no. It's a commercial role. A PM's ideas, or hypotheses, should deliver turnover growth, advertiser retention, and a higher average check. Prioritization, roadmap, Jira, and dailies matter, but they're secondary. Turnover should be the first line in the role description.

Then everything falls into place. You bring an idea that makes money, implement it, and watch the numbers grow. The PM has the influence and resources to do that, and the company has a person accountable for results, not for the speed of the conveyor.

What's left is the small part: where do you find those ideas?

Where Ideas Come From and Who Decides Which Matter

Finding them is fairly simple, because they always come from client problems. Talk to clients and look for a pattern in what they say. Then check it quantitatively: for which segment, and for how many advertisers, is this problem real? Are they ready to use a solution and raise their budgets, and by how much?

You end up with an audience defined by clear criteria: how many advertisers, and how much they spend. Multiply their spend by the percentage they'd be willing to add, and you have a benchmark for turnover growth. Add the cost of implementation and calculate payback. That's your defense in front of a stakeholder. And in an ad network, the stakeholder is most often you.

The key point is that the problem is found in a conversation with the end client, whether that's an advertiser, a publisher, or an internal customer. A problem is whatever stops the client from reaching their goals. If your platform helps them do it faster and more profitably, they see value and stay.

But we often decide for the client what their problem is. We rely on our own opinion, on what account managers say, on what competitors already have, or, very current, on a deep LLM research run over many tokens that hands us ready-made solutions.

I've seen many built features that nobody used afterwards. We had to invent ways to promote them just so clients would try them, and often they tried once. If we had talked to advertisers beforehand, it would have turned out this wasn't what stopped them from spending.

The opposite happens too. In one DSP, city and region targeting sat in the admin panel for years. The belief was that letting advertisers narrow their own audience would cut revenue. It was an internal conviction that had never been tested with advertisers. We ran a survey: 15% of the active base responded, and 89% finished it. Demand was massive and concentrated in the same geos that brought the network most of its revenue. After launch, LTV of campaigns with geo-targeting grew by 270%. The full story is in the geo-targeting case study.

Only the client decides what is a problem for them. It never happens for them, inside your organization. You have to step outside it and talk to the client.

Metrics as a Diagnostic, Not a Target

We're used to the idea that a high temperature or a sore throat means you need a doctor who will find the source. Core metrics work the same way: they show where it hurts. Lots of registrations but no campaign launches. Campaigns stopping after a week of activity. Average spend unchanged for a whole year. That's a marked-out territory where research should begin, not a task to close with a nice-looking number.

In that situation I segment advertisers by spend, vertical, and pricing model. I pull as much as I can from internal data on the formats, countries, and targets they run, so I understand the client's profile before the first conversation.

For the conversation itself I prepare a goal and a list of questions. Say the goal is to learn why advertisers don't activate after registration: every question is built around it. Then I go through the list with advertisers, at least ten in one segment, to see a stable pattern and pull out a few recurring reasons. I test those reasons on a larger group of similar advertisers, usually through surveys, and where the tooling exists, through experiments in the interface. When there's enough data for statistical significance, I calculate the financial efficiency of the solution and bring it to the stakeholder. I showed this mechanic on a real case in another article.

The scale of a feature can be small while the effect is visible. When we let advertisers set a dedicated bid for a zone instead of blocking it, about 2% of campaigns used it. Those campaigns generated 3 to 5% of platform revenue, and the total incremental revenue came to around 4.7%. Numbers like that come from a problem found in a conversation with a client. Only after that does it land in Jira.

After development there's one more layer: communication with marketing and sales. They need to understand the essence of the solution and how it removes the client's problem that was keeping them from spending more. Then advertisers use the feature as intended, and the chances of success are higher.

I'm confident in this approach. It has proven itself more than once and produced results you can see in turnover.

Two Questions to Ask Your Product Manager

If you want to check what kind of role you've actually built, ask two questions. Which core metric moved after your last release? How many advertisers did you talk to last quarter? If the answers are about the number of closed tasks and conversations only with engineering, the role is technical, and nobody has given it the job of making money.

If you're facing advertiser churn, weak activation, or similar challenges, let's talk about how to solve them.