Julian Dunn

I break it down as follows: product marketing's main role in sales enablement is to educate salespeople on the target customers/market segments/buyer personas & needs, etc., how to position value (not benefits or feature/function) for those customers, and provide competitive intelligence (battlecards, training on what to know and what to say, objection handling, etc.) There is also a technical marketing component to it of course, which is training sales engineers (typically) on features & functions and mapping those to buyer and user problems. The rest of it, in my view, is sales enablement's responsibility. Curating and packaging the aforementioned content in a way that is consumable by sales. Training salespeople on all the other mechanics of sales -- BANT, MEDDIC, sales process, sales operations, negotiation skills, objection handling skills, etc. Anything that is a generic skill that a rep would need at any other company similar to ours. In other words: if a rep doesn't have the information they need in order to position the product, handle objections, and articulate value to the buyer, that's on product marketing. If the rep can't find the information when it's around, isn't trained on how to use it, or doesn't have good sales process hygiene around any other aspect of their job, that's on sales enablement.

If you are literally looking to stay in product marketing or marketing (and already have a job in the field) then I would agree with the other posters that an MBA is not going to get you much. However, if you have designs to move into (strategic) product management, start your own company, or something else adjacent to where you currently are, then an MBA can be useful, particularly if you don't have an undergraduate business degree. That said, if you plan to move into product, I would actually say that the ability to work with a delivery team (e.g. engineering) and having the domain expertise / empathy for their world is more important.

As a PMM, I was always conducting my own wide-ranging research about competitors and market dynamics (competitive and market intelligence) and providing this to PM. This included reading a lot of analyst reports, both about our category and adjacent categories, meeting with industry analysts to conduct inquiries on pressing questions of interest, keeping up on industry news, and understanding what trends are likely to impact the product and category. Finally, distilling this down to both proactive recommendations (where I would send unprompted suggestions to the product team) and reactive input (where I would comment on their product proposals and bring in this information) is how I would add value. As a director of PM now, I have come to expect the same of my peers in PMM, as they well know. :-) The PMM's job in this regard is generally to widen the aperture of PM. PM can often get trapped inside a very myopic worldview, where they are only building products for the customers or markets that exist today. In the worst case, PM can become a feature factory, literally taking customer orders for enhancements and just building those. PMM's job is to push PM to expand their horizon. In sum: Adequate PMMs help market horizon one products. Great PMMs help product management build horizon two and horizon three products.

In general, PM KPIs tend to be further down-funnel and PMM KPIs are further up-funnel. PM's KPIs are about utilization / adoption of products or features, including repeat usage ("stickiness" or "MAUs/DAUs"). PMM's KPIs are about clarity & effectiveness of messaging and positioning, which you can measure with metrics like message pull-through on launches, inclusion in analyst reports, progression through stages in the customer's consideration journey particularly the later ones, etc.

It can vary from not-terribly-technical to quite technical. This depends on how complex your product is and how much the nuances of that complexity matter to the user's success with it. As an example, GitHub Actions has sophisticated features like matrix builds for parallelization, required and reusable workflows, and others where the design, down to the structure of the YAML, matters a lot to the end user. But even in Actions, these are corner cases. What's important is that developer product managers not be afraid to dive as deep as necessary into technical details. Now, 95% of the time, do they need to be reviewing engineering design documents with a fine-toothed comb? Largely not, assuming that their partnership with engineering has been going well, and also that engineering has enough empathy about the end-user to make the right call even at a low level of detail.

I've reported into both in my career and the best I can come up with is "it depends". As an overall philosophy, I would generally prefer to report into marketing, because it creates the right level of healthy conflict between the CMO and CPO (Chief Product Officer or SVP Product) that you need in order to develop a good product strategy and go-to-market in tandem. Reporting into product often means you end up just as a support function to product managers and cannot influence strategy. PMs throw items over the wall and see PMMs primarily as launch managers and wonder why they're not "making enough noise". The other advantage of reporting into marketing is that you have significantly more resources and can influence the direction of campaigns. That said, if your marketing organization is dysfunctional and/or not held accountable to revenue/pipeline generation (which does happen a lot, to be honest), then it's going to be a bad time. The other issue in reporting to a marketing organization is that the KPIs of PMM get skewed away from product & feature adoption/usage and towards pipeline.

This is a tough question to answer because it is so situational. For example - I have seen organizations where PM is so immature that it is essentially a project management function. Melissa Perri even uses such an example in her excellent book Escaping the Build Trap! While in Perri's fictional organization, she was able to develop the PMPs into PMs in the end, many companies would opt to try and hire a few true PMs first. Another dimension is mix of seniority which is critical on any team (just like in engineering). If you have a team of all very junior-to-intermediate PMs, you may find that you cannot develop any PMs fast enough into being sufficiently senior & that you need to hire outside. A great Staff+ PM is worth their weight in gold because not only do they generate great results themselves, but they act as an accelerant to the rest of the organization: engineers and designers become both more productive and happier. You also asked about switching folks from other roles in a company into PM (e.g. engineering, sales engineering, customer success, professional services, support, etc.). In my experience, this can work, but moreso at junior to intermediate levels on the PM career ladder. This is because there are a lot of skills that a PM needs to employ that are sometimes not exercised in these other roles. Many such transferees need to be disabused of the notion that PM is just about having a huge wealth of domain knowledge and employing that to "tell people what to do". Even if you can overcome such a barrier and the candidate truly wants to do PM, the compensation gap from where they are coming (particularly if coming from a revenue-oriented role) and perceived demotion may be unsurmountable & you may need to hire from outside.

