AMA: Glean Head of Product Marketing, Paloma Ochi on Stakeholder Management

Fostering strong relationships begins with having the right mindset: assume everyone has the best intent, and you’re all there to build something great together. (If you don’t believe that’s the case, then you’ll likely want to reevaluate whether that’s a place you want to be working.) Next, figure out what unique value Product Marketing can add to help other departments. Working with Product? Help create a narrative that articulates how your product is differentiated in the market, and use customer insights to identify opportunities for the product to support that narrative. Working with Communications? Help identify upcoming product releases that support thought leadership pillars for executive talk tracks. Proactively helping others not only accelerates the business you’re all building (a rising tide lifts all boats!), but also helps maintain the “magic relationship ratio” of 5 to 1. According to relationship studies— yes, these are studies about romantic relationships, but the concepts still apply to any interpersonal interactions— you want to maintain a ratio of 5 (or more) positive interactions for every negative interaction during conflict. Conflict is bound to happen, but it doesn’t feel like conflict when you have a solid foundation of positive experiences working together. 

The best Product Marketing and Product relationships are the ones where the two departments work in lockstep to: * Understand customer needs * Create a compelling product narrative that addresses customer needs * Determine what to build to make the product narrative into a reality Once the team has determined what to build to support a compelling and differentiated product narrative: * Product leads the charge on gathering build requirements and determining the plan for delivering a great product * Product Marketing leads the charge on determining the go-to-market motion, including how to position and message the new product features Because both Product Marketing and Product depend on each other to successfully deliver a great product experience, regularly gathering input from and checking in with the other department results in the best collaborations.

When rolling out a new GTM launch tier framework across the business, start by identifying key stakeholders across R&D and GTM who can represent their functions’ objectives and needs for launches. With the group of key cross-functional stakeholders, determine which launch tiers you need. For each launch tier, determine the cadence and product criteria that defines each tier. For example: * Tier 0 launch: Happens once per quarter. This is a large feature or bundle of features that have significant impact on and high visibility with customers, and therefore require more GTM support to have the highest impact. * Tier 1 launch: Can happen every two weeks. These launches have larger customer implications or will drive meaningful impact to business metrics, and therefore warrant more GTM support. * Tier 2 launch: Can happen once per week. These are launches for standalone features that have high visibility with customers, but low calculated risk to customers and aren’t expected to drive meaningful end-user adoption, so don’t require more GTM support. * Tier 3 launch: Can happen whenever features are ready to ship. These are small, incremental feature updates that have a smaller impact on and less visibility with customers, and therefore don’t require any GTM effort to launch. If an update doesn’t add new functionality or change the behavior of existing functionality (from the user’s perspective), it likely falls into this category. It’s particularly helpful to sanity check whether you have appropriate definitions for launch tiers by using past launches as examples, and determining where those launches would’ve landed in the launch tier framework. Then for each tier, determine which activities are required from each function, across R&D and GTM. Higher tiers (i.e., tier 0 and tier 1) will naturally require more support from each function. Once again, use past launches as examples to determine what the required launch activities should be for each launch tier. Once all key stakeholders are aligned on the launch tier framework, leaders from each function should share the framework and solicit feedback from their respective functions— and start using the framework! When planning new launches, the planning process should include identifying a launch tier from the launch framework. You may find that you need to make adjustments to the framework, but teams will have a starting point for defining the type of launch and which activities are required to support the launch.

Keeping stakeholders informed on a regular basis can involve a variety activities, including: * Sharing updates in broader company forums (all hands updates, OKR updates, Slack / Teams / email updates) * Regular syncs with key functional leaders * Regular syncs between product area owners * Documentation on ongoing trackers or project management tools

A key part of getting buy-in from different stakeholders involves first ensuring that everyone understands the context behind the project, the objectives for the project, and the importance of moving quickly. Make sure all of this is very clearly laid out for stakeholder consumption. Set a timeline for when you need to make a decision, and make sure stakeholders also understand the consequences of not moving quickly— in some cases, it could be a tradeoff you’re willing to make. In many cases, prealigning 1:1 with key stakeholders ahead of a larger group alignment discussion can actually expedite decision-making, since it gives you the opportunity to understand key concerns and resolve any key differences 1:1.

Prioritizing and managing requests from various stakeholders across the business requires: * Understanding what’s best for the business. Prioritizing what’s best for the business is the best way to get stakeholder buy-in. * Determining what’s important vs. what’s urgent. While it’s easy to get caught up prioritizing the most urgent requests that come in, that can lead to spending all your time just playing whac-a-mole with urgent requests; there’s always something else urgent that requires your attention. This leaves little to no time to prioritize work that’s actually important– i.e., the work that will actually move the needle for the business. Make sure you prioritize what’s most important, and fill any remaining time with urgent requests, prioritized by their impact on the business. * Ensuring stakeholders have broad visibility into what you’re prioritizing. At the end of the day, everyone should want what’s best for the business. So when stakeholders see the high-priority, important work that you’re working on, they’ll better understand where their requests fit in the lineup. 

Different teams may have different goals, but at the end of the day, all of those goals are in support of larger business goals. Interdisciplinary project goals should ladder up to those larger business goals, and influence should come from moving the needle on those larger business goals. If people are not aligned on the same objectives for an interdisciplinary project, then it’s important to first take a step back to align on common objectives.