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 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