{"id":77006,"date":"2021-11-04T11:42:36","date_gmt":"2021-11-04T11:42:36","guid":{"rendered":"https:\/\/www.prodpad.com\/?p=77006"},"modified":"2025-01-13T16:26:06","modified_gmt":"2025-01-13T16:26:06","slug":"release-planning","status":"publish","type":"post","link":"https:\/\/www.prodpad.com\/blog\/release-planning\/","title":{"rendered":"Planning for Success – How to Master Release Planning"},"content":{"rendered":"\n

Release planning can be frustrating, because it\u2019s essentially an attempt to structure something that\u2019s complex and unpredictable.

Sure, release planning provides an execution and phased rollout<\/a> structure for the product roadmap<\/a>. It helps you plot out what gets released to the market and when. But the process can also create a lot of stress and confusion among your team and users.

To avoid this, there are two fundamental best practices<\/a><\/strong> that I think every product and development team should adopt right away: separate hard and soft launches, and a release train cadence.

I explain these two practices in-depth below, then touch on three follow-up steps<\/a><\/strong> you should take after a launch and three common mistakes<\/a><\/strong> in release planning.

By the end of this article, you\u2019ll know how to master release planning and see more success with your product.<\/p>\n\n\n\n<\/a>\n\n\n\n

Release planning best practice #1: Separate soft and hard launches<\/h2>\n\n\n\n

Release planning is always beholden to the development process, which can be unpredictable. When things don\u2019t come down the pipeline as planned, marketing is left wondering what\u2019s going on (and their budget might take a hit, too).

One key to successful planning is to separate the soft launch and the hard launch <\/strong>for any software release<\/a>. In effect this is separating the project management of the app <\/em>release from the project management of the marketing<\/em> release.<\/p>\n\n\n\n

\n
\n

Here\u2019s how it can go:<\/strong><\/h4>\n\n\n\n

During the soft launch, a function is built and deployed behind a feature flag, available for a few users only. Marketing is informed and can select some favorite users, maybe a beta group.

These select users test the feature and ensure it\u2019s working. Bugs come to the surface (and fixes are deployed) before any official announcement and before your entire user base starts fiddling with it and filing customer support tickets.<\/p>\n\n\n\n

In the meantime, marketing can plan an official release\u2014the \u201cbig bang\u201d release\u2014which might involve a new landing page, email campaign, or plane in the sky.<\/p>\n<\/div><\/div>\n<\/div>\n\n\n\n

When the time comes, the \u201chard launch\u201d of this feature is just a matter of pressing a button to remove the flag in the app. And marketing knows they can confidently move forward with their side of the plan.<\/p>\n\n\n\n

Release planning best practice #2: Adopt a release train cadence<\/h2>\n\n\n\n

When a train comes every 20 minutes, you\u2019re less stressed about missing it than if the train comes once every two hours. The same is true in release planning.<\/p>\n\n\n\n

The release train process <\/strong>sets a frequent pace for routine software releases, prioritizing development work over deadlines. Whatever development work that\u2019s 100% ready will go out. If you miss one, no biggie! There\u2019s another release coming up soon. This week\u2019s release might be just a few bug fixes, next week\u2019s might be huge features. <\/p>\n\n\n\n

\n
\n

Continuously releasing in this \u201ctrain\u201d method is a great way to:<\/strong><\/h4>\n\n\n\n