Chase Wilson

Most product marketers I've worked with are tuned in to new feature releases or creating effective comms for upcoming product improvements. For a product launch, however, it's almost always given the highest priority automatically. Most of the work is done to make sure the product itself is positioned correctly and that what we promise matches up in-product. All hands are on deck at a specified time for a large volume of page traffic and social comms. With that said, I absolutely needed to prioritize various channels for the launch and assign KPIs per channel. When I was planning my launch strategy I evaluated ~25 different channels and placed them on a 2x2 grid based off of their relative effort vs impact. We had a small team and some channels barely made the cut, such as social channels. I'm a big believer that marketing KPIs should more-or-less match up to what the product team cares about. For example, for Jira Work Management I worked with my corresponding PM to establish what we cared about (MAU), which sub-classifications of that goal were important (expand channel-driven MAU, conversion rate of top-of-funnel to MAU, etc), and monitored which marketing channels were most effective at driving those numbers. After the launch we evaluated the success of our bets to iterate for upcoming releases.

I hear this pain quite a bit. Many people would likely propose working hard to have a "seat at the table". To me this isn't quite enough. A seat at the table will give you insight into launches, but not necessarily any real sway towards changing decisions. I believe product marketers need to expand beyond the "typical" skillset to provide enough value to be taken seriously at early stages. Be comfortable pulling your own data directly from the databse using SQL, be competent at Figma / Sketch, learn how to code a little to understand the relative difficulty of engineering tasks, spend time prioritizing features yourself and learn a few prioritization frameworks. These skills (and others) will help you be a true value-add during times where roles are less clearly defined, aka product idealization. 

Great question! For the Jira Work Management launch I was actually the first team hire. This was really important for the dynamic of our team and we eshewed the common "triad" for a "quad". That is to say that I helped design the product and no large decisions were made without my input, whether that was for design, engineering, or product. The same existed in the reverse, where everyone knew what the marketing gameplan was and was able to give their suggestions and thoughts. I would say that every new product team should be evaluating the market, competitors, differentiators, packaging, and positioning before designing the product. This could be done by a product marketer or not, but these areas are key. You're absolutely right that product marketers are often relegated to "translation duty", or to take whatever the triad created and find a way to present that to customers. Org readiness was a huge task for my most recent launch and I essentially managed: * All cross-team enablement * Distribution strategy and coordinating with relevant teams to make those channels succeed * Asset creation, development, and testing I found that a few things were key to making this successful. * Deep knowledge of the product itself. If you don't know how and why the product is engineered the way it is you'll almost always be creating superficial enablement materials. Additionally, I believe that you want to get to the point where stakeholders will come to you with technical questions and that you should be able to answer ~70-80% of those questions. The rest (such as why the GraphQL endpoint was configured the way it was, etc) should be handed over to product or engineering. * Organizational buy-in. I found this allowed for less last-minute stress as I was able to ask favors for quick turnarounds. Also, other people in the organization would come to me with their ideas for how to make the launch better. * Trusting relationships with your core team. You really should aim to be a foundational pillar of why, when, and how a product is launched. But even before that, you should hope to be a pillar for why the product is necessary at all. Once you have this foundational knowledge you'll be better set up for success with organizing the work surrounding a launch.

Launch frameworks vary wildly depending on some fundamental questions: * Is your company well-known or resource-rich? * Are you B2C or B2B? * Do you have a Freemium offering? * How long do you expect the sales cycle to be? Once you establish answers to these questions you can more effectively choose: * Which channels are viable * Which channels are likely to be successful * What channels you need to put the most effort towards * Which tactics will best drive engagement through those channels When you've created a plan you can start to work backwards. At that point you would find the hard dependencies within your organization and plot out dates to make sure everything is set up correctly for the launch. Here is an example of a (basic) launch roadmap and a channel prioritization matrix.

I was lucky enough to manage a sales team at my previous role and hopefully can provide some insight here that were informed by that experience. But, it may be a bit controversial! I'd say that most sales enablement campaigns deliver: * Competitor battlecards * Product feature talking points * Positioning statements * Collateral like whitepapers, decks, and one-pagers Most of this is moot at a product launch in my opinion. It's not that these aren't important, but you can quickly spend significant time on any of these categories. What's important to me is that you should be set up to provide very basic versions of each of these that you fully intend to completely revamp after talking to the sales teams themselves post-launch. We can always guess what customers want, but reality is often different. I generally assume that everything I create pre-launch could be discarded within a few weeks of the launch. So, in short, competely only the most funademental requirements (e.g. explaining what is the product, who is it for, what makes it different) and start in earnest a few weeks post-launch after you acquire more learnings.

This has depended fairly dramatically depending on the size of the product launch, how ready the product is for prime-time, and the scale of the company! For example, for my Jira Work Management launch we needed to make sure that: * Purchasing and provisioning pathways were live * Support / sales teams were enabled to answer questions * Email comms were accurate and scheduled * PR interviews were completed the week prior to launch * Landing pages are live and priority pages were translated We had a marketing runbook that involved ~50-70 tasks depending on how you count the work. For product launches at smaller companies, however, it looked something like this: * Email comms scheduled / accurate * Social comms scheduled / accurate * Checking for dead links across all pages * Establishing support documentation and basic FAQs * Posts for Product Hunt / Hacker News / IndieHackers were all ready I've found that larger company product launches involve significantly more cross-team enablement compared to startups where the majority of the launch is the launch itself. Much more work and pre-planning went into launching a product at Atlassian.

I hate to answer with "it depends", but it does! Atlassian has ~25 cross-functional teams that I worked with as the launch came closer. Some of those teams required 4 months of lead time to make sure everything was done on time! Others came in during the last few weeks. I found that it was important to cast a wide net early on and to be curious. Your curiosity will uncover more dependencies than trying to think of every possible dependent team if your org is larger. For smaller companies, I found that most of the work was crammed into the two months prior to the launch. If I needed a new email the day before the launch, this was fairly easy to do myself. At Atlassian, where an email team manages such sends, I had to have content finalized weeks before the launch day. A good rule of thumb is that you should double or triple the SLA of the teams you work with. If an email team requires 2 weeks of heads up, try to get engaged with them 4-6 weeks beforehand so that you have a more elevated final result that they feel bought in to. If I had to do things differently, I would have set up some larger meetings where I explained the launch to at least one member of each team. I was hesitant to have large meetings because, well, large meetings aren't great, but that would've made things go more smoothly.

I've seen this vary from top-of-funnel metrics down to MRR depending on the goal of the product. Aspects that I believe impact the KPI you ultimately choose are: * What does this product mean for your company? * Is it awareness of your company in the market? * Is immediate revenue important or can it be pushed down the road? * How well do you understand user pathways from signup to product usage? * How well do you understand your funnel? * Do you have historic data to base assumptions on or is this a green-field launch? * Are you confident in the amount of traffic you'll be driving from specific channels? * Do you have a captive audience anywhere that you can take advantage of? You'll choose very different KPIs depending on how you answer the above questions. For the most recent launch we focued on in-product usage (MAU, engagement rate) instead of revenue. For bootstrapped, single-product companies, revenue was my KPI. For startups with money it might be signups to show growth. Understanding what marketing should do for your company will help to create impactful KPIs that don't focus on vanity metrics.