SaaS Upgrade Maturity Model
As of late, I’ve had a number of conversations with different individuals regarding release cycles and what SaaS companies currently do and/or should do with respect to releasing upgrades to their offerings. The biggest question is how to map the release to your customer’s needs. In many cases, it’s ok to release an upgrade to your SaaS offering and “force feed” the upgrade to your customers (i.e. they don’t have a choice regarding acceptance of your upgrade). In other cases, however, this could be a terrible mistake.
Let’s start with an example: imagine you are an ISV that writes software for helping manage law practices or that aides in litigation. Your law firm customers generally use your software in a mission critical, time sensitive fashion like managing a current legal case that is making its way through the court system and is worth millions of dollars. A midstream upgrade to your SaaS offering could be catastrophic for the law firm. Your changes could require some amount of retraining, could accidently introduce inefficiencies that were unintended, or might impact your customers in unforeseen ways. Any of these changes would mean that the imaginary law firm would be negatively impacted due to your upgrade, which is most certainly not the intent of an upgrade (Ask Microsoft, I’m sure they remember Windows ME). How can issues like this be solved? By supporting multiple versions! Before calling me a SaaS heretic, let me give some detail!
Ideally, the law firm in our imaginary scenario should have been able to opt out of the upgrade for a period of time, accepting an upgrade when ready. This would indicate that while some customers were on version ‘new’, others were on version ‘old’. In SaaS, it is wise for a SaaS ISV to take a “one version only” stance as a mantra during periods of non-release, but real world pressures exerted by customer needs should always come first during releases. SaaS providers can be bucketed into 1 of 3 buckets in the following maturity model:
- Level 1 (’The Blanket Upgrade’) - When you release new functionality or bug fixes, you release it at a specific point in time to all customers. At a minimum, it would be wise to give your customers fair warning (15 days, preferably 30) prior to the release. In sensitive situations, it will give your support team the ability to mitigate any disastrous customer service outcomes from an unexpected, sudden upgrade. What would be even better would be to a fixed release schedule (e.g. ‘Every 1st Tuesday of the Month’) so that they have foreword expectations and can plan accordingly.
- Level 2 (’The Grace Period Upgrade’) - A new release is released in batch at two points in time. Customers are notified of an upgrade and are given the option to ‘opt out’ of the first upgrade date and delay their upgrade to the second date.
- Level 3 (’The OnDemand Upgrade’) - Level 3 is one that intrigues me the most. Customers are notified of a pending release and are given a time span (say, 60 days) during which they must upgrade. They can invoke the upgrade at any point in time within the 60 days, or be forced to upgrade on the 60th day. This puts upgrade control in the customer’s hands, within boundaries. Generally speaking, this would require a highly automated architecture.
Part of the upgrade process that applies at all 3 maturity levels would be the ability to have ‘preview access’ to the new version prior to releasing. This would allow customers to retrain staff and understand changes to the offering outside of normal operational constraints.
Which maturity level seems to be most common in the marketplace? If your organization functions at any of these levels, what has your experience with that level been and have you considered maturing to a higher level?
The SaaSBlogs group on LinkedIn now has 1300+ members and it’s growing every day; make sure you are not missing out and join today.
Links
View Technorati Links
SaaSBlogs Tags
Tagged with: application lifecycle • SaaS • saas upgrades
(1 votes, average: 5 out of 5)
Loading ...
Sinclair - I’ve worked with an application very much like you describe. A couple of interesting things from the experience:
Process/feature changes that positively impact usability and productivity are excepted immediately - however, in many cases those should be considered for monitization. Depends a lot on the competitive atmosphere.
Feature changes that require “relearning” with no apparent usuability or productivity bonus are roundly rejected and likely to lower user retention. It doesn’t mean they aren’t necessary in some cases however for reasons the users aren’t aware of. Making them aware of the deeper issues is key in this situation.
But the worst case scenario is when a change requires API restructure and integration realignment. Planning this level of upgrade can be very difficult when customers have a significant investment in integrated apps.
In the first case, I can see the positive upgrades being pushed out immediately - in coordination with marketing of course.
The second and third situations would require your “level 2″ or “level 3″ upgrade, but there is also a very serious service component both helping customers understand potential issues and in some cases helping them test and prepare for the upgrade. In SaaS we are selling service, in some cases added service ($) and retention is king.
So, I wouldn’t necessarily call this a “maturity level” decision - it is more a matter of the product manager, QA, and service team having a way to evaluate changes and determine which plan works for an individual situation. There are going to have to be some parallel versions during testing and in some cases evaluation or “beta positive” users that allow themselves to be pushed to the new version as soon as it is ready. Getting to that discussion before release is where the maturity comes in.