Best Practices

The Great De-coupling: Product Shipping and Product Launch

In my prior life at a very large, very traditional software company, releases were very regimented. We shipped code twice a year: once in May, and again in September (and since everything was on-prem we really did ship it). Every product team in the organization knew when the ship dates were, and delivered against them.

Product marketing, for its part, centered around these two big calendar dates, and everything was in sync.

Now, working at a dynamic hyper-growth startup, I’ve found myself having the same conversation over and over again with different teams in our company: product shipping and product launch are most definitely not the same thing. This would seem to be self-evident, but what I’ve come to realize is that in the Agile/SaaS software world this distinction is actually a bit confusing.

What’s Different Now?

In the software industry today, the notion of structured releases is quickly going away. Agile and Dev/Ops practices push the idea of continuous delivery, and cloud deployments make it super easy to push new functionality out to customers. We typically ship code as often as twice a week.

How do you effectively announce and market your releases around a schedule like this? The answer is: you don’t. You don’t adhere to the schedule that is. The effective approach for SaaS companies to fully de-couple product launches from the shipping of code.

What is a Launch Anyway?

One might think that a product launch is the external announcement of new products or features. This is true, but only partially. Yes, product announcements are a key part of launches, but they are also opportunities to showcase company momentum, build brands, and share a market vision with a broad audience. Effective launches combine internal enablement, communications, and cross-channel marketing execution.

Launches are often tied to specific moments in the marketing calendar which is another important argument for de-coupling. They often align with large industry events or your own user conference. Aligning launches to these moments allows you to get a broader reach for your message, but they don’t always coincide with when code is ready to ship.

Does that Mean Holding Back New Features?

No. Separating launches from shipping doesn’t mean not shipping features. Launches are primarily about external communication and promotion. Most of the recipients of that message will have no idea that a specific feature has already been live in the product for a month. Conversely, that means you might also end up announcing features before they ship (although in this case, the announcement should generally indicate when the product or feature will be available).

Separating the outbound marketing activities from the actual product delivery makes sense for SaaS companies, but it doesn’t absolve the product marketing team from any responsibilities when product decides to ship new code. New features that make their way into the product need to be communicated to product users, and internal sales and customer success teams – even if they aren’t launched externally.

Defining Launch Tiers

A good way to manage launches is through a documented tier system. We break product updates into three categories:

  • Tier 1: Minor feature or update – Internal enablement and customer communication only
  • Tier 2: Medium feature or functionality – Some external communication (Website and/or blog announcements), and sales aids included alongside Tier 1 activities.
  • Tier 3: Major announcement – Generally the cornerstone of a full marketing launch. Launch activities include press outreach, cross-channel communications, and additional marketing execution such as specific events or webinars.

The specific tactics, content, and enablement associated with each launch tier are documented and shared broadly across the company so teams know what to expect. Because marketing launches are often separate from actual feature delivery, we have some flexibility in the approach. For example, the first rollout of a feature might have Tier 1 coverage, but then in conjunction with an event, we’ll add Tier 2 components. Or a series of Tier 2 announcements might roll up into a larger Tier 3 launch.

Delivering Product Marketing Sanity

Our tiered launch approach and the separation of marketing launches from product delivery allows our team to maintain a sense of sanity, and it also allows us to deliver more coherent messages to the market. At the end of the day, the mission of the product management and product marketing teams is different. Shipping code quickly and regularly is important to get users interacting with new features, and allows you to gather feedback. Marketing launches are about maximizing reach and awareness for the organization. De-coupling makes both teams more successful.