Eve Alexander

I've tried so many tiering methods! One that's working really well for us right now is something we made up based on the audience that "needs to know": Go Big, Tell Sales, Tell CS. Every quarter, we propose one story line to put in the Go Big bucket (typically several capabilities that ladder up to a unified story). That gets 80% of our efforts -- or at least, that's the goal! That's what we rally our marketing team around in terms of PR, social, analysts, content. If there are additional capabilities that are important to sales -- e.g., because they'll help sellers hit quota, competitively differentiate, or gives them a good reason to reach out, etc -- we put those in the Tell Sales category. That gets about 20% of our attention specifically around enablement and developing a few sales assets. Everything else lands in the Tell CS bucket, and enablement and communications happen through PM and tech pubs -- no PMM. I like this approach better than Tier 1, 2, 3 -- because it always felt like more things would end up in Tier 1 than we could actually support! In terms of KPIs, one size doesn't usually fit all. Typically you want your Go Big items to be real needle movers for the company, which typically means they drive revenue. So pipeline, bookings, attach rate are often ones I've used. For smaller launches, adoption and usage are pretty common. If we're responding to a competitive gap, we would also track an increase in win rate or reduction in that item being a "reason lost". And sometimes, capabilities might lend themselves to NPS.

I don't know about you, but I think there's so often a tendency to jump right in and start delivering. I encourage everyone that starts working on my team to spend their first 30 days learning! If you can work with your boss, try to buy yourself some time just to soak up knowledge and develop a point of view. The key things I try to get to know as much as possible when starting a new job are: the product (spend time using it, get certified if that's an option), customers/prospects (listen to Gong calls, shadow sales calls), the business (dig into your dashboards -- what's your average deal size, how long are sales cycles, which segments are performing well or aren't, what's your pricing...), and your colleagues (product managers, sales RVPs, CS, enablement, demand gen...). At the end of 30 days, share a SWOT with your manager, and identify a few quick wins for days 31-90. The quick wins should be tangible deliverables that have some visibility with cross-functional teams. Maybe there's an in-progress launch a colleague is leading that you can contribute to and present deliver part of the enablement. Or maybe there's an under-served area (a persona, a part of the product) where you can collaborate on with a few people to build out the storyline, materials, and training on. 

Here's my go-to: * Initiative objectives and targets (bookings, adoption, whatever you've aligned on) * Opportunity size and costs * Customer challenge * Brief product strategy (MVP + 1-2 releases out) * Positioning/Value Prop * Target audience * Distribution strategy (e.g., are only a subset of your sales teams going to be selling it? Can partners resell it?) * Pricing & packaging (including Services) * Competitive set (do your traditional competitors have a similar offering? Are there non-traditional competitors) * Launch summary (Date, approach) * Key risks I summarize the above on a single slide "exec summary" then include a slide -- or a few -- per topic to provide additional context and rationale. This works well for driving understanding and alignment and is great as a pre-read. Then you can double click into specific topics live based on the audience.

I won't share the full list -- there are some great resources out there like SiriusDecisions -- but here are a few that I've learned through trial and error are really helpful. * PRFAQ: As soon as possible, I work closely with PM to craft a "PRFAQ" (fake press release, customer and internal FAQs). Then, we circulate that to cross-functional stakeholders from sales to legal to finance to customer success to enablement. It's a killer way to make sure everyone is on the same page, and flag items that require debate and dialogue. We're doing this right now for a major initiative, in fact! * Messaging framework: Currently, I'm loving "Storybrand" (check out the book Building a Storybrand by Donald Miller). For every major launch, we craft messaging that puts our customer at the center as the hero, and positions us as the hero's guide. Not only does it make for empathetic, customer-centric storytelling -- it's also a great tool for other teams to build out content. * Tiger teams: Our launch marketing manager brings together key cross-functional team members starting months before a launch. In addition to driving key deliverables, they also serve as the subject matter experts within their team in a "train the trainer" kind of capacity. For example, for our new AI-Guided Selling offering, the solutions engineer participating in the tiger team is getting the whole SE team up to speed on how to demo it effectively. Way better way to scale! * Enablement plan: Every product has different enablement implications from the teams that need to know, to the topics they need to know about it. We partner with our enablement team to tailor it for every launch. * Slack channel: Centralizing questions and information about a particular launch or capability is a great way to democratize knowledge-transfer. Whenever a sales person or CS rep reaches out to me over email with a question (e.g., pricing or availability), I point them to Slack. Then our internal community can help provide answers, which makes everything so much faster!

One thing that has been wonderful at Seismic is we have someone on the product marketing team that is in a program management role and who is responsible for driving and faciliating organizational readiness for launches (shout out to my colleague, Steve!). He pulls together "tiger teams" for our major launches with representatives from around the company, leads weekly meetings, and manages our project plan. This takes some of that organizational readiness weight off the PMM. The PMM lead may still have to help triage bottlenecks and risks, but frees her up to spend more time on her core work of buyer insights, GTM strategy, messaging and positioning, enablement, launch, etc. 

