I have started this blog posting several times, and have been diverted each time. It is a complex topic, and it almost seems like heresy, but I believe it needs to be said.

There has been much said on the roles of Product Management, and Product Marketing. There are firms who have well developed frameworks, and extensive training to help you get to a “good” state. In particular, I am familiar with the Pragmatic Marketing work, and the Blackblot BOK*. Both have similarities, and both are profoundly helpful. But…

The first But…

Perhaps for me, it goes back to when I started in product management. There really wasn’t a BOK to draw upon. There was literature, but the vast majority in the pre-Google days was centered on packaged consumer goods, and product managers were much more like General Managers of a business, or business unit (today, they would be better described as “Brand Managers”). Enter the tech world. I was a new product manager, climbing a steep curve. I had to know my markets. Cold. I had to know the dynamics of my business. Cold. I had to know my product inside and out. I had to know enough of the technology to talk to the engineers (hint: It was electron microscopy. I.e. lots of physics, quantum mechanics, E&M etc). I had to be the point of sales enablement. There was no segmentation of the role. No partitioning. No delegation of the responsibility. It was just me. Sure, I had peers, but they all had businesses to run. We all learned together, and we all eeked out path forward.

So, when I see a framework where the role is partitioned, I am immediately skeptical. Not that it is a bad idea. Lord knows that the all in one product manager is a tough place to be. But there is comfort with having all the bits and pieces within grasp. When I see a recommendation to split the role into two, I worry about how each half will work together to make the whole picture.

The second But…

Can you be successful at only half of the role? This is a question that really bends my mind. To me, the Technical Product Manager (or product manager), whose role is mostly limited to the bottom-left portion of the Pragmatic Framework (below the descriptive bar, to the left of Programs) is really not a product manager. Sure there are some meaty tasks, knowing the competitive landscape, assessing the technology, managing the roadmap, but it is commonly held that this role delivers and hands off a product to the product marketing manager (or product marketer), who then owns and drives the business aspects (GTM, positioning, pricing, promotion, sales enablement etc.)

The theory is that the product marketer will hand down to the product manager the input from the market, direct VoC feedback, a semi-prioritized set of features. In return the product manager then cranks out the detailed product development plan and cycle. A pretty thankless job, if you ask me.

The product marketing manager then is responsible for all the interesting parts of the job. The marketing component, including win/loss, Go to Market strategy, distribution, pricing, business case building, the market problems, and much more.

Blackblot breaks this down a little differently, essentially calling the product marketer as handling all the inbound data flows, processing and passing them to the product manager, who creates requirements, and drives the development process.

Either model leaves me thinking that the parties are not whole.

If the product marketer is completely disconnected from the nuts and bolts of the development process, their understanding of core competencies is incomplete, as well as their understanding of the team’s capacity, capabilities, and past performance. This leads to some pretty wild miscommunications and mis-set expectations of deliverables. I have often seen this manifest itself in promising more than can be achieved, and then being stunned/angry/indignant when plans go awry.

On the other side of the fence, if the product manager is insulated from the business and marketing aspects of the organization and product, then they are like the boy in the bubble. This leads to a disconnect, disenchantment, and disfranchisement.

Compounding this, is the fact that the two roles will often report into two different organizations (marketing, and engineering are common), with different comp plans, and most importantly incompatible objectives set. Thus while their success is often so intertwined, they are paid on such orthogonal metrics, that neither will be inclined to help the other be successful

The way forward:

It is my belief that there is plenty of work to justify two different people for these roles. But to manage towards success, it is critical that they are not insular. Your product manager needs to have some skin in the game on the inbound marketing-like activities. Likewise, the product marketer needs to have some shared experiences in the trenches. This helps them understand why their preferred prioritization may not make it into the product plan. Also, it helps them understand the dynamics of the development team, the process, and gives them a fuller view.

Lastly, and this is for a mature organization, I believe that both roles should report to a single leader. Splitting their allegiances to two departments will dilute their mutual goals, and purpose. They both need to have visibility into the other’s objectives, and ideally have some skin in the game. If you have product management and product marketing at odds, you have a truly dysfunctional team.

Summary

To steal a page from Hewlett Packard, “Product Marketing is too important to leave to Marketing” rings true. Yes, it is marketing, but it is really a component of product management, and the goal is to build kick-ass products, that delight customers, are easy to sell, and are widely applicable. The Pragmatic framework offers a great guide, and having the three chief roles they talk to, marketing, product marketing, and product management is important, more crucial is to have all parties on the same page, rowing in the same direction.

To me, that is what defines a great product management organization. Do you have it? What are you doing to get there if not?

The future will bring a post that describes how to develop each role to peak efficiency

—

• BOK = Body of Knowledge