This is a great question. I've transitioned from PM to PMM and back again, so I can give you my perspective on both. The biggest challenges for anyone moving into PM, whether that be from PMM or other roles, are the following: * deeply understanding the domain; * leading by influence; and * being comfortable with high levels of ambiguity. (And, of course, the ability to make good judgment calls on top of all that.) For PMMs specifically, particularly those without a technical background, the first area is going to be the one that's most challenging. You can't be successful at leading by influence if you don't deeply understand the product & customers and can convey the nuances of these elements to your engineering and design counterparts. Let's be honest: In marketing, you can sometimes get away with hand-waving (PMMs have often done it to cover for product shortcomings!) In PM, this simply won't fly. You can't BS your customers or your R&D teams. For PMs looking to move into PMM: I actually wish this was a more "acceptable" career path, or that PMs could do a stint in PMM and then come back again, because knowing how to position a product and working with the rest of the company to take it to market is an incredibly critical skill that I believe makes product managers better at their jobs. Unfortunately, the current industry perception of PMM is that it's a lesser role than PM. The recent e-book from the Product Marketing Alliance, Product Marketing Misunderstood, essentially states this flat out. It's very difficult to get back into PM once you've made the move to "marketing" which is often perceived as a fluffy department by R&D teams. That being said, Product Marketing Misunderstood holds as its central thesis the notion that the CMO of the future will come from PMM rather than demand generation, which, if it holds water, bodes well for the PM-cum-PMM who wants to rise in their career. Just bear in mind that, as you become more senior as a PMM, you will increasingly need to interface with marketing functions (such as demand generation, events, field marketing, partner marketing) that may not interest you at all. If you're a PM considering making the move into PMM, you should familiarize yourself with all the aspects of marketing (I even have a blog post about this), assess the maturity of those functions at your company if you're planning to make a lateral move, and then decide.

I used to be very much on the side of "PMM should own pricing" but I will now caveat this with a couple considerations. First off, though, I think at a smaller company, say a startup where you're the only PMM, PMM should still own pricing. That's because there's both a strategic ("how should we set our suggested retail prices and package the product?") and tactical ("how much should we allow our reps to discount the product and on what basis?") element to pricing. At smaller companies, I've seen more problems with the latter. Failure to set acceptable discount levels and enforce them with the sales team creates the wrong kind of working relationship with them and leads to a lot of "special" deals that you'll end up having to unwind later when your product is successful. ("What do you mean $EARLY_CUSTOMER from 5 years ago is only paying $5/seat/year? They have 80,000 seats now and we can't raise our prices that dramatically!") At a larger company, my answer is "it depends who is capable of taking a rigorous approach to pricing and packaging" including conducting both quantitative and qualitative research on how products should be priced and packaged (P&P). If this sounds a lot like product management, it is. That doesn't necessarily mean I think P&P should sit under PM, however. P&P is such a specialized skillset that works in a domain so distinct from traditional PM that I've started to see companies start to create VP/Senior Director of Pricing roles. These roles often roll up to a Chief Product Officer (CPO), but not always; particularly with the rise of growth marketing and the renewed hype around product-led growth (PLG), sometimes it's more effective for these folks to sit in marketing. My default choice would be to put P&P in product marketing, because experimenting with packaging and pricing is a job better left to the go-to-market side of the house.

My current product team consists of four direct reports who are all senior product managers. My job as a director is to create distinct areas of responsibility (AoRs) for these PMs to deeply understand customer problems, conduct discovery and research with their design and engineering (tech lead) peers, scope and propose initiatives, and then greenlight them to go on the roadmap only when we have sufficiently reduced the level of ambiguity that we know how such initiatives will move the needle on our product. I measure PM success not only by the level of adoption of their initiatives but also how well they work cross-functionally to orchestrate their work. As the scope of a PM's responsibilities grow (i.e., they rise through the ranks), I naturally expect them to "touch" more functions across the organization, have larger and larger areas of responsibility, and at very senior levels, be able to propose new business or markets that we might enter, and justify this with generative research (finding their own domains rather than me needing to hand out domains). I have several peer directors that work on other distinct, but related, areas of the product -- the org structure is very much a "reverse Conway maneuver" as described in Matthew Skelton's Team Topologies, to deliberately minimize the surface area of communication that is necessary with other functions. All of us report to a VP of Product for the product unit who is essentially a general manager over the group, including understanding P&L.