AMA: GitHub Senior Director of Product Management, Julian Dunn on Stakeholder Management

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.

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.

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

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.