AMA: Airtable Senior Director, Portfolio & Engagement Product Marketing, Christy Roach on Product Launches

Enablement is one of the most critical and often most difficult parts of the launch. The key to remember is that, usually, the product launch is just part of the overall sales process, and you need to treat your enablement as such. Very rarely will a customer-facing team drop everything for a new product line, you need to fit it into their existing flow. Here are some practices I use: * Timing is everything: This sounds stupid but it’s so key. If you’re trying to train a team during the last week of the quarter, you’ll get very poor participation and engagement rates. At Airtable, we will not launch a Tier 1 feature launch during the last month of the quarter to avoid this. Keep sales timing in mind when scheduling the launch and your enablement sessions * Work into their existing resources and frameworks: Rather than a feature-specific deck (which I have, unfortunately, thought was a good idea to make in the past) add this new capability to their current materials and show them how your new capabilities fit in with you overall product value prop and pitch. If they have a standard messaging framework and sales process they’re working off of, your messaging for launch should be mapped out in a way that fits into how they’re selling. * Outreach sequences and target customers: While marketing will have broad announcement comms planned, your CSM team is going to have a much tighter relationship with your customers than you are, and your sales team will have a better idea of how to introduce the new feature to a prospect based on their needs. Arm them with outreach sequences (that they’ve reviewed and will use) and, if applicable, pull lists of key customers and prospects who are a good fit for the new feature/product to help them prioritize outreach and communication around the launch. In terms of large, medium, and small launches and how to enable teams for each, my POV is that large launches usually have multiple dedicated training sessions. Often one on the demo, one on the story, and one for support on nuances and expected questions. For medium, likely one dedicated hour-long training. For small launches, work it into a monthly meeting about product updates or in their monthly all-hands. My biggest advice is to work closely with sales leadership to determine what makes the most sense for the team. You should come in with an idea of what you think will work, but your sales leads know the team much better than you do and can help make sure you do the right amount of enablement at the right time. 

If you take one thing away from this AMA, it’s that you need a source of truth for your launch activities. Please don’t run a launch without one, I’m begging you. Unsurprisingly, at Airtable we use Airtable to do this. I’d recommend it, it’s worked well for us. But I won’t give you too much of a sales pitch on why since that's likely not what you're looking for. What I will say, is you need a place where you can list out every activity, the owner, the status, due date, approval activity, and assets in one place. That way you can have a view of where things stand at any given point in time and spot problems or missed deadlines. Hiccups, delays, and mistakes happen in every launch, you can't get in front of every single one of them, but you can make a system that makes those problems easier to spot, so you can fix them. We use our Airtable base asynchronously to keep an eye on progress and also bring it up during check-in meetings to see how work is progressing. Cross functionally, I’d recommend a frequent cadence of check-in meetings that map out the main activities for each involved function. My product and CSM counterparts don’t need to see every line item of social copy or email hero image that the marketing team is tracking in our Airtable base, so our updates for the group are on the highest priority activities and anything we're working on that impacts other teams. Those check-in meetings might start once a month at the beginning of a launch process but get weekly or twice weekly as you get closer to launch. Our meetings included representatives from PMM, campaign management, creative, product management, product operations, engineering leadership, sales, CSM, support, and internal comms. A few weeks before launch, you should create a “run of show” plan in partnership with product and engineering. This maps out exactly when things are going live, who is on the hook, and key dependencies between the two. For example, in our recent launch, we needed our website to deploy before we could push our feature live in product because we had links in our product experience that took users to our web content, and didn’t want to ship a product with broken links. We might have missed this step without creating that run of show. The side benefit of making that is that it’s really fun to cross each checkmark off of your run of show plan when you complete them on the day of launch.

This totally depends on the product. Some launches are meant to grow top of funnel signups, others drive expansion with your current customer base, others reduce churn or expand product stickiness. Your goals should line up with the problems you’re solving. They should also have a tie back to your company strategy. At a high level, we usually have some awareness goals around web traffic, press pickup/message pull through, and signup rate. We’ll also usually set product usage goals within about 3 months of launch to help us determine if our customers know about what we launch and if they’re using it. We’ll often look at CSAT and NPS as well to see if the launch improved customer sentiment. If the feature is an upgrade driver, there may be an upgrade rate, sales pipeline number, or even a dollar amount that we set a goal around. I hesitate around setting revenue targets for launches unless we have something analogous to compare to. Without those, it’s often a guessing game more than a clear way to set goals. My big advice is to have a small number of clear, ambitious but achievable goals for your launch, then set one stretch goal that you've clearly labeled as a stretch. Get alignment with your product partners to ensure that you're both bought in on those goals. I usually have a shared KR with product to ensure we continue to work well together. From there, select a group of "monitor" metrics related to your launch. You don't need to set goals around those, you need to monitor what happens to them to help you understand how your product is being used and influence follow-up product improvements and education/activation activities. 

