LaShaun Williams

Yes, I do. We continue to tweak and refine it. The document serves as the single source of truth and artifact for each launch. Here's what in it: Strategy * Product/feature/capability narrative: A short story that provides context into the why behind the release. * Product/feature/capability overview: This is a snapshot of the what it is and why it's important. If you were giving a feature elevator pitch, this would be it. * Who cares: The primary and secondary audiences in a "think, feel, do" framework. * Messaging framework Execution * Goals: The top three things we want to accomplish and how we will measure success. * Deliverables: These are organized in a channel matrix with DRIs (directly responsible individuals who are typically the channel owners). * Product release date * Launch date * Run of show: Organized into a table. Tracking * Meeting notes * Performance against goals * Landing review notes

This is where tiering comes in handy. We adjust the depth and breadth of GTM plans based on the estimated impact of the launch. We also decouple product launches from product releases. For example, some small launches are bundled into a larger themed launch, which may happen after some of the features have been released. It's helpful to align on this approach and set expectations with your product management partners early on — they drive what is being built and PMM drives how and when it is communicated to the market.

I segment communications into three audiences: 1. Product management 2. Project DRIs (Directly Responsible Individuals, typically marketing team members) 3. Leadership Communication with product managers driving particular features or areas of the product occurs regularly, typically on a weekly basis. I use these meetings to remain aligned on positioning and messaging, accuracy in deliverable development, product/feature readiness, and timelines. I see this ongoing communication as foundational to the other pieces of the puzzle. After formally kicking off a launch plan, I also like to meet with project DRIs on a weekly basis to communicate product updates, any potential changes to the timeline, surface dependencies and blockers, and maintain alignment on goals, deliverables, and timelines. This approach has helped me effectively manage the project coordination and wrangling needed to pull everything together for launch day. For larger scale releases, I include a leadership GTM review in my process. I like to run these meetings prior to kicking execution off with DRIs. During GTM reviews, I develop a slide deck that outlines my GTM plan and includes context on the why behind my decisions. It is reviewed with the product manager leading development and sometimes the engineering lead prior to leadership review to ensure alignment on timelines, dependencies, and potential trade offs (if needed).

This is a great question. In my overcommunication with leadership, I am very open about the skill levels of my directs, what I think they're currently capable of, and where I think they need improvement. While some failures are a result of non-performance, many help surface areas for improvement. That said, I am also very clear with leadership when I have given someone a stretch project or they're struggling in a certain area and there is the possibility of failure. This helps set expectations around what to expect from my directs. I also communicate my role as a leader and what I can control to other leaders and my direct reports. That's ensuring my directs are clear on all things related to the who, what, where, and why of a project. And, communicating my expectations around decision-making, timelines, and deliverables. When it coming to managing down, I articulate what it means to own a project. So, when we're discussing ownership, we're all on the same page. They know they are accountable for all outputs and outcomes related to the execution of projects they own. They know I expect overcommunication, no surprises. They know I will look to them when things go well and when they don't. My directs are people, not robots. Learning comes from failure. I take responsibility for giving them opportunities to fail and learn, and I hold them accountable so they can learn from failure (and take pride in their wins!).

We communicate updates and progress two ways. For each launch, we create a Slack channel specific to that launch and the people directly involved in decision-making and execution. Whether it is private or public depends on the culture of your organization. We also have a public marketing Slack channel where we generally keep folks in the loop on marketing efforts. We share weekly updates that can include updates and progress on product launches.

