Ad Tech vs. Non Ad Tech Product Management

What are the differences and which type of role is best for you?

Intro and Background

I started my career in product management at an ad tech startup many years ago. When I initially joined, I was the third PM and it was a small team. I had this vague understanding of product management. My idea is that it was a combination of the CEO of the Product, the technical writer, and the “idea guy.” As I learned, none of those were accurate descriptions! This was far before the current product influencer craze had exploded over social media channels, so I learned the only way I could, trial and error, and observing or emulating my product peers. 

At each stop in my product career, my understanding of product management evolved, and I recognized how the size, industry, organizational structure, and company culture affected the nature of the role.

One of the more dramatic shifts I’ve experienced is moving from an ad tech to a non ad tech product management role. In my mind, it is so different from what is traditionally written about in product management, and yet, I haven’t found much content about these differences. I resolved I would one day write a no-nonsense evaluation of the differences between these two types of product management so that others who enter the product field would understand which type of product management category they’d like to work in. 

Here are some of the key aspects to understand the differences between ad tech product management and other types of product management.

Data Availability

You often hear that product managers spend much of their time analyzing quantitative data. This data, when accessible and interpretable, provides lots of insights about your users and customers as well as problems and opportunities in your product. Ad Tech product roles provide quantitative data to make data-based decision-making, but it is only on certain aspects of the business and product. The actual customers are businesses, but the recipients of the product, mostly ads, are the consumers. (This is a different dichotomy than the classic B2B product conflict of customers vs. users, which is a whole other discussion) Data is available, but it more often pertains to how consumers are engaging with your ads, not necessarily how customers are using your product. For example, if you want to know why ACME Co. is showing so many ads, well look at the ad exchange data and you may find interesting signals to indicate why and provide you clues for further investigation and experimentation. But if you want to know how your B2B customers like that fancy dashboard you created to manage their campaigns, you will have a harder time using data. The best data will not be metrics-based, but will likely be sparse qualitative data from customer interviews or meeting milestones, such as QBR’s (Quarterly Business Reviews).

Technical Expertise

Another aspect of ad tech that is different from other types of product roles is that there is a wealth of technical domain expertise that is necessary to be successful in this product role. Advertising technology terminology, acronyms, and technical standards are plentiful, partially because advertising technology products are highly dependent on many other product integrations. This creates the need to have deep expertise in the actual way your products work to be successful as a product manager. Be prepared to read many internal and external technical specifications to build your working knowledge. The complex nature of ad tech products also means that when advertising or revenue performance declines, there will likely be a push to investigate your product by business stakeholders. If I had a nickel for the number of product/engineering investigations I’ve had to lead because there is a “feeling” that something is wrong with your product, I’d be a very rich man. Rarely does this feeling result in finding an actual problem, but the onus is still on the PM to perform the investigation. Naturally, engineering will be reluctant to do so and will have a natural incentive to not look as deeply as necessary, so it is incumbent on the product manager to build a deep functional knowledge of the product to drive the investigation in partnership with engineering.‘

Conferences and Networking

Spending time going to conferences is generally a waste of time for product managers IMHO (I’m speaking of ad tech conferences, not product career conferences). Conferences may serve useful to provide product support to the marketing teams, or even deal support for business development reasons. However, I find in ad tech product management, it is necessary in more senior roles. Your products and initiatives are generally going to rely on many other vendors and frenemies than you care to remember, and having strong relationships with those third parties is going to be important for your success. The ad tech market is extremely fragmented and complex (check out the Luma Landscape), and it's going to be difficult to figure out who you are competing with, who can potentially help you achieve your product goals, and who has some good ideas that can spur innovation in your own company. Conferences are a useful forum to discover these companies and opportunities, and although I wouldn’t spend significant time at conferences, I would try to attend the larger and more significant ones when peers recommend them.

User Experience and your relationship with designers

For better or worse, user experience design generally takes a back seat in ad tech products. The ad creative in the actual ads is critical for performance reasons, but that is creative, not product design. The design of actual products is generally considered an afterthought. Enterprise SaaS products have fully embraced consumer-grade design, but I’ve found Ad Tech products are still far behind this trend. The partnership between product managers and designers is not nearly as strong as it is in consumer products. In the design process, designers are generally not involved early on in the product process, and much of a designer's user and business context is derived from the product team.

Which one is best for you?

These differences in product management are important to understand and can be learned on the job. However, my goal with this article is to educate developing product managers to understand the differences so they can make informed decisions on where they would like to take their careers. One thing to remember is, product management differs widely from each company and industry you work in. If you find you don’t like it, perhaps you only dislike a certain flavor, and you haven’t discovered the version of product management that lights a fire in your soul. If you have any thoughts or perspectives of your own, feel free to leave a comment below or shoot me an email. I’m happy to discuss or debate the points above.