This is one of those times that PMM’s role as a “connector” shines most brightly. There are so many teams involved in a launch, and usually, they have differences in their POV on what the launch should do. I get goal ideas, questions, and suggestions from across the org, but I’ve worked to keep PMM from being a team that’s “given” goals, and instead made our team one that influences our priorities, connects work happening across the org, and leads the conversation around goal setting. There are a few different ways to think about this: * Tie back to company goals: Your company should have a clear set of goals and priorities for the year. Rather than setting a goal for a specific launch that’s duplicative to the company goal, show how this launch reinforces that goal, and what metrics you hope to influence. I find that often we feel the need to set bespoke goals for something, rather than just making the connection that this big launch aids in your company-wide goal of increasing awareness or moving upmarket. You can point to the ways this launch influences that, without having to set a standalone goal. * Share goals across your organization: Not every goal needs to be owned by PMM. I’ve often had folks suggest goals around large companies using a feature, NPS improvements, and more. Those are great goals, but they’re not ones that the PMM can really own. If we want large companies to use a feature, bring your CSM team into the conversation to see what they think about that goal, and suggest that they create an action plan for hitting that goal. If you want to improve NPS, that’s a conversation for your product and support teams to lean in on. As PMMs we often think we need to take on all the goals, but instead, we need to make sure the right teams are plugged into the work to agree on a goal and set a plan for it. Often, when you bring those teams in, you’re able to tell quickly if a goal just doesn’t work or isn’t obtainable. * Keep in lockstep with product: Start talking about goals early with your PM partner. Get their POV on what success looks like, share yours, and come to an agreement on priorities. I’ve found that if my PM and I are aligned on what success looks like, what we want to track, and the goals we think we should have, the rest of the organization will feel less of a need to tack on a bunch of additional goals. Of course, this doesn’t mean you’re not going to get goals from across the organization. When that happens, my suggestion is to clarify who needs to be in a room to discuss, and get alignment across everyone involved on a few (think, 3-5) clear goals that everyone can stand behind, as well as who will be on the hook for them so you can create a plan to hit those goals.

I think more than anything, the things we got right were the fundamentals: * Product need: We were launching a product that truly solved customers’ needs. We were crystal clear in our product spec about who we were solving for and what problems we were focused on. We validated that and got even sharper in our vision throughout a clear beta, and PMM was involved in every step, so we were operating with the information we needed to run a successful launch * Tight messaging: Messaging isn’t as hard as we crack it up to be, but it does take work and finesse. These launches had super clear, customer-focused messaging and that we could all rally around. We weren’t trying to say too much, we were deliberate in our pain points, value props, and differentiators, and everyone was aligned on what needed to be said. Our product team read the messaging and said “Yes! That’s exactly it!”. Our beta customers heard our pitch and said “Yes! That would solve my needs”. And our marketing team had a clear message to work off of, which enabled them to create incredible launch materials that resonated with customers and prospects. * Our entire team was rallied around the work: The hardest launches are the ones that lack alignment. They’re soul-sucking and take way too much internal conversation to get anything done. If you catch yourself in multiple conversations with the question "Why are we doing this again?", you're probably working on a launch that lacks alignment and buy-in. The best launches I’ve ever worked on have had clear alignment on what we’re doing and why. And I, as a PMM, have brought my key partners in early, listen to their feedback, and not tried to be a hero to do everything myself. PMMs often have to run the last mile to get a launch over the finish line, but that doesn’t mean that you should do everything. My best launches had an incredible partnership with campaign management, creative production, PR, lifecycle marketing, sales and CSM, content, and more to make it a success. It was “our” launch, not “my” launch.

