If your product team works in two-week sprints, how do you balance and prioritize each launch? In other words is a "release" always a "launch" and how do you differentiate and treat each?

That sounds really challenging, but exciting to work on a product that iterates so quickly.

First, I'd work with your product team and try to show the impact of bundling a few small updates at a time, rather than piecemeal. It's tough to break through if all the updates are small and are so frequent — users start to zone them out. You can better help reach product goals with bigger launch moments that can pack more of a punch — which will help the product team reach their goals, too. Can you get them to test holding updates from one sprint to the next once or twice? Then you can show them how much more attention and adoption you were able to drive.

If that isn't possible, I'd think through your marketing channels and set up forums where you can get updates out there in a clear and steady framework. Can you set up a Twitter thread that you add to every time a small update fits in that theme? Can you build habit around a biweekly or monthly newsletter to all users that bundle up all the recent updates? Can you build an in-product notification system that lets you share quick fixes in real time?

I would suggest bundling the two week sprints into a larger quarterly release cycle so you can benefit from a bigger, impactful story. If you are hitting your customer base with new features every 2 weeks, I can guarantee you they are going to be fatigued, saturated, and less likely to engage. People are suffering from cognitive load, so cut through the noise and surface the features that matter on more sustainable and customer-friendly cadence. 

In terms of release and launch terminology: a release is product-owned (normally consists of getting a product/feature into production for general availability. While a launch is formal marketing of the feature. Development complete = release. Market ready = launch. They are very different motions.

Good question! Mindset shift suggestion: Every release, or update, or upgrade is a launch. BUT there are different tiers of launches which enable us to provide a very low level, but consistent level of support. It's not the job of PMM to create fanfare around every single update, but it IS our job to create understanding around each.

Getting ready to ship v0.1.13? You don't need a parade or a linkedin post, but you do need to make sure your audience understands the changes. Have your product or docs team be responsible for updating the changelog, or set a reminder to ping them every two weeks for what's new so you can do it yourself. Optimize for reducing questions around anythign that launches—both internally and externally. If you don't expect a lot of questions, even better!

For larger product marketing teams, there's a whole function around "release marketing", which aims to showcase the added value consistently. Activities might include a "weekly wrap-up" or "what's new in [product]" monthly update via social media channels, newsletters, community forums, and/or a dedicated space on the company website.

For example, Confluence has a dedicated webpage for these types of updates: https://www.atlassian.com/software/confluence/features/whats-new, and you can see screenshots and summaries of new feature releases.

Compass has the "Compass Communique", which is a regular email update detailing new features in this beta product: https://www.atlassian.com/software/compass

And Jira Software shares short updates on Twitter to make people aware of new features, integrations, and UI changes: https://twitter.com/Jira/status/1660664543352111104 and https://twitter.com/Jira/status/1658520714092195842

To differentiate between a "release" and a "launch", we look at several criteria (I'm coming from a SaaS lens):

• Is this a net-new capability, or incremental improvement on an existing capability? Is this driving feature parity across products and/or cloud vs. data center?

• How novel is this release in the market? Is this a rare capability or is it ubiquitous and brings us to parity with a competitor?

• What is the potential market size for adoption? Is this targeted at a niche subset of users, or will this have broad impact across our user base?
  

• Will press, analysts, influencers, etc. have interest in sharing, promoting, and/or amplifying content around this capability?
  

• Does this tie into a broader story and/or more related features coming soon/recently released?
  

• Do we have any other big moments coming up that might impact how this message is received/when we announce (ie: earnings call, user conference, industry event, pricing changes, Magic Quadrant/Wave placement, etc.)?
  

Depending on the answers to those^^ questions, we'll determine the level of "launch" that a new feature/capability receives. Most of our teams have a tiering system that includes criteria about impact, novelty, audience, etc. and the associate activities.

The big key is that product marketers have to be ruthless in their prioritization, and sometimes that means telling product managers that a feature does not rise to the level of a full "launch". This is not just about time or budget management, it's also about reputation management and credibility with your audience.

If every single feature rises to the level of "full-scale launch", you miss the opportunity to truly wow your audience when you have a differentiated capability. They become numb to the barrage of messages about "THE BEST NEW THING EVERRRRRR", when it might just be fixing a bug or realizing feature parity with your own products!

I always frame a "release" as an engineering event in which new capabilities or a new product (after having been deemed "complete," passing QA, Docs fully update, etc) are either ready to be made available to customers in the form of distinct Release Candidate (RC) build or, in the case of SaaS, made available to customers on a rolling basis. Either way, there's no integrated marketing support in the form of PR, AR, social, demand gen, etc - that would be a "launch" - but PMM still needs to make sure that account teams/customer support are prepared for the changes and supporting self-service content on the web, forums and other places are updated to support that "release". A "launch" involves big marketing fanfare with coordinated PR, AR, social, demand gen, etc efforts meant to create awareness and demand in the market, often anchored to a major moment like a user conference, 3rd party event or some other galvanizing moment (like the release of a Gartner Magic Quadrant for certain enterprise categories). For SaaS products, oftentimes new capabilities get pushed when they're ready ("released"), but for the full marketing "launch" announcement are the pieces are pulled together to tell a fuller, more compelling story all at once. In both cases, PMM plays a critical part but "releases" are engineering events while "launches" are full GTM motions.

While a product may technically be ready for launch, it doesn't necessarily mean it's market-ready.

The key to addressing this lies in the quarterly planning process, which involves reviewing the roadmap and tiering the launches. Larger, more impactful launches are given dedicated moments to shine, allowing them to receive the attention and resources they deserve. On the other hand, smaller feature launches may be grouped together to create maximum impact with the target customer while the minimizing noise.

As each launch becomes available, the strategy established at the beginning of the quarter is executed. This approach ensures that product launches are not only aligned with the overall strategy but also effectively managed within the constraints of two-week sprints.

So first of all, you don't necessarily need to "launch" every release to the market. In my experience with B2B enterprise SaaS, we typically had various product teams on various schedules and even if we got them on a common schedule, it didn't mean that every feature needed to be "launched". Launch to me is the different than release because launch implies something being pushed to the market and there is a GTM engine behind it. And as part of that, this is where the role of the marketer is so valuable - you get to build criteria in that determines (1) when you launch (2) how you launch (3) and really, what you launch - because not everything is worth evagenlizing in press release or analyst briefing.

Correct, a release does not equal a launch. I get it. When your product team is working in two-week sprints, it may be overwhelming if you're not used to it, especially when your product and R&D team are proud of what they are delivering (as they should be) and want more to announce it to the world.

There are two important things to remember, and you already nailed the one:

1. A release doesn't equal a launch

2. What is the full story?

Sometimes, a release contains an item that may warrant its own GTM strategy. Hopefully, you, as the PMM, were brought in early enough to know that it was coming and have already built a plan around it.

Other times, the release item might be part of a larger story. Even though the capability is live, you can communicate it to partners and customers and save the external announcement until you have a larger story to tell.

Develop and communicate GTM phases and activities to help with this. It could look something like this:

• Sprint release: customer release emails, in-app notifications, release notes

• A significant feature (consult a launch-level tiering system for it): stand-alone GTM strategy on the release item

• Thematic Launch (bundle relevant previously released items together to create a launch story): Full GTM strategy