How do you think about bundling or 'holding' launches for a regular launch cadence vs releasing when ready?

Every organization thinks about this differently, and I’ve worked across the spectrum from a single, annual release (Android OS) to continuous release (B2C startup).

So what cadence is right? If you pressed me for a single answer, I would say a quarterly release (I didn’t make this up, I just happen to agree with this post by David Sacks: https://medium.com/craft-ventures/the-cadence-how-to-operate-a-saas-startup-436aa8099e8). Quarterly tends to be long enough to bundle together several meaningful product updates and develop a "through line", but regular enough to show your customers you are responding quickly to their feedback. For PMMs, it allows you to organize around a cohesive launch - whether that takes the form of an event, a “What’s new” webinar, a customer activation, or something else.

But if you’re at a scaling startup, and especially one that’s focused on consumers or SMBs, you may find quarterly releases feel too slow at first. At Vanta, we’ve found success with creating a cadence of launches throughout the quarter, aiming for several mini-launches and a larger release every ~month that receives integrated marketing support. 

If you are grappling with this at your company, some ideas are:

• Create delineation between bigger and smaller launches - ideally through a formal tiering process, but even a quick T-shirt sizing on impact is helpful
• Agree to a cadence of those larger/smaller launches that matches both your product development cycle and your customers’ expectations
• If you don’t know what that cadence should be… test and iterate!
• Remember that pushing code ≠ a release. You can “release” things before or after they are shipped - or even re-release them.

I think there are two different thing - and both important. I think releases shouldn't be random (like daily) because your CS and Sales teams, and most importantly, your customers, can't keep up with them. If so much is coming out all the time, your customers don't know about the new stuff. And worse, your cs teams doesn't know either and then cannot answer customers questions! At Drift, we have a monthly release process. This means that we release features on the first Wednesday of every month. A week of ahead of release, we train the CS & Sales teams and arm them with customer facing slides they will need. We also include in-app messaging on release day and include it in a monthly customer newsletter roundup. 

Product launches, on the other hand, are meant to drive market momentum -- to built pipeline, create urgency, and deliver value. I've always implemented a Tiered launch strategy (tier 1 - market moving, tier 2 - feature add on, integration etc, and tier 3- backend update or 'monthly release'). Tiers 1 and 2 have big market impact, with goals to drive pipeline, revenue and win rates. I suggest seasonal Tier 1 launches (so 3-4 a year MAX since it's a major effort) and sprinkle in 2-3 Tier 2s throughout the year to keep building momentum between Tier 1s. 

I’ve seen both approaches, but it depends on your business, selling motion, and product team culture on which approach is best for your company. I'll share some takeaways from my experiences at Asana and Gong. 

At Asana, PMM and product aligned on an annual launch calendar with 3-4 major launches. Launches for smaller feature releases and improvements were coordinated between the PMM and PM. This decentralized approach allowed the PMM to be more strategic when positioning features, which oftentimes meant bundling; coordinating across PMMs to create an overarching story to target audiences. The downsides of this approach are that customers sometimes have to wait to get value from new functionality, and it relies heavily on the rapport between the PMM and PM.

At Gong, our product team is quite prolific, so we have a monthly release cadence that aligns GTM teams with product. In other words, we release features when they’re ready but only during a designated 1 week release window every month. On top of this release process, PMMs also create larger launch moments for Tier 1 and 2 features. The upsides of this approach are that customers get value right away, and Gong is perceived as a company with high product velocity. The downside of this approach is that it's challenging to pull through a common narrative when shipping 5-10 disparate features each month. This also makes it more challenging for the field to understand how to plug these new features into their sales motion.

There are tradeoffs to both, so it’s important to understand what you should optimize for, based on your business. #1 optimizes for clarity (both for customers and the field), and #2 optimizes for product velocity and faster customer value.

Each organization thinks about this differently, and both approaches have pros and cons. Three things to think about here: market impact, efficiency/scalability, and customer experience. 

Typically, I advocate for monthly releases (unless you’re an early-stage startup). Bundling releases together can help drive:

• Market impact: Larger, more significant launches can create more buzz and media coverage, generating greater market awareness and excitement.

• Efficiency: Coordinating marketing, sales, and support efforts for a single, comprehensive launch can be more resource-efficient. Teams can focus their efforts on a few key moments throughout the year.

• Customer experience: Customers receive a more substantial update with multiple new features at once, which can be more compelling and show a significant leap in product value.

Here are some questions to ask yourself to make the decision:  

• Customer needs and expectations: How quickly do your customers expect new features or improvements? Are they willing to wait for bundled updates, or do they prefer immediate access to new capabilities?

• Competitive landscape: How quickly are your competitors releasing new features? If the market moves fast, quicker, incremental releases might be necessary to stay competitive.

• Product complexity: Is your product complex with interdependent features that benefit from being released together? Or can features be independently launched without causing confusion or integration issues?

• Internal resources and capabilities: Does your team have the capacity to support continuous delivery? Do you have the resources to handle frequent launches in terms of marketing, sales training, and customer support?