Your GTM strategy for a launch starts by determining the audience and “tier” of your launch. I use a framework that has 4 different tiers: * Tier 1: Large, newsworthy updates that happen 1-2x per year. These change the positioning for your overall product, will appeal to your current customer base, and will attract new customers to your product. These have full-court press by the entire marketing team and usually utilize nearly all of your channels. You should rally your team around these launches more than any other. * Tier 2: These are big product developments that either apply to your current customer base or will apply to a specific subset of the market. They don't warrant the big efforts of a Tier 1, but are still a big deal. Usually 1-2 per quarter depending on the size and speed of your org. These deserve standalone activities and effort but are usually a smaller, more focused list of activities to your current customer base. * Tier 3: These are relatively small product updates that a subset of your current customer base will care about deeply. Usually, 4-5 per quarter that can be bundled together if needed. The launch is usually a very targeted set of activities to a subset of your customer base. * Tier 4: These are small updates (often usability improvements) that do not warrant comms. They should be either unnoticed by your customers or straightforward enough that a customer can see them and understand what to do without prompting. Based on the above, here are the main components of a GTM strategy that my team uses for a launch: * Product launch tier and strategy brief: You cannot execute until you have a clear plan, a clear goal and audience, and a clear POV put into a brief that your product team is aligned with and your marketing org can understand and act on. This includes a pass at a bill of materials that your channel owners review and contribute to. * Messaging: This is, in my opinion, the most important part of a product launch strategy. Nail the messaging, nail the launch. Write your messaging in partnership with your PM and validate it with your customers. Messaging is not final copy and does not need to be 5 pages long. A tight, clear framework that helps everyone understand what we’re trying to communicate is the most helpful thing you can create for the launch * Pricing decisions: If your PMM team leads pricing, you need to be clear about what the pricing plan for this feature is, how it interacts with other features, and if you’ll be pushing any upsells etc for this launch. Even if you don't leave the pricing decision, you need to create a plan that accounts for it. * Channel execution: PMMs should partner with their channel experts and partner teams to execute the materials they’ve set out in their bill of materials. Often this is, at minimum, a launch announcement (blog), email, in product announcement, and social/Community posts. Your bill of materials can also include things like video, AR/PR activities, webinars and gated content, tutorial videos, and more. * Enablement: Training for internal teams (sales, CSM, and support) as well as internal comms coordination to ensure everyone knows exactly what is happening, when. I’ll caveat: every launch is different. There is no formula you can follow every time, your GTM plan needs to be created for the product you’re launching.

Every single launch, even the ones that made me crazy, taught me something valuable. As I’ve gotten more senior, I’ve done less of the launch coordination but I still get deeply involved in our product launches because I believe there’s nothing that encapsulates the feeling, energy, and excitement of being a PMM quite like launching a new product. If I look at the launches I’ve been a part of, there are two that stand out to me as the most impactful: The first was very early in my career, in a job I actually didn’t thrive in, but that I learned a ton from. I was lucky enough to be a very early employee at Gusto and was there through the launch of their benefits product and the rebrand from Zenpayroll to Gusto. This stands out to me because I think it taught me the most about running a large launch, building a brand, and having a customer-centric mindset. The product was incredibly complex (as you’d assume health insurance would be), it also was a huge unveiling of a new brand and a new name, and I loved watching and contributing to the process of defining that brand. The thing that stands out most to me was that every employee, probably about 125 of us at the time, blocked the entire launch day out to call every single one of our customers to share the news, reassure them that getting an email from “Gusto” was the same payroll product they knew and loved, and answer any question they had. That launch has stuck with me for over 6 years as a way to go above and beyond for your customers and stand up for your brand values. The second was the most recent launch I ran at Airtable bringing our Interface Designer product to market. This stands out mostly because I’ve seen enough launches to know when there’s something special happening. On the surface, it looked like a lot was stacked against us. Our team was short-staffed, I actually had to step in and individually manage this launch. Our product was launching in beta because, while we knew we had something powerful to bring to market, it was a very early version of the product. We were juggling over ten other product updates, and our deadline seemed tight. This stands out because it was truly a team effort across the entire company. We were on Zoom at 9 pm ensuring the website deployed, all of us were Slacking our favorite tweets and community posts back and forth, and our customers loved the product. I think part of what stands out about this launch is it highlights the power of mindset and the role PMM plays in fostering a positive launch environment. Huge launches managed remotely can lack the energy that being in person does. But this one had that same buzzy feeling of excitement and accomplishment. As PMMs, our role isn’t just to bring the product to market, it’s to motivate the company and rally us behind that launch. This launch was such a nice reminder that you can do that remotely when you’ve got a great team and a great product.

