Julian Dunn

There are some commonalities and some differences. First and foremost, across all constituents, I always promise that product management will always listen to them, carefully consider their feedback and advice, but we may not do what they want. This isn't to be mean. Many constituents not worked with truly empowered, autonomous product teams, so they don't understand why product management is not just a department of project managers to shepherd through work orders that they are issuing in the form of "feature requests". It's important to set the record straight about who's ultimately in charge of the roadmap.

Now, by doing so, I'm also obviously inviting these constituents to hold us accountable to customer satisfaction from what we are building. After all, with great power comes great responsibility, and if product continually is failing to deliver products and features that delight customers, then we deserve to lose our jobs.

With that out of the way, I always try to put myself in the shoes of the constituent and what they care about. How are they being measured, what is their background and context, what is their level of tech and business savvy and what do they need to know, in what form. This is a constant learning process, as other functions in an organization are always evolving! But just basic knowledge about what are the key drivers of constituent points of view -- to be blunt, what are they paid on -- helps to properly frame up any discussion about roadmap. It would behoove any product manager to understand the difference between "customer success", "customer architecture", "sales" (and the many roles in sales), "marketing" (and the many roles in marketing), etc. It's not all just "sales and marketing". Achieving this level of understanding is on the product manager.

Finally, be consistent. I use a small set of artifacts to describe roadmap, and I use them again and again with different constituents. The only difference between these artifacts is the level of resolution & detail. A salesperson for example typically doesn't want that much detail -- he or she just wants to know what are the hottest features that are going to help him or her retire quote. Sales engineers want to know which are the most complex features they're going to need to learn, but also which ones are going to be the most differentiated from competitors and impactful for showing off in a pre-sales motion. And so on. Being disciplined and consistent in articulating roadmap, down to just silly things like "don't call an initiative 5 different things to 5 different groups" goes a long way towards building confidence in you as a product leader, particularly as you know constituents will talk to each other without you. The more their stories align about what's going on in product, the higher level of confidence they have in you and your leadership.

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.

First, get good at written communications -- both as a writer and a reader. One of the most impactful lessons that I took away from the Amazon Working Backwards book by Bill Carr and Colin Bryar is how much they focus on crafting and refining written narratives like the six-pager or the PR/FAQ. Not only is the information density per hour higher for someone who is reading it (i.e., you can convey more information in a shorter period of time using the written word), but it also ensures that poor reasoning can't hide behind flashy PowerPoint. Written communications also level the playing field to ensure that ideas are what is being debated, not how good of a presenter a person is.

Second, have a good object hierarchy for how you will plan, track, and report on work in flight. Having an agreed-upon meaning for "initiative", for example, and criteria that must be satisfied before engineering (not discovery) work commences is critical for ensuring stakeholders are read in. Once you are in operational/execution mode on initiatives, have a set cadence (we call it "rhythm of the business") at which your management team will walk the work in-flight and discuss any issues is a key synchronous meeting to surface and address obstacles head-on.

Third, and this relates to the first item -- regularly publish and evangelize the product vision and strategy and how the department or company's current work connects to it. This should be a low lift if you've already written it down (see item 1) but admittedly, some people will not want to read lengthy OKR or business plan documents. Use synchronous time to unleash the passion you have for your area and get the team excited about what they're doing.

First, if you truly have stakeholders whose goals are 180 degrees opposite from yours, that's an alignment problem in the organization's executive leadership team and you have to decide whether that's something you believe you can change. But in my experience it's rarely this clear cut. Nobody has a product team that's trying to increase revenue only to have a sales team that's trying to minimize revenue, for example.

More often than not it boils down to a conflict between things that appear mutually exclusive but aren't. Take, for example, the common conflict between PM & engineering on reliability versus velocity, as embodied by (frankly unhelpful) maxims like Mark Zuckerberg's "move fast and break things". Actually, it's possible to move quickly and not break things, just as it's possible to move slowly and completely hose systems.

