Now that you have done all the hard work in identifying the set of problems to address and have also got the required approvals. It is now the time of defining when and how are you going to ship these features. The frequency of releases and the features you ship with them shall play a pivotal role in the success of your product.
Many organizations have a formula of release bus or a train which you need to catch to ship the feature. You need to plan your dates and tasks in a way that you do not miss the defined bus/train. These Release bus or Train, also popularly known as the Release cycles have evolved over many years.
Let’s look at some of the release cycles that exist and also some of its pros and cons. These shall help you in how should you define release cycles for your product or help in streamlining existing processes.
Major release followed by Minor release
If you look at some large software companies, in the early days of software development, most software companies planned out releases much in advance. This approach is followed when product is in growth stage. Usual time frame is between 3 and 6 months. All major expectation from product are to catered through these releases. There is a subsequent minor release to address some bugs left unaddressed. This would take care of any glitches or issues introduced by the major release.
This approach, as good as it sounds is difficult to implement for many reasons. Since the duration is so long for a release to be shipped, any on the fly changes should not be acceptable. I have had experience with an ever-changing release plan, and it became really challenging to handle these situations with customers. You could have customers asking for something else than what you build. Your competitor comes up with some new ideas better than the ones that you had thought of. This approach could work well only if you have set a customer base and there is not much pressure coming from the competition.
The Monthly or Weekly Releases
Post introduction of Agile, companies started rolling out releases every month, every fortnight and in some cases even every week. This may be a great idea for a product in the inception or the growth stage. This release model is has a defined timeline by which you should ship out a set of features. The underlying idea here is to keep the customers engaged with new and possibly innovative features. This may well be good practice for a B2C organization, however, it will not work well for a B2B organization. In my experience of B2B organization with frequent releases, customers complained of too many frequent changes and unable to keep pace with the feature set there were released. SPOCs on the customer side will have to communicate these changes to various stakeholders as well.
A peculiar challenge that needs to be addressed with such a shorter release cycle is to define what needs to be addressed. Since you have a release bus to catch, and you need to be effective too, you might end up taking a call which may not really be in the best interest of the product. You might let go of some bugs or scope creep a feature.
Agile and Release cycles
Agile is a development methodology, which was created for short iterative development. If you have a bi-weekly sprint and ship products every week, it does not mean that you are following Agile. Neither does Agile mean that you have sprints being followed for 6 months and you do not ship out any features at all.
The idea of your release should be that features introduced should be usable by the end customers, serving their basic use case. In reality in the name of Agile, many releases end up just shipping, which is not effective enough. So if you are just sending releases for the sake of staying neck to neck with the competition, it is not really helping.
Defining Release Cycles for your Product
While we look at various challenges with the release cycles, there is no single rule or decisive factor that defines how a release should be defined. However, there are various factors that you can use to define how and what should your release cycle look like. It is expected that you have factored in engineering capacity while defining the scope.
- Is your software a B2B or B2C
If you are a B2B company, then refrain from shipping out weekly or fortnightly releases. It is better to stick to either a monthly or a quarterly release. Defining whether to go for a monthly or a quarterly release will depend upon various other factors as well.
If you are a B2C company, you should ideally ensure to use releases to engage your customers. However, not all releases will be to engage customers. You need to focus on only several releases a year, maximum 5 -7 for mega features, 5-7 for medium-impact releases and rest all purely bug and performance fixes. - How strong is the competition in your Business
If you have very strong competition in your business, then you cannot stay behind. If your competitor ships a release a fortnight, your releases cannot come out in once a year or thrice a year. You need to keep up with the pace of innovation within the industry.
If you are in moderate to low competition business, you can define the release cycle in a way to stay ahead of the curve. Maybe a release a quarter shall be good enough. - How efficient is your delivery infrastructure?
One key aspect Product managers might not have control over is the Post development process is the post-development delivery process. If you have a lengthy and elaborate process for each release, try and reduce the cycle time to ship often. If that is not possible, shipping often may not be a great idea. - How complex in terms of integration and system knowledge is your IT landscape?
Basis the software shipped, how often does your partners or customer will have to make changes, is a critical attribute. If your tool allows multiple integrations, making many changes anyway may not be a great idea. If the releases go as independent packages without any connectors then the frequency of shipping shall be independent too. - Leave out enough scope for Bug fixes
While defining the releases, quality is of most importance. While you may have taken care of all the bugs before shipping, keep enough buffer to fix issues that arise post-launch. Historic issues can be a great guide to identify how time should be allotted. - How mature are your products
One key factor in defining releases would be at what stage your product is and how often should you ship. If you are at the inception stage, you can afford to and you should ship often. In the growth stage again, you might want to focus on features with 10x returns. This is when there will be a lot of attention to your future roadmap. In the maturity stage, you may follow the major release followed by a minor release model. - On-Premise installation or SaaS-based model
If you have an on-premise installation, the releases that you ship may or may not get implemented. Whereas the SaaS model will always be expected to deployed and being used. If you are still in In premise model, shipping many releases may not be a great idea.
Once you finalize the release plan out, do review it regularly. Also try and educate all the members and not just key stakeholders about how releases work.
Also Read – How to prioritize better
References
https://www.mobilespoon.net/2019/01/product-shipping-why-i-love-shipping-so.html