One of the most important outcomes of stakeholder management is getting buy-in, and that comes easiest when there's trust. Getting buy-in is absolutely critical to moving projects forward, and the first 90 days is a great time to lay strong foundations. Here are the three actions I take very intentionally to build trust with my peers and cross-functional partners: 1. Ask questions and listen intently. The same way I approach different audiences with different positioning or messaging is the same way I approach building trust internally. It starts with showing a genuine interest in other people — putting them at the center of the interaction — and listening intently. This allows me to understand the lens through which they see the world, the company, and our product. I can meet them where they are. Example: It's my first 90 days and I am making my rounds in getting to know the Sales team. I ask questions about our audience and how what they're hearing on their calls aligns to the slide decks and collateral. Are they using that collateral? Do they feel like it works? Why or why not? I demonstrate a genuine interest in how they show up to work and their day-to-day, so I can best put myself in their shoes. I may learn from my conversations that they don't feel like they have input on the collateral created for them, it's not really useful, and they just build things on their own as a result. This gives me insight into them feeling unheard and a desire for closer collaboration on the things that directly impact how they do their job. Let's say we start working on a new sales deck. I create a small consulting group of high-performing and influential sales folks to collaborate with (true story). Together, we come up with the idea for the deck to live within the new product we launched, passively demoing that new product while speaking to the broader platform. This approach satisfies the closer collaboration the team is seeking, produces a fantastic idea that supports our new narrative, and results in greater buy-in across the broader Sales team. 2. Create clear documentation. Don't expect people to read your mind. When I was at a previous employer, one of the things we would say is "clarity is kindess." I really believe that when you have the best interest of a stakeholder in mind, clarity is best. It sets expectations and empowers people with the knowlege and understanding to make decisions. Example: I was running a big launch at a previous employer. There were lots of moving parts, and lots of stakeholders — including executives. It was really important that the folks executing on deliverables understood why they were creating what, and that the executives understood why we were making certain decisions around timelines and tradeoffs. This required very clear communication across documentation, Slack channels, etc. My approach was to create a comprehensive GTM plan that included the strategy and tactics (single source of truth) and separate project plans to manage the plethora of deliverables. The GTM plan included the thinking and why behind what we were doing, our goals, and how we would collectively achieve them. The projects plans included that thinking at the project level. For executives, I ran GTM reviews. There I gave them insight into the strategy and where our efforts fell within the GTM funnel, so they could see the complementary relationships between each tactic. I also communicated go/no-go criteria for moving forward from a product readiness perspective, including what we were and were not optimizing for, and why we were or were not making certain tradeoffs. That clarity (and the confidence it exudes) helped me get their buy-in and move the launch forward as I saw best for the customer (even when it meant pushing back on their sense of urgency to fix bugs and conduct more beta testing). 3. Overcommunicate. This is especially essential in a virtual environment. It's definitely something I don't think I've mastered and continue to work on. Overcommunicating means communiting clearly, early, and often — which also requires a level of vulnerability. It means erring on the side of too much information. It's asking for help as soon as you need it, or sharing an idea when it's not quite buttoned up. Example: Within my first 90 days in my current role I laid out my plans through the end of the year. Part of that plan was cleaning house — creating structure, getting organized, and identifying missing parts. I knew it was important in positoning us to optimize for speed and execution. The challenge was, at a company level, people want to see marketing doing stuff — producing content, running experiments, etc. And, at the team level, people are wondering what (if anything) is going to change about their roles and responsibilities. At both the leadership and team levels, I communicated my thinking, goals, and foresight as I was refining my plan — answering questions and implementing helpful feedback along the way. Overcommunicating brought them into the journey and being part of the story I was building with the plan also gave them greater understanding. Ultimately, resulting in buy-in.

I really enjoyed launching branching and merging at Figma. It's a technical feature that is challenging to build as well as communicate to a non-developer audience. Both the product and marketing teams worked hard to simplify the complexity of the feature in experience and messaging. It was a two-part launch, public beta and GA. There was an interesting back story to share, we made hard decisions, timelines adjusted, the team rolled with the ebbs and flows, and we launched a great feature.

Tying your work to tangible outcomes, specifically those related to product growth and revenue, and socializing it has worked well for me. Here's my approach: Have a revenue-first mindset. Businesses exist to make money. One of the first questions I ask myself about any launch is "how can we leverage this to drive revenue?" Before getting strategic or tactical, I explore the different angles we could position or message the launch to drive revenue. Releases small, medium, and large have the potential for revenue impact. Work backwards. When setting launch goals, I work backwards from the company goals, and map the connection so I know where tactical efforts and outcomes ladder up. This trail is helpful when communicating the value of your work, especially at the executive level. Map your tactics to the growth framework of choice (flywheel, funnel...). This has worked really for me when presenting GTM plans and running reviews. Organizing your tactics into a strategic framework helps folks see all of the areas Product Marketing touches, understand what areas your work is contributing to and how it all works together. Socialize wins and learnings. Beating your own drum brings visibility to your work while also increasing morale (wins) and knowledge (learnings) across the company. Celebrate others. Spread the love and it will come back around to you. Word of mouth is a great internal marketing tool. I've found that when you celebrate and champion the work of others, they are more inclined to do it for you — which increases your visbility throughout the organization. 

Ask yourself what it really means to connect the product to the customer? You'll see that it's more than the features you build and launch alongside your Product Management partners. Behind product execution is product strategy, behind product strategy is a product vision, and that vision is based on a story. Product Management and Product Marketing build that story together — deciding what part of the story they build and when (Product leads, Product Marketing supported) and how and when to introduce that chapter of the story to their audience (Product Marketing lead, Product supported). You're strategic partners with an overlapping interest in using the product to tell a market story and influence the way people behave. 

Engineering timelines change for a variety of reasons. It's just the nature of the work. To help manage the expectations and emotions of others working on the marketing timeline, I take this approach: Communicate early, openly, and as often as possible. That way, folks don't feel out of the loop or in the dark, and they know you have respect for their time and effort. Don't overcommit to to timelines. I approach and communicate them with the caveat that there is always the possibility for delay. Focus on the customer. When engineering is delayed, it's likely that the team ran into unforeseen difficulties building the feature, challenging bug fixes, or there was a shift in prioritization. All of these things have the potential to impact the customer experience negatively. In communicating with launch stakeholders, I always circle back to being customer-first and delivering the best possible experience. Being customer-first means just that. We take on the domino effect delays can cause for the sake of their experience. Empathize with their disappointment and move forward. We are all humans and humans have emotions. Acknowledge that folks may be upset, then work with them to talk through next steps. That may be holding off on a deliverable and prioritizing something else in the meantime. Or, moving forward as planned and having everything tee'd up when the feature is ready.