The best technique I've found for creating alignment and avoiding silo-versus-silo local optimization is to plan the business using one planning document that surfaces everyone's initiatives. I've used a single V2MOM (vision, values, methods, obstacles, metrics) document that makes all work visible across a product area. Engineering needs to redesign something for scale? Put it on the V2MOM. Design wants to spike on an area of the product that's causing significant user pain? Put it on the V2MOM. Need to conduct discovery (research) in an area? Put it on the V2MOM with its exit criteria. And so on. OKR is a similar system to V2MOM with the same forcing function that if a team decides to do something (objective), the goals defining success for that objective (key results) have to be internally consistent.

One other important thing when writing planning documents is to number all lists. Numbered lists force prioritization conversations because literally item n, by virtue of appearing at position n, is more important than item n+1. (In other words, if we only had time to do n items, items n+1 and on would not get done.)

Since I have experience on both sides of the aisle, I can agree that this is definitely a complex relationship! PM and PMM are two of the toughest roles involved in bringing products to market, because of the high degree of uncertainty that each job entails and the need to tailor each role's work to both product and organizational maturity.

I think there are three focus areas for creating and maintaining a great relationship with PMM:

1. Clear roles and responsibilities. If you haven't already conducted a functional roles assessment and gap analysis with your PMM team, you should start there. You don't literally have to use an instrument like Pragmatic's Framework Gap Analysis (https://mediafiles.pragmaticmarketing.com/Framework-Files/Gap-Analysis_1307.14.xls) but I have always found that one helpful at surfacing disconnects between who is responsible for something and who is being consulted. This is obviously much more of a job for PM and PMM leadership but if you're an IC and not getting the clarity you need from your management team, this is a good thing to push on.

2. Regular operational cadence and measurement. The corollary to this is to bring PMM into product development early. I can't emphasize enough how important it is to keep PMM read in, even during product management's discovery phase, and sharing rough drafts of artifacts like PR/FAQs and designs. This is even if you don't anticipate that the feature or product will be launched for several quarters. Doing so ensures PMM internalizes the broader context of what PM has in mind, what customer problems they're trying to solve and segments they're solving them for. When it's time to launch, the feature and its motivations are not a surprise. The same goes in the other direction. I want to hear from PMM regularly on what messaging and positioning is or isn't working in the field, what salespeople are saying they need in order to sell, how PMM's work is being threaded through to demand generation and campaigns and its impact on the top line.

3. Agreed-upon communication artifacts and bill of materials. I use a single spreadsheet that is a rough roadmap, plus PR/FAQs (other companies use "one-pagers") to explain to PMM what is the value proposition of each feature being built, in a customer's language. All of this rolls up to one high-level product strategy document that is updated once a quarter. Having a small set of detailed artifacts for information interchange keeps communication concise and accurate. Similarly, I expect PMM to maintain an evergreen "bill of materials" for each product and be able to explain on what cadence each BoM item is updated. This also helps both PM and PMM manage the sales team and prevent the creation of rogue, one-off artifacts that aren't on brand or on message.

I think "share" is the right term to use here. I've heard marketing teams claim that only they represent the voice of the customer, which is obviously not true. There are many groups in a company that interact with customers and listen to their voices. It's a PM's eternal challenge to figure out which voices are the ones they should weigh more heavily and which ones less!

I would say that PMs tend to engage deeply with a small proportion of the customer base and get a certain perspective that is then balanced by the views that PMM gains by interacting with the broader market using different instruments. For example, PMMs will gain particular viewpoints when they interact with analysts, or conduct win/loss analysis, that are often distinct from what PMs will hear from working with users. Good PMMs also tend to have a clearer view of the voice of the economic buyer in B2B software, as PMs tend to work with users more.

Lastly, I want to address the topic of customer feedback. Most successful companies tend to have some kind of customer feedback system where feature requests and other general feedback go. This kind of information is a goldmine representing the voice of the customer, provided there is someone -- usually a product operations function -- curating the data and summarizing common patterns for both PM and PMM. Without this, the feedback system is just noise and we lose the incredible valuable information buried in it.

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.

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.

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.

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.