AMA: Retool Head of Product Marketing, Kevin Garcia on Stakeholder Management

This will vary depending on how large or small your company and PMM team are, but let me share a few frameworks to keep in mind for different scenarios. Early-stage startup (0-50 people): It is likely you are the only PMM and one of few marketers. In this case, I think showing the value of product marketing comes through aligning with the company's top priorities (in what you do) and being results-oriented (in what you measure). If the company is looking to grow new self-serve users, use product launches to tap into new markets and use cases. If the company wants to go enterprise, help develop the enterprise pitch and customer proof points that will help land the first few deals. And be results-oriented. Early founders want their company to survive and grow. Being too theoretical/heady/abstract in how you describe your impact will earn you no points with founders. Scaling startup (50-250 people): You're likely one of a few PMMs and a growing marketing team. I think in this case it's good to start differentiating from other marketing roles by outlining 1) what initiatives your team OWNS and 2) how you fit into the company strategy. Don't focus on who writes blogs or launches campaigns. Focus on the specific company initiatives that could benefit from the discrete skills PMMs bring to the table—and communicate that! In terms of value sharing, your company is growing, so be a team that helps bring customer proof points, unified messaging, and market insights into every project you're a part of. The more you set the expectation that PMM will come to the table well-researched, the more tables you'll be invited to. Larger startups (250-1000 people): There's a PMM team and marketing department. Now is a great time to define swimlanes, set PM/PMM rules of engagement, and write playbooks based on your benchmarks from early launches. I like to showcase the strategy projects PMM is working on separately from launch/campaign work in our OKRs to reinforce the roles we play in marketing. And now is the time to become a master of your impact. To help the company keep investing in product launches, show how you enable new sales, expand customer relationships, and reinforce a great brand. Every launch, big and small, is a chance to reshare the value of PMM—and keeping executive buy-in requires that you communicate the outcomes FOR EVERY LAUNCH. Make it part of your process, and you'll see that buy-in stays earned. Bigger than that... I've never worked, so no advice! 

I've seen this play out a few different ways: * PMM owns content, Design owns design/dev, Marketing ops owns analytics/reporting * PMM owns content, Web team owns design/dev/project management/analytics/reporting * Brand owns content, PMM assists, and other teams own other things I'll start off with a few lessons learned: * If you try to be the gatekeeper of the website, you will eventually become the bottleneck of the website * Not all web pages are the same, and some are just not worth your time and energy * The more cooks in the kitchen, the less responsibility anyone feels toward anything My favorite dynamic has been: 1. You define the most critical pages on the website (usually homepage, pricing, and pages that made it into your header nav). If it's related to how a user/buyer would consider and buy your product, PMM owns. If not, it's owned by Brand or Growth. 2. Everything else on the website is owned by the team that is most impacted by it (i.e. Field owns events pages, Growth owns SEO pages, HR/Recruiting own the About page). 3. A centralized web design/dev team (and contractor group) works on all these things for visual cohesion and ownership when things inevitably have bugs or break. Because core web pages aren't shipped every day, you can focus on nailing the pages that are most strategic for the business. As someone who has owned the website for extended periods of time at 4 companies... trust me... you do NOT want to be the person who owns the entire website for any longer than you absolutely have to. It's not where your PMM strengths are best used, and is a huge distraction from core work. 

Excellent. Let's respond to this from the channel owners perspective (I promise it's to build empathy, not to be annoying). If I'm the channel owner, there are a few reasons why I might not want to do what you're asking me to do. Let's break them down: 1. I don't think it will work 2. I don't think this is a priority/ I'm really busy 3. I don't think you understand your audience 4. I don't think you understand the channel 5. I don't think you have reasonable expectations (of me or the goal) What you'll notice as a theme across all these things: I don't have the same amount of conviction in your plans as you do. This could be because I need to learn more about the launch, our strategy, or how this launch impacts the business. As a PMM, it is your job to be so clear on your WHYs (and to document that clarity) that channel owners can help you understand which of those 5 (or countless other reasons) is the reason they aren't buying into this as much as you are. In my experience, I find a lot of channel owners say it's 1 and 4, and as a result 5. Be honest with yourself: did you loop them in early enough to have them inform what would work, what the channel is best used for, and what a reasonable expectation might look like? If not, take the learning and give them enough context and space to collaborate that you get the outcome you want! 