This is something I deal with a lot. Often, for a large launch, you’ve got multiple product components that you’re bringing together for one big moment. I find that launch teams often have that "more is more" mentality, where our product teams push to get something else completed with the energy of the launch. While I love the energy, all these components can be impossible to tie together and manage as you’re getting close to the launch. As a rule of thumb, I focus on the customers we’re targeting and the story we want to tell as the two lenses I use to decide what to group together and what to create a standalone effort. My biggest suggestion for managing this is to get in front of it as best you can. Here’s how I do it: * Yearly planning: As we go into our planning for the fiscal year, I sit down with our product leaders and map out the major launch moments for the year. We look over the proposed roadmap and talk through what we think the big launches will be for the year and the possible components we can add to the launch. From there, I drive an exercise focused on determining what we think the headline of that launch could be and the main perceptions we want to drive. Once this is done, we look through those components and determine if they strengthen the story. If they do, they’re in. If they don’t, they get moved to a standalone, smaller launch. This is a great time to get your product members on board with what the launch could be, and you have alignment on what to do as new product opportunities pop up and the launch gets closer. It's also a great way to make sure your key teams, like creative, content, and web know when big launch moments are coming so you're not catching them off guard with your requests. * Quarterly planning: With our big launches mapped out, we go into each quarter looking at what we think will be coming up in the next 3 months and how to plan for those launches. We decided to group things together if they strengthen one another’s story. Sometimes we’ll also consider combining if they’re happening at the same time and we need to combine to save team resources or not over-contact our customers…but only if we can find a way to tie them together that's intuitive and will make sense for the customer. If that can't happen, we'll hold the launch for a week or two to give each product development its time in the sun. * In launch prep: Often, during launch prep you realize you have WAY too many things going on. At that point, you sit down and map out what should be held for a follow-up launch moment. The story you want to tell and perceptions you want to drive are key in that decision-making process. After our last big product launch at Airtable in early November, we did 3 “follow up” launches focused on features that launched with our large launch but didn’t get much airtime because they didn’t fit with the story.

I count these as “Tier 3” launches which I define as: Relatively small product updates that a subset of your current customer base will care about deeply. You are spot-on that they’re important for users to know about. Usually, it’s a specific group that needs to know about it. For example, we usually treat launches for our admins as tier 3. They’re vitally important for admins in the enterprise, and they do reinforce our overall enterprise message, but admins are a relatively small percentage of our customer base when compared to our overall user population. Our whole customer base doesn’t need a ton of communication about this, but admins do. For something like this, we’ll usually write a blog post about the updates that's emailed specifically to our admins. We’ll also arm the sales and CSM team with outreach email templates so they can keep their most important customers in the loop. We also recognize that while most end users don’t need to know in-depth details about our admin updates, some of our most engaged users are still curious about anything our product team releases, so we’ll include the update in our monthly customer newsletter, release notes, and share on our social channels.

This can be really hard to manage! Like everything, it really depends on the feature and product readiness. I’ve often done this is in a few stages: * Early product development: We start by educating our internal teams on what we’re building, the problems we want to solve, and our target customers. That helps them understand what’s coming and often they’ll suggest good customers to add to the beta. At that point, there is nothing for a sales team to demo or show a new customer, but we will give an early preview to customers who would qualify for the beta to give us feedback. We have the PM/PMM do the presentation to the customer in a slide deck, rather than having the salesperson manage the preview. We rarely show actual product during this phase and, if we do, they’re images on a slide, not a live demo. * During development: As we get into the beta and have more of a product to show, we’ll create a form for our sales team to submit if they have a customer they want to add to the beta or demo the product to. We’ll still have our PM/PMM demo the product and need to vet if the customer’s needs are in line with what we’re building and what level of “polish” they’re looking for before we agree to do the preview. If they are okay with a rough demo, we may pull up what we’ve got. If they’re not, we’ll still show slides. We set guidelines on what types of customers and opportunities qualify to get a sneak peek. * As we get closer to launch: We’ll enable the product for internal dogfooding. That’s around the time that we’ll also do our sales demo training. We want the team to feel comfortable sharing the product before we launch it, both in terms of functionality but also what use cases to highlight and what is available at time of launch. We ask our sales team to not include this news in every demo until our launch activities happen, but we do give them the ability to give a sneak peek to customers who are up for renewal, need the functionality to go all-in on Airtable, or have another special circumstance. We follow this system because it’s impossible to keep a sales team from sharing product news before launch, and you shouldn’t try to keep them from doing so. A sales job is incredibly complex, they have a lot to manage and juggle in a customer relationship, and they need to be able to have flexibility in their conversations. That said, it’s important that the product is positioned in the right light and that you’re not overpromising what will be available. We find that keeping that demo functionality gated by a PM and PMM is a great way to do this. It does take up a fair bit of time, but it’s also a great way to test and get validation on messaging before launch that can help strengthen your launch activities.