A product release is the launch of a new product or a combination of features that will provide value to customers or users. Digging deeper, a release is much more to both your customers and internal teams.
For your customers, it's a promise of new value they can look forward to embedding in their everyday work and activities. For your internal teams, a release helps them plan their work and when they'll be needed to launch great products.
When we talk about releases, teams often confuse the roll-out of new features from your backlog (a deployment) with the total customer experience. A release is not just the act of providing access to new technical functionality. Instead, think of a release as the date when the company is ready to deliver a new customer experience and support every customer interaction point associated with it.
Releases should take into account all the additional work that must be accomplished, such as updating the public website and training the customer support team. While the supporting teams (like development) may define a release through their lens of deploying code into production through a series of sprints, the product owner incorporates this perspective (and those of teams and customers) into a complete delivery.
In agile development, you may feel that there is no need to plan actual releases -- and some may consider the term "release planning" obsolete in an agile world. But the value of releases is methodology-agnostic.
Releases define your themed product journey, and represent major launch milestones for that overall journey.
You may choose to call it a "launch," an increment, or some other name. Regardless, it is still a new offering your customers will anticipate and ultimately expect. In addition, your internal supporting teams must accommodate the plan in their schedule if they are to assist your efforts.
A release -- and the plan to get there -- provide your customers a vision into the journey they'll be taking with your product. The release and its place in the journey also provide your teams valuable information on when they may need to engage on a dependency or market a new innovation (as just a few examples).
In an agile world, the actual dates of engagement may have less precision as far as committed targets. However, a general delivery plan - even in an agile framework - will continue to establish trust and expectation in your product with your customers and teams.
Standardizing a release management process
A standard process may likely mean different things to a product management team and a development team. Both perspectives are strongly incorporated into a dependable release management process. A release management process incorporates all of the following:
An initial release plan takes into account the team's velocity on the previous release (or general capacity to deliver) and the feature prioritization to create a general scope, sequencing, and timeline for the release. During release planning, a general expectation on the number of sprints or iterations to deliver the scope is achieved.
The accuracy of this expectation and plan depends on whether the team's capacity is well-known as well as the level of detail (or grooming) the scope has been through during estimation. This general plan will also provide expectations of major product changes (or dependencies) for products that may depend on your roadmap or platform.
Plans will be revisited after each iteration. For this reason, a tracking of an external release target (with quarterly, monthly, or other precision) can be helpful. It will still set the expectation and trust with your customers, but can be refined by you as the plan progresses.
Phased communication and supporting team engagement
Product managers know best how to deliver their product successfully -- and that includes a series of non-development tasks of engagement with supporting teams to complete items like documentation, sales training, or marketing campaigns.
As a product manager, using a launch planning tool will enable you to create a "gold standard" for major delivery. Use this template to engage your greater team, who may be supporting multiple products in the portfolio only when needed. A standard for launch also sets expectation for when these teams will be needed internally.
Repeatable stages to readiness
Establish standardized status at both the release and feature level to indicate overall health of the plan. Status provides an "Are we good?" pulse point that can be key to seeing around corners and proactive risk mitigation.
A release status will enable communication to your internal stakeholders, while feature status workflows enable granular visibility into the readiness of the feature and its current status with respect to development, staging, or QA environments.
Regardless of whether your release plan is executed in sprints or via more waterfall methodologies, regular check-ins and adjustments to plan are necessary. Use your sprint closure to adjust plans as needed, or schedule regular reviews to ensure plans are on track.