AMA: You.com Director, Product Marketing, Ben Geller on Stakeholder Management

As a PMM, it's crucial to be the expert in the market, including the user needs & competitive landscape, while you can lean on your PM partner to be the expert in the technical details of the product you're building. With this in mind, I would draw the line based on the type of question you're answering. If it's about the user's needs or competition, then it's your job to educate the PM/rest of the org. If it's about the technical details of how the product is built, then it's okay to lean on your PM/Eng counterparts to get up to speed. That being said, the ultimate goal is to 'mind-meld', so that the PMM team gains a deep technical understanding of the product, and the PM team gains a deep understanding of the market/user needs. This is when the magic happens!

In building trust with your stakeholders/xfn partners, I think having a curious, open mindset, demonstrating kindness goes a long way. For example, if you disagree with a decision, first seek to understand the rationale and context around the decision (e.g., in a quick Slack chat), before pushing back in a more formal setting. In the past, I've seen colleagues run into issues here, where they will unintentionally hijack meetings by voicing concerns in front of a broad audience, without having taken the time to understand the rationale with an open mind. This can create resentment from the working group (and wasted time) and in the worst case lead to exclusion from similar meetings in the future.

Personally, I've found that the best way to build trust in the first 90 days, is focusing on identifying areas where you can immediately create value (no matter how small). The softer side of relationship building naturally happens through executing. Here's why: * You were likely hired for a critical reason. Especially in the current market, there's an expectation that you will be taking over work that was causing your teammates stress/headaches until you joined. * Focusing on identifying areas where you can jump in head first (are there fires that need to be put out?) will build trust & teach you how the organization works. * From there, you'll be on a much more solid footing to go on a listening tour, and deeply get to know your coworkers. The biggest way I've seen new employees lose trust in the first 90 days is over-indexing on relationship building without jumping right into things and executing. Alternatively, colleagues who develop a reputation as a 'do-er' (no matter how small the task) tend to be more deeply trusted & respected.

I think it's crucial for a remote team to have a regular process/cadence for showcasing their work to the broader company. Why? It creates a forcing function for the team to clearly articulate what they're working on & why. It also create visibility for xfn partners & fuels collaboration. Here's the process we use for my team at You.com: * Every Friday, the marketing team puts together a short deck (<10 slides), that shares highlights from the past week & what's coming next week. We'll share the deck during a quick (5-minute) readout in the company all hands, with 1-2 main presenters and others chiming in as relevant. * To prep, the team meets Thursday morning for an hour, to update each other on projects, and build the outline for the deck. Then we collaborate async to finalize the slides. * The team touches base again Friday morning for 30min to review the slides and align before sharing out to the broader company. While this exact approach may not work for ever company (not everyone is fortunate enough to have a weekly all hands :), I would encourage all marketing teams to find a consistent cadence for sharing their work more broadly. It works wonders in driving alignment.

Rather than thinking about what team they're on, I love the RAPID framework for stakeholder management. This is a tool that helps clarify who is accountable for decisions, and the role each stakeholder plays in that particular decision. The different roles in RAPID are: * Recommend: Develops recommendation for a decision. 80% of the work happens here. * Agree: Ensures the recommendation meets specific requirements. Their input must be factored in by the R. * Perform: Executes the decision once made. * Input: Provides expertise or information to help shape the recommendation. Input is used at the discretion of R. * Decide: Makes the decision and commits the organization to action. In projects I've led in the past (as the "R"), the communication cadence/style will change depending on the stakeholder's role. For example, the "I's", which historically have been an xfn group of data science, product, design, marketing, and potentially sales, are deep in the weeds with me, and comms can be relatively informal. However, the "As" and "D" require more active stakeholder management, and are typically made aware of progress in written updates, and brought into the discussion formally once the recommendation is getting close to finalized.

For a large cross-functional project, there are three keys to keeping everyone on the same page & running efficiently: * Align on the high-level objective: When kicking off a new project, it's crucial to outline the vision for what you're trying to accomplish and what success looks like. I typically will do this in a joint Google Doc or Notion page and ensure that it's distributed ahead of time so stakeholder feedback can be incorporated. We'll then do a formal meeting to review & address any final outstanding questions. * Establish a shared workflow: It's essential for everyone working on the project to have a clear system to align on the progress of each task and collaborate. I love Asana for this—as it's easy to track the high-level project status and dive into details. I've also used Google Docs, Jira, and Notion. While each has their own strengths/weakness, the best tool is the one that will be adopted. Start with whatever people are already using, and only add on new software if absolutely necessary. * Establish regular syncs: Do not underestimate the value of bringing everyone into the same room, to make sure that people are communicating. For a high-visibility product launch, this may mean 15min daily standups leading up to launch day. For other projects, this may mean weekly 30min syncs. It's important to prep an agenda ahead of time and make sure notes/action items are clearly documented. Otherwise, it's easy to swirl. If the project is running smoothly, I love using these meetings to review the shared project tool (e.g., Asana), and focus on exception management where group feedback is needed.