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.

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.

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 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.

Lots of changes are happening, chiefly motivated by the end of free money (i.e. post-ZIRP era) and the rise of AI. I know everyone has probably heard these two themes a million times before so let me break it down specifically for this area. The end of free money has been talked about a lot on the vendor side but not so much on the buyer side. Startups are under pressure not just because VCs are a lot tighter with their funding rounds, but also because revenue is drying up for point solutions as buyers are tightening their belts & trying to consolidate spend onto a smaller number of platforms (exhibit 1: Datadog). Whereas in the ZIRP era, developer buyers had a lot more latitude to experiment with individual tools that might deliver small productivity gains (or were even of questionable value!) This does not mean that all point solution tools will die off -- not in the slightest. What it means is that point solutions who have been in business for >5 years are trying to move up market to the enterprise and/or build a platform (or get themselves acquired by a platform), which leads to a Cambrian explosion of new point solutions. However, these products will be more laser-focused on value as expressed in direct revenue, rather than "blitzscaling" to create massive adoption first and figure out the value/revenue later. How does this impact developer product management? It means the developer PM now needs to be focused not only on whether the feature is cool and shiny, but also become more financially literate: what is the ROI and time to realize that ROI. Financial literacy is even more critical in the era of AI, which promises to bring about a whole host of fundamental changes in human/computer interaction, yet at a very high cost today. It's critical that PMs keep abreast of macro trends in AI, but not to get distracted with the day-to-day minutiae of how this model outperforms that model (unless you are building a product solely in the AI domain for AI/ML developers, in which case, have at it.) Two things that developer PMs have to keep in mind in the AI era: 1) How do the innovations in AI change how developers specifically will interact with computers in the future & what interfaces/experiences are possible now that weren't possible before and 2) What is the cost of delay in prioritizing good AI ideas? Right now we are often seeing cost of delay as positive because the cost of AI computing infrastructure is coming down so rapidly but there can also be persuasive arguments to be made for accelerating certain features to market in areas where you don't have a good moat (you need to beat competitors to the punch).