Totally empathize with this! When projects start to creep into the "dozens of stakeholders" size, you end up with a lot of work just keeping people updated. Some golden rules that I use: * Create durable documents that outline the 5 Ws (who, what, where, when, why) for the project. Having robust documentation means everyone reads the same thing—and you don't have to have the same meeting with tons of people! * Create milestone moments. I addressed this in another question but I create 20% and 80% review check points for all projects—at 20% you align on strategy and at 80% you align on execution/polish. By creating two very public check point moments, you give stakeholders confidence that they'll get their feedback in when it counts, and you'll avoid people bugging you for when the right time is to give feedback. * Create a Slack/email cadence. For all of my projects, I create a public Slack channel where, at a minimum, I am providing an overview of the priorities for that week and tag who's responsible. We also use the channel as a visible place to make decisions. The result: I make updates and decisions in public, and every stakeholder can follow along at their own pace. It's a great way to uncover misalignment in real time and to make your update meetings much shorter—since you already have a documented trail of what's been done.

Product marketers have to work with a lot of stakeholders! I always recommend two strategies for keeping internal stakeholders aligned—and they both require consistent work. I recommend rigorous documentation and ongoing updates to get stakeholders aligned. Why? Because alignment is a process, not an outcome. Put another way, you can be totally aligned at the beginning of a project and completely misaligned the next week! Rigorous documentation helps develop early alignment. By documenting your goal, audience, expected outcomes, and timeline for the project/initiative, you create a durable reference that can be shared and iterated on faster than a series of 1:1 meetings. It also forces you to really think and be opinionated. For example, you might write down your timeline as next quarter, but your CEO—in seeing it in the document—lets you know that they'd really love to pair the launch with an upcoming fundraise next month. Writing the project plan down helped you learn about a really important deadline well before starting on the project, at a time when you have maximum flexibility to scope the project up or down. Ongoing updates helps keep alignment over time. I've never worked on a project that didn't change at least a little (in scope, timeline, audience, goals, budget, etc) over the course of execution. Ongoing updates help everyone stay on the same page—and raise the flag about issues in real time. It's also a great forcing function for you to focus on only the most important things. I like to write weekly "sprint updates" in a public Slack channel for big projects that outline the biggest to-dos and tag responsible parties. This level of visibility means I'm thoughtful about what I sign up to do, and gives all of us a healthy bit of social pressure to stay on track. Even better, you allow stakeholders to stay updated on decisions big and small. This is CRUCIAL for them to trust the process and stay aligned as the project naturally evolves.

EVERY company I've ever worked for, the engineering releases were mostly... not on time. And before you think that's a dig, let's levelset. Product development is hard. You are bringing an idea to life and testing it in the wild. You make decisions that work or don't, and then have to clean up later. You get pulled by customers to do things you didn't originally scope, and sometimes have to pivot (a lot). Product development done right is iterative, messy, and non-linear. The best products are not built in clean sets of two-week sprints. In other words, releases are a "guess-timate" at best. Knowing this, you have to balance doing right by stakeholders with the mess that is product development. Some learnings from my experience: * Align with the head of product on the most important product updates and what timeline makes the most sense to communicate broadly—and be general. You'll thank yourself x100 that you said "By end of quarter" and not "June 15th." * Become milestone (versus timeline-oriented) for GTM updates. Let the teams know why you are starting work on something even though the timeline might move (e.g. "We'll kick off wiring up the onboarding emails once the product team finishes the last billing update this week or early next" versus "we'll kick off onboarding emails May 2nd"). It helps channel owners understand that you are working off a product plan versus setting arbitrary dates. * Create a forcing function. If your PM team is open to it, there is NOTHING stopping you from launching things right after they are code complete. Giving marketing teams the buffer that something is live and exists while wiring up flows, experiences, ads, webpages, etc is SO much smoother. OR, you can work with your head of product to do a "Seasonal Release" that has a locked date your engineers can work toward. Doing so will also help you get more predictability on timeline since the date is immutable (or at least feels that way).