• Strategic goals: What are your company’s strategic goals? Are you aiming for rapid market penetration, or is the focus on building a robust, stable product with periodic major improvements?
  

In terms of buy-in from Product - coming to the table with data and insights is usually effective. Share historical performance, customer feedback, and competitive analysis to justify the strategy.

I worked at a startup who took pride in the fact that we launched new features with every sprint. It sounded like innovation to talk about how we released X new features that year, but the reality was that customers didnt know what was a thing they needed to care about vs what was just noise. Because there's no customer that NEEDs every feature that's launched.

I also worked at a large org that had three set launches a year. It felt like the magic of a specific product could easily get lost because it was abstracted into a large bundle.

So there's no set approach that will work for every company. I'd suggest you think about what the best way to resonate with your user base is and then flex your timing. There's nothing wrong with a feature that goes out when ready, but isnt marketed heavily until the bundle. There's also nothing wrong with launching something in a bundle but leveraging the bundle as the launch vehicle where you also follow up post launch with an independent set of deliverables.

I'd recommend you consider a tiering approach where you have something (roughly) like a tier 4 launch is silent, and it just launches when ready and theres no comms around it. A tier 3 launch rolls out when ready, and maybe you do an in-product notification around it at launch and then its included in a blog or bundled webinar at launch. A tier 2 launch GA's at the time of the bundle and most of the bill of materials falls into the bundle activities. A tier 1 launch is announced (or GAs) at the time of the bundle, but has a continued body of work to drive awareness and interest in the feature outside of the launch bundle.

This way you keep the value of the bundle, limit noise to your users but also dont water down hero features.

I'm a big fan of bundling, especially for small/medium (Tier 2/3) launches. You could bundle into a one-off launch, but I've seen more success at just setting a regular cadence for bundled updates, which lets your customers know when to look out for the latest from your business. Either way, these bundled updates are more consumable for the market, and it elevates standalone launches to an even higher level of importance with your key constituents.

With product -- I've had success raising a few points:

1. The public 'launch' moment and a dev release moment don't necessarily have to be 1:1. It can be ok to deploy a feature into prod (alongside docs, any other MVP info) but do the public announcement some time later -- the worry would be breaking your own news, though if this feature is big enough that it's newsworthy, then it might be one you want to elevate to a standalone moment anyway.

2. Bundling is also a way to get more visibility for your unique feature: by creating a bigger moment, we'll get more eyes on your feature. It also doesn't preclude us from doing targeted post-launch comms to targeted audiences, e.g. in-product messages, working with lifecycle/growth marketing, amplifying via sales, etc.

This is a question that comes up at every company I work with or talk to. As product teams have moved towards continuous delivery, there's a desire to just launch new features whenever they are ready. This is often not the most ideal thing for customers however and we as product marketers need to advocate for our customers! I would recommend working with your product and engineering to come up with a release cadence that makes sense for your specific customers. For companies with large enterprise customers, this may mean more infrequent launches like monthly or quarterly. For companies with SMB customers, you may find weekly or bi-weekly is ok. But I have never met a customer that was ok with a totally unpredictable schedule of new features appearing in the software they use!!

Now that feature flagging has become more common, you do have more flexibility. Your product teams can leverage flags to show new features to only a subset of customers, like alpha or closed beta participants first, then maybe moving to a more open beta, and finally opening it up to all customers. This can help balance the desires to push product out quickly with the needs of some customers to not see changes in the products they use. You may even need to limit changes for certain industries - for example not touching your retail customers' environments in November and December.

Regardless of when the feature goes live in the product, you as product marketing can still decide not to "launch" it externally until you are ready. For example, you might have a big feature that you want to save to talk about at a live event. Or you have a set of connected features that are coming out over a period of a few weeks and you want to launch a single press release and external push around the whole set to make your launch more impactful. I would definitely advocate for understanding the bigger picture before you do your external announcements even if you are making a feature live inside the product.

I don’t agree with the strategy of “holding” back feature launches for a regular launch cadence. Tech moves fast and you should be constantly shipping. Launch the feature when it’s ready. However, you can make a bigger splash later with a big market moment or by bundling features together. Don’t worry too much about re-marketing your feature in this scenario. Bundling features together is a great way to…. Getting your feature in front of your customer often and in different ways can be beneficial. 

If you’re launching a big new product, then it makes sense to make a big splash with a market moment.

Bundling launches can drive efficiencies of scale and impact of message. If there is a Tier 1 launch, that is the primary and sole message/launch for that quarter. At other times, we bundle features/capabilities being shipped in a quarter to ladder up to a larger theme. The marketing channel mix will also look different based on the approach.

I wouldn't disrupt product's release cycle. If they want to push new capabilities and product updates during a 2- week sprint, thats great! You can even inform customers and partners about what new at a high-level (think what benefit does it provide me today).

However, for external launch announcements, I'm a big fan of bundling items together to help tell a larger, more cohesive story.

You need to be flexible though. There will be times where a release will have a feature that is big enough for its own announcement. In these cases, hopefully you're close with the product team and have had enough notice that you can craft a standalone GTM strategy around it.