Priya Patel

I'll start with the first question around working with your PM team to get a sense of what's launching and product benefits. If your product team does not already do this, definitely work with them to see if they can develop a PRD or some form of product documentation that outlines the problem the product is trying to solve and what the solution will be. Here's an example I found quickly on Coda: https://coda.io/@john/prd. This is an important asset that all stakeholders across engineering, design, and PMM can reference. In terms of outlining product benefits - your PM counterpart may lean on you as the PMM to define the benefits, but they should ideally have a sense of the customer problem they're trying to solve with a particular feature if it's on the roadmap.

With regard to not needing to launch improvements/bug fixes - one thing you can do that I have found helpful is establishing a framework for launch tiers. Low customer impact items like minor bug fixes, as an example, would be tiered in a way that would indicate no marketing support. At my company, the launches that get marketing support are typically Tier 1 and Tier 2 launches, and a bug fix would be a Tier N/A (no support). The tiering is based the level of impact to customers & prospects. You can work with your product team to align on the tiering framework and define tiers for every launch so everyone is on the same page.

At fast-moving startups, the product roadmap is often fluid. When you're facing a decision about whether to push out a launch or even deprioritize a launch, let the customer be your guide. Think about what features and capabilities they care about most, and prioritize your launches based on this. Not every feature will need a marketing launch - tiering your launches will be really important here (and establishing a tier for the launch in collaboration with your product counterpart), so you understand how different launches stack against eachother and can communicate this broadly across the org.

If you're constantly feeling like you're shifting launch dates and every launch is becoming a firedrill, definitely invest in aligning with your product stakeholders to define launch dates that make sense from a GTM standpoint. Your PM counterpart will not always know or be thinking of GTM considerations such as spacing launches out for media coverage, as one example...but they want their products to be adopted and launched successfully. So having conversations with your PM counterparts to align on launch dates that give your launches the time needed to coordinate across the org and make a market impact is important. 

Lastly - you have 2 P0 launches right next to eachother, think about spacing them out artificially. You don't always need to align the marketing push around a launch with when exactly the feature actually goes live. 

As the driver of the overall success of a launch, typically the PMM is responsible for the overall metrics around a launch. These can drill down into KPI categories like: Sales (ARR), Product (adoption or engagement), PR/Comms (coverage), Social (likes, new followers, engagement), Web (traffic, demo requests, form submits), Sales Enablement (asset views/downloads) and Demand Gen (will detail below) KPIs. At a more mature company where there are members of the marketing team specialized in these areas, those teams would be responsible for their respective KPIs. Of the above categories, PMM would typically squarely be responsible for the sales enablement KPIs (at a B2B company).

Demand Gen KPIs would typically include:
Email engagement
MQLs
SQLs and/or SALs
Influenced or generated pipeline

In terms of responsibilities, this can obviously depend on the size of your organization, but if you have a dedicated demand gen team, PMM would be responsible for:
- the product/feature messaging and positioning and target audience definition (buyer personas)
- content that is used in demand gen activities (email nurtures, webinar decks, ebooks, web copy, etc.)
- sales enablement assets (decks, one pagers, customer evidence)

Demand gen would typically be responsible for developing programs to amplify a launch and PMM content would feed into those programs.

This is a great question. The key here is to get involved early - in roadmap planning and product strategy - so that your role extends beyond reactively launching features. If you're at a B2B company, this means you'll want to get to know the market and your target audience really well so you can deliver insights to the rest of the organization, especially sales and product. You'll want to have a perspective on key product gaps, where the market is moving and customer needs/expectations.

In terms of specific actions you can take, if you're not involved in your company's quarterly roadmap planning process - get involved. Come prepared to those meetings armed with insights (from customer surveys, Salesforce, qualitative data from the field) to support your POV on the roadmap. If you become a thought partner to your PM counterpart, he or she will include you in the strategic planning process.

I've never worked anywhere where releases don't get delayed - delays happen. The best you can do is to stay in as close communication with your key stakeholders as possible - informing them of updates in real-time. You won't lose trust with your team if you're open and honest: put a stake in the ground and establish a launch date if there isn't one, so that everyone can start planning their respective workstreams and you can ensure a successful launch. But also clearly communicate that there's a chance the date may slip. You can hold a launch planning session on a regular cadence (every week, leading up to a critical launch) where you bring stakeholders together to discuss latest timelines and workstream updates.

I've worked at companies with different philosophies on this. The main benefit of a monthly or other regular cadence is predictability - i.e., everyone in your organization is aware of launch timelines and can plan accordingly. Customers always know when to expect product comms. But a con is that releases can get lost when they're bundled together and when updates become very regular or templated, they can become less interesting to a customer.

On the flip side, sometimes it's not ideal to wait (or scramble) to push out a product or feature by a certain time every month, and having rolling releases can offer more flexibility. For this reason, many earlier stage companies do rolling releases. From a product comms standpoint, one challenge you might face when doing rolling releases is that timelines constantly shift, and you might be spending more time aligning internally on launches. You also need to be careful about not over-blasting customers with communications. But a pro is that you can drive education and adoption of specific, important features.

A hybrid is a nice blend of both worlds. You have predictability around planning and comms with a monthly cadence, but for major Tier 1/high-customer-impact releases, you can do dedicated comms so they get the airtime they deserve.

Customer research is so critical to the success of a launch and the extent of it will depend on the size and scope of the launch. At a minimum, you'll want to do customer interviews to understand:
- The customer problem
- The value the product will deliver
- Who your target segment(s) and persona(s) are
These will serve as the inputs to your product or feature messaging and positioning. If you work at an enterprise-focused company, it's sometimes not so easy to get in front of senior buyers at the enterprise level. In these cases, you can leverage the feedback of CAB members and beta customers - if you feel this isn't enough or representative of the market, work with the field to get in front of the audience you're targeting. If you work at a consumer or SMB-focused company, you can also conduct surveys, but you'll usually still want to start with qualitative interviews to get inputs for the survey.
In addition to direct customer feedback, depending on the launch, you may also want to leverage other data sources such as in-product, competitive, SEO and/or CRM data.