Love this question! It's funny - the first one that comes to mind was not actually a traditionally successful launch; it was the one where I learned the most, got to spend a ton of time with customers, and really got to flex my creative muscles. What I loved was having the space to conduct deep qualitative and quantative research. I had the chance to go on a few multi-city roadshows to pitch it live, and refined the storyline after every conversation to craft a compelling, customer-centric, validated value proposition. Unfortunately, so often, I feel like this part of the process gets rushed -- which is too bad since it's so fun. At launch, I partnered with the marketing team to execute a really creative integrated campaign. We kicked it off at our customer conference where we unveiled the product with a video, and then brought features of that video into our physical presence at the event and incorporated audience participation. The product and the message were everywhere. I mentioned a learned a lot in that launch, too. One thing I learned the hard way is just how critical it is to bring everyone along for the ride -- you can have the strongest value prop in the world, but if key stakeholders aren't bought into the product's success, you might not be successful. That's why now when I'm working on launches, I engage with cross-functional team members as early as possible and collaborate with them closely on the GTM strategy. 

Probably the top one -- and one I've been guilty of in the past -- is not setting objectives and measures of success for a launch. I've seen this most often at companies that are earlier in their maturity, before a formalized business case process is in place to greenlight projects. But you don't need a formal process to at least sit down with your PM counterpart and discuss things like "is this a product that we expect to drive revenue? Or is it about reducing customer churn/increasing stickiness? Something else?" Then, ideally set a target around it. The targets help a lot when it comes to post-launch to figure out if you're tracking or if you need to make adjustments to your approach. The other one I've seen is not socializing early and often with sales and customer success teams. Early in my career, I participated in a new product intro that we treated as kind of a "skunkworks" effort. There was a desire to minimize too many voices that the leader felt would slow down the project. But when it came time to launch, the product didn't have support from the field. It ultimately failed. It was a great learning experience for me, and now I know how important it is to bring people along for the ride and develop your champions early.

Is it ever wrong to start as soon as possible?! Early in the ideation/business case phase, I try to keep it narrow. I'll tap a few members of the GTM team to help me brainstorm use cases and value proposition, which we then refine through additional research and customer validation. It's helpful to have early champions that you can pull in as you are launching -- they can help generate excitement and understanding. If it's a really new motion for the company (e.g., the first time you're introducing a new product or a new way of pricing), or a new buyer, you really can't start those conversations with teams like finance, sales, customer success soon enough. Ideally 6+ months. If it's not such a new paradigm, then I'd say on average I aim to start about 3-4 months in advance. We start with a single member of the key teams, and then as we get closer to launch (6 weeks-ish) start to pull in others. Ultimately, it depends on your organization. How fast it moves, whether it's a consensus-driven culture, etc. At a previous company, I authored a launch playbook, and after every major launch, we would do a retrospective and refine it. I really like to approach launches as something we can continuously improve upon rather than a big unveil or overhaul. 

I can so relate to this question! One of the things I've grown more comfortable with over time is the idea that if we wait until something feels truly "fully baked" then we probably aren't moving fast enough! This is especially true if you've got longer sales cycles. I used to be really uncomfortable with that, but I think there are a number of ways to mitigate risk. Here are some of the things I think about: * Can I phase the launch or roll out? For example, is there a pilot I can do with a subset of my customers, or is there a segment or sales team I can start with before rolling it out to everyone? * How might I put guard rails in place? For example, when it comes to deal qualification, is there an approval or review process we can implement for early deals? * How can my messaging and enablement efforts drive excitement, without overselling? For example, with my sales team, articulating the vision while making it clear that the product only solves for 1 of the 3 use cases right now. One of the things I always try to include in prepping for a launch is a slide or document that frames up the risks because it gives you a channel for escalating those. So if, in fact, you feel like the company is out significantly over its skis, you should definitely raise it!

I'm a huge fan of Donald Miller's Storybrand framework. I typically like to use a simplified version of it, as I find that the full framework can be onerous and heavier than we need it to be in our fast-moving company: * Define your hero (your customer) and what they are trying to accomplish. For example, at Seismic our hero is an enablement leader, and she wants to improve her ability to impact business outcomes--and demonstrate that her team directly contributed to those outcomes. * Articulate the problem, or what's getting in the way of them achieving their goal. Historically, enablement leaders have had to wade through multiple systems and disconnected data to understand what is going on with their initiatives, like a new product launch. This is manual and time-consuming--making it nearly impossible to quantify impact, or course correct along the way. * Highlight the guide (your company or product) and how the guide can help. With Seismic's new Programs product, for the first time ever, enablement teams have a centralized command center to launch, run and optimize their initiatives--and connect their work to business outcomes like revenue. This is where you can pull in additional information about your product or company, such as key capabilities. * Demonstrate how the hero achieves success. This is where you articulate the business outcomes your product provides. Seismic Programs allows enablement to operate more strategically, drive GTM team behavior change, prove impact, and increase company agility. I like to bring in customer evidence -- case studies, data points, etc.