What is release management?
Release management is the system you have in place that allows you to control the software development lifecycle, all the way from planning to testing then release.
It helps your team stay on track and work towards a common goal making sure that every member of the team is aligned.
In simple terms, the release management process ensures that your product is ready for production and release to end-users.
When managed and implemented correctly, it results in high quality releases and enhanced productivity allowing you to release more frequently and with less risk.
At the heart of an effective Agile roadmap is feature release management, which breaks down development into sprints and is more user-centered.
Keep reading: the most important elements to include in your Agile release planning.
Release management phases
The release management process is quite similar to the main steps of the software development process, that is the software development life cycle (SDLC), which consists of:
At the beginning, the product manager will plan for the new functionality by identifying a consumer pain point and how this feature will relieve it. They will answer questions such as what this release will do, how it will be used and who will use it.
They will then develop a strategy accordingly and start working on the product roadmap. The feature will then be built and managed through the various development cycles.
The manager will then need to decide on an appropriate release strategy depending on the use case, goals and budget.
The role of a product manager, therefore, revolves around managing product releases. In this guide, we’ll go into what we mean by releases and the type of release or deployment strategies that enable product managers to experiment and test their products to ensure optimal customer satisfaction.
First, in the planning stage, the product manager will gather feedback for ideas to start planning for a new feature. The product manager will determine a customer pain point and how it can be solved with this new feature.
The user persona and value proposition will be determined at this stage. The product manager will set up KPIs to assess the product’s success after release. He will then devise a plan on what it is needed to deliver this new feature and the expected release date, according to the following:
- Devise the team needed to build the feature.
- Define requirements and end-goals.
- Build a roadmap.
From product strategy to product delivery: Planning a release
Once a product strategy has been put in place, building a release management process is the next logical step. Such a process requires carefully planning the scope and phases of work and setting clear expectations and requirements.
A release plan will help each member of the team know what they need to do and the timeline of the work. It will lay out the priorities and the flow of the project. Other points to include in a release plan include:
- The product’s goal and roadmap
- New features to add
- Phases of work
- Estimate on deliverables
The product roadmap is an essential component to ensure success of your products. It will outline the strategy, vision and goals and will serve as a guide in order for the different teams involved to execute this strategy and keep everyone aligned and on the right track.
Therefore, a product manager is responsible for creating and defining a prioritized list of features to be developed over time according to the organization’s goals so it is usually formed in partnership with senior management and other stakeholders.
Developing an Agile roadmap will be far more flexible than a traditional one, allowing for shorter time frames and adjustments to accommodate changing priorities.
In Agile methodology, the product manager would be expected to release new features on a regular basis, whether quarterly, monthly or even weekly. Because an Agile methodology is user-centered, this means success will be measured based on user feedback, engagement, conversion, etc.
Once the release plan is in place, it is then time to plan for the actual release. There are many release or deployment strategies that a product manager should take into consideration depending on the objectives and the business needs as well as taking into account the impact on end-users.
Which teams are involved in the release process?
As already mentioned, a successful release will require cross-departmental support. Thus, the product team will need to coordinate with other teams, including:
- Product teams- this one is a given but for further clarification, this team may be small or big depending on the organization and consists of several roles with different responsibilities including product owners and product managers. The lines between these two roles often blur but still there are some differences between a product manager and product owner.
- Development- the product team will work closely with developers to draw out the requirements of the release and set the deadlines for each stage of the release. Once the requirements have been defined, the developers will create the documentation and design the functionality.
- Sales- this team will require training and to be provided with materials and documentation to be prepared to sell the product.
- Marketing- they will help develop effective communication around the release to educate and persuade potential customers to try the product.
There are also other more specific, technical roles within release management, besides product managers, which include:
- Release managers- they have a major role in release management, where they manage all aspects of the software delivery lifecycle.
- DevOps engineers- these engineers oversee the release of new code.
- Site reliability engineers- they create a bridge between IT and operations, create scalable and reliable software systems and remain on the lookout for any possible breakdowns in the systems in place.
Choosing a deployment strategy
There are a number of ways to deploy new features to production. Choosing the right strategy is essential and will depend on numerous factors including impact on end-users and the use-case.
There are what are referred to as ‘big bang’ deployments, where the whole application is deployed at once requiring longer development and completion cycles. However, such deployments are no longer practical in modern software development because of the high degree of risks associated such as outages and almost impossible rollbacks.
Therefore, in this guide, we have chosen to focus on four strategies that are within the phased deployments strategies and that are commonly used by organizations and modern teams.
Blue/green deployment is a technique that uses two production environments, blue and green, and traffic is directed to one of these environments once changes are ready.
Therefore, this type of deployment has two production environments but only is active while the other remains idle, which remains as a backup in case any issues arise in the active environment, allowing you to quickly revert to the idle environment while the issue is fixed.
There are many advantages to this practice including rapid release and simple rollbacks. However, blue/green deployment requires a lot of resources to maintain two production environments, especially for product managers who will require special software to track how their features are performing.
Read more on our blog about the pros and cons of blue/green deployment to determine whether it is a viable option for your team.
Canary deployment is a deployment strategy that decreases the risk of new releases by testing on a subset of users before rolling out to everyone else.
This means that you can choose a percentage of users to test on based on certain attributes and if no problems are discovered then you call gradually roll out to the rest of your users.
Canary deployment differs from blue/green deployment in that the former allows for more targeted releases, which is beneficial if the release is particularly risky. With blue/green deployment, it’s more of an ‘all or nothing’ strategy.
Keep reading: everything you need to know about canary deployments.
Ring deployment allows you to gradually introduce new features to different user groups to minimize impact. These user groups are represented as an expanding series of rings, hence the name.
Thus, this technique starts with a small group of users, such as internal users, until you gradually start to feel confident enough to target the release to all your users.
A/B testing a common release strategy used by product managers to test features in production with less risk. It is a strategy especially used for experimentation to observe and test which variation works best with users.
Therefore, A/B tests are used in feature testing where product managers can test out their ideas on their target audience by collecting data on feature performance in order to make informed decisions.
In this test, two versions of a feature or system compete against each other and based on preset KPIs, the version that resulted in more conversions or revenue, etc would be the winning variation and all users would then be directed to it.
This method is particularly useful for product managers as it allows them to test out their ideas on their target customers but with less risk. It allows them to keep testing different variations until they’ve found the perfect fit based on live users’ feedback.
Release gradually through phased rollouts
As we’ve seen, deployments could be ‘all or nothing’ or it could be done gradually in the form of progressive rollouts such as the case of canary deployments and A/B tests. Find out how progressive rollouts can help you deliver rapid releases and why they are an essential part of an Agile methodology in our progressive rollout guide.
As we’ve already mentioned, release management guides a product from development to testing and finally to production.
Implementing feature flags in your release management process could help in driving even faster and higher quality releases with even less risk. Through the use of feature flags, all new changes can be deployed and accessed by your end-users while any unfinished changes can remain hidden and wrapped in a flag until it is complete.
With feature flags, you decide the when and to who, giving you complete control.
All the deployment strategies mentioned above can incorporate the use of feature flags when releasing new features, whether through percentage-based releases in the form of canary deployments or releasing or hiding certain features in a ring deployment.
Just as feature flags help in faster deployments, they are also crucial if you want to do rapid rollbacks in case any bugs are discovered that need to be fixed before you release them to everyone else. Such rapid rollbacks give product managers increased control over the deployment process giving them the freedom to test their new features with greater confidence, allowing them to gather valuable feedback to improve their product. Find out when you will need to carry out a feature rollback.
Choosing the right release strategy
As we’ve seen, there are multiple ways to release a new version of an application or new features. Whatever strategy you use will depend on your objectives and budget.
Thus, the release strategy chosen will depend on many factors including:
- Your customer needs
- The type of feature you’re aiming to launch
- The goal or metrics you’re looking to achieve with this release
- Resources at hand
So, for example, if you have the sufficient resources to maintain two environments, as in the case of blue/green deployments, this will offer you ample benefits with little downtime.
However, if you’re limited in the budget and resources you can utilize and your release is more configuration-driven then your best bet is a canary deployment.
It will also largely depend on your business goals. On the one hand, if you want to roll out changes with little to no downtime then blue/green deployment is a viable option. On the other hand, if you want to test your features on a small subset of users then you could consider phased rollouts using feature flags, for example.
After release, it is important to keep monitoring releases for any issues that may come up so that they may be fixed immediately.
Third-party services such as Flagship by AB Tasty offer a sophisticated control panel that allows for teams other than development teams to monitor the flags that are being used and get access to reporting to determine if the release has met the KPIs set at the beginning of the experiment.
Such advanced features in a feature flagging platform give product managers more access control over releases without depending on developers.
Feedback is a central pillar to an Agile methodology and the idea of feedback loop, the process of continuously collecting feedback from customers and improving the product accordingly, ensures that the product you’re creating is delivering real value to your customers.
Why continuous delivery matters to product teams
As already mentioned, frequent releases are at the heart of an Agile methodology. Thus, maintaining an environment of continuous delivery is important.
This essentially means that teams release products in shorter batches and reduced time frames to get products out to consumers faster, which in turns allows them to gather valuable feedback to continuously improve their products.
Similarly, a DevOps culture is commonly associated with continuous delivery as both concepts aim to enhance collaboration between developers and operations team and both use automated processes in the software development process to achieve faster and more frequent releases.
Additionally, continuous deployment, which combines continuous integration and continuous delivery, is just as essential to product teams as the idea behind it is to make software readily available without human intervention. This means that it relies on a set of automated processes instead.
Find out how continuous deployment may be added to Agile product management.
Continuous delivery is vital to product teams for the following reasons:
- It allows them to release their products to market faster, which is important in order to respond to the demands of a fast-paced, ever-changing market.
- When teams release to market more frequently, they are able to achieve the aforementioned feedback loop at a faster pace rather than waiting to make a full deployment when it’s more riskier to release rather than releasing in smaller batches.
- This feedback from target customers allows them to improve their products, ultimately resulting in higher quality releases that meet customer requirements exactly.
As a product manager, you’ve taken careful steps to building the right product so you also need to be just as particular in how you go about releasing it.
To ensure that you’re delivering a top-notch release, you need to be testing in production on real live users as it is an essential best practice for any product manager.
Testing in production allows you to gather valuable feedback from the users who matter the most, allowing them to improve the product according to their needs. However, it is not only to improve but also gather ideas for future releases for features you might not have considered before.
Learn more about why testing in production is an important component of a product manager’s role nowadays by referring to this article as well as a more lighthearted approach to the importance of testing in production explained through memes.