I find that trustworthy relationships with Sales leadership and Sales teams require a few key ingredients: * The Sales team believe that you will be honest * The Sales team believes that you will be empathetic (which requires research) * The Sales team believes that you will be part of the solution for projects/problems Honesty At the core of trust is honesty—that your actions match your words, that you only promise what you'll deliver, and that you will raise your hand when you don't have the answer. Sales teams play a huge role in the success or failure of many companies, and they rely on a huge network of stakeholders to help them drive revenue for the business. If you're honest in your approach to collaborating with sales, they'll most often meet you with the same. A few ideas for building an honest relationship: * Create a shared calendar of upcoming marketing events, campaigns, and launches and share with them * Create a shared channel for teams to share competitive intel, market updates, and customer news * Add sales leaders to emails/docs where you share a retrospective and learnings from prior work * Ask for feedback—and share when you've incorporated feedback you've heard into new work Empathy Don't forget that, just like you, sales teams are trying to do great work and do right by the business. It can be easy to want to do trainings, meetings, certifications, workshops, group deep dives to help inform marketing activities or drive product betas—but remember that you're not the only thing (or the most important thing) competing for their attention this week/month/year. By learning about the trends and initiatives that the sales team is prioritizing—and doing extra research to really understand why its a priority—you can become a strategic partner that they trust is asking for things because they truly are the most important thing. A few ideas for building an empathetic relationship: * Consolidate all the marketing activities/launches that are competing for sales attention into one place, and prioritize them (often with your head of marketing) so that the Sales team isn't getting hit from every angle. * Pay attention to/meet with your sales leads/sales enablement. Read the notes from their sales meetings, pay attention to how sales is doing compared to goal. Meet with leads on a monthly basis where they share insights and you do, too. * Listen to call recordings. This one is big. If your company has a call recording system (i.e. Gong) USE IT. It's so easy to forget that sales people are telling your product story and company story AND trying to build a relationship with the prospect AND influencing how that person thinks about their own problems. Listen to the good, the bad, and the ugly, and I promise you will develop a lot of respect for each individual sales rep. Solutions-orientation This one is pretty straightforward: will adding you to a sales initiative/challenge improve the outcome? If the answer is consistently no—or that you create more turmoil than solutions—you won't build the team's trust. Whether you influence how they connect the dots (strategy) or how they get things done (execution), being a player that helps secure the win guarantees you'll get invited to more games. A few ideas for being solutions-oriented: * Be a great listener! Often the person who listens for the patterns and clues in the data, meetings, and docs is the one who can most clearly see a great path forward. * Be lazy! Don't stress about why the project would be "perfect" if only it had [some ideal state]. Focus instead on "what is the least work I could do/the team could do RIGHT NOW that would lead to the best outcome?" 

Oh, geez, I have a LOT of failures to learn from! One of my biggest failures to date was during my time at AdRoll. I was leading PMM and we had a product launching in the attribution space that was having a pretty major identity crisis. Some of the biggest questions at hand: 1. How do we do attribution/incrementality testing better than what exists in the market today? (differentiation) 2. How does a vendor like us, who helps companies run ads, also provide trusted attribution insights across the entire marketing funnel and channels that we don't run? (building trust with target audience) 3. How do we monetize incrementality testing? (pricing and packaging) Major challenges to research, break down, and turn into an aligned strategy. And the stakeholders we were working with had put forth a pretty confusing plan to get there—one that made a lot of assumptions about the market and users. But I failed to help my team influence difficult stakeholders and it caused the product to falter and get delayed as a result. Here are my lessons learned: * Documentation, documentation, documentation. Having a GTM strategy documented is a huge way to help you and stakeholders—who may see things very differently than you—to start to work through your different opinions toward a joint goal (of creating the GTM plan). It's so much more productive than talking about things in the abstract, and helps you get into nuanced conversations (e.g. "If we want to launch the beta by June we'll need to lock in pricing by April so that engineering can use May to build the billing flows." versus "What should we do for pricing?") We didn't start documenting well until halfway into the project, and only after did we start to see the tide turn. * Create milestones and shared goals. Very similar to the point above, is that working together toward something is so much more powerful than working in the abstract. Try to understand the milestones your stakeholder wants to reach and the outcomes they want to drive. Where there is alignment, try to formalize your tag-team to make it happen. By setting a milestone to conquer, you create the right motivations for both of you to work out any conflicts in service of delivering the success. Again, something we didn't do until far later in the project. * Create visible gut checks. Sometimes your difficult stakeholder is the VP of Product. Or the head of sales. Or the CEO. And it can feel scary to deliver feedback directly that you disagree with their strategy/plan. But one practice I've since learned is having 20% and 80% reviews with a broader group. A 20% review is sort of like a strategy gut check, where you share how you're going to move forward before you start executing with a broader stakeholder group. An 80% review is all about polishing the details and preparing for launch. Creating space for a 20% review means that the broader group can call out concerns that "echo" and reinforce the feedback you're giving. Put another way, a strategy gut check gives you the chance to take an objective view on what to do next, which can be your ticket to a better outcome. I know this definitely would have helped in the example above! You'll notice that all of these thematically use process to help you drive toward the best outcome. It's totally possible that all of the above could bring to life that you are actually the difficult stakeholder—which is still a good outcome because it means your process helped you find space to pivot before it's too late!