This is part of a series of posts focused on the life cycle of a SaaS customer. The first post is here, and the previous post about new releases here. This is the final installment in this series.
This final step in this series is crucial for all SaaS organizations. That is not to say that installed software companies aren't interested in renewing contracts, but the financial implications are slightly different. I have written about monthly recurring revenue (or more importantly contracted monthly recurring revenue) in previous posts. This is one of the key measurements of a SaaS organization's health and worth. If there are investors this is one of the key numbers they will likely focus on. If your organization is looking to take on investors this is a key number they will likely focus on. Did I mention this is an important number?
Hopefully contract renewal was an issue that was addressed during the sales process. The initial contract certainly included terms like price and length of contract, but hopefully also included language around how the renewal process will work. There is a balancing act to walk here in that obviously the longer the contract the better for the organization providing the software, however enterprise clients may resist lengthy contracts, especially if they are still new to the SaaS concept.
The flip side of a lengthy contract is that it will likely also lock in pricing to some degree during the term and subsequent renewals. It doesn't really matter what your pricing model is: a per seat basis, a feature basis, or some other model the contract price will likely be allowed to increase some set amount with each subsequent contract renewal or calendar year. This means that a client who is an early adopter of your services may end up with a very modest increase in their fees if they continue to renew for a long period, say an additional two, three or four contract terms. This may or may not be a big deal, however it is one that should be entered into with eyes open.
Since this blog is focused on SaaS for the enterprise I would be remiss if I didn't mention procurement. It is likely that at renewal time there will be a formal procurement process that is invoked. It is important to understand this process as much as possible and rely on your internal champions within the client to help guide this process. Many enterprise organizations have a procurement process that runs in cycles, say every 2 or 3 years, so if you have a one year contract with the option to renew at annual intervals it is important to understand how that will work. If you are lucky it might mean no formal procurement process until the next cycle or until the contract dollar amount hits a certain threshold.
One way that you can help your internal champions make the case for contract renewal is to ensure that there are tangible numbers that can be referenced when speaking to budget holders. This falls into the best practices / relationship management category but helping the internal units who are using your software build a case with metrics that are legitimate and easy to understand should help make the renewal process smoother and more likely.
There shouldn't be any surprises about whether a client is or isn't going to renew their contract. Speaking with clients about contract renewal well in advance is to everyone's benefit. The more transparent the process the better it will be for all involved. If there are issue with the product offering, or issues with service levels, etc the sooner they can be addressed the easier it will be to ensure contracts get renewed.
I would also strongly encourage internal teams to be transparent and honest when looking at contract renewals. This should also follow into the revenue projection and budget process. If a large client is unlikely to renew then having a revenue plan and budget impact if they choose to renew as well as if they choose not to renew is a worth while exercise. This also helps set internal expectations and a better informed internal leadership team. If your organization has investors or board oversight transparency around contract renewals is crucial for honest communication about the financial well being of the organization, as well as for where budgets might need to be adjusted to fit new goals (say increased client retention or ability to increase billing by rolling out new features on a more frequent basis for example).
Clearly this series of posts is far from exhaustive in relation to SaaS customer life cycle. I will follow up on some of the concepts presented in this series of posts over the upcoming months.
Monday, April 6, 2009
Monday, February 9, 2009
SaaS Customer Life cycle - New Release
This is part of a series of posts focused on the life cycle of a SaaS customer. The first post is here, and the previous post about going live here.
So at this point client is up and running, let's assume they are wildly successful and the relationship is going well. As the account management team (or whatever language your organization uses to describe this function) has been focused on sharing best practices and hitting all metrics the product team has been busily hammering out the latest version of the product.
Product Management and Product Development are discrete functions that are separate from managing implementations and relationships. This probably sounds like another obvious statement, but worth making. As tasks related to the core product require a different skill set than deploying and managing clients it is likely they are different teams within an organization. I am planning some future posts on both of these topics so I'll follow up on this thread later.
The challenges associated with pushing this latest version begin at the most seemingly innocuous place: What is this called? Is this an upgrade? Is this a migration? a push? some other word?
Upgrade and migration will typically trigger a whole host of associations for enterprise clients. Many of those associations are not pleasant ones, remember many enterprises are likely to still be involved with installed software. Think about the pain and costs associated with a migration or upgrade of some large installed software product, such as an ERP or HR system, especially if the system has been customized in any way (which is likely).
In addition to the possible negative associations words like upgrade and migration are likely to have, many enterprises are also likely to have a number of internal processes and procedures that are invoked once these terms enter the conversation. Some of the possible events that an upgrade or migration might trigger could include another round of UAT, additional security tests, and possibly having procurement getting involved if there are any costs associated. Ideally this issue will have been addressed during the sales cycle and also covered at the end of any implementation cycle, however it is pretty likely that the people involved in those cycles are either no longer attached to this project or have completely forgotten what was said during earlier phases.
All that being said there are three major aspects of all upgrades / migrations:
Each of these should be considered carefully with a detailed plan that is shared between all parts of the organization.
Client facing communication is seemingly straight forward, but the decision to communicate at all to clients is one that will likely come up internally, especially If many / most / all of the product changes are focused on items that clients would never know about (say security upgrades, or changes to the way the application handles requests, or communicates between layers, etc).
In those instances it is theoretically possible that a client would never know. It could be tempting to simply perform these upgrades without any notification to clients. I would say this a mistake. Long term relationships with clients are built and trust and trust requires transparency. The possible downside of communicating to clients far outweighs the risks of not communicating. If something were to go wrong during the process that impacted uptime, or any other metric, you would then be forced to communicate to clients that something went wrong while upgrading. This would certainly not contribute to an atmosphere of trust and partnership.
Clearly any significant new release that would impact end users in any way must be communicated to all clients and are subject to all the same concerns.
The specifics of what exactly to include in client facing communications and the tone will vary from release to release. It is a bit of a tight rope act. The goal is to help clients understand what is coming, all the great new stuff that is included and how it makes their lives (and programs) more successful. This is the true power of SaaS. At the same time by making a release seem like too much of a big deal can generate concern and/or any of the issues mentioned previously. Most enterprise clients are risk averse by nature so that is important to keep in mind.
The communication should go out with plenty of time for clients to absorb and ask questions and have the majority of their fears / concerns addressed. If your release cycle is once a quarter client facing communication is one of the things that could be a challenge.
The specifics of a release will need to be locked down and guaranteed to be included if they are to be communicated to clients. In many cases this may not be known until all coding and internal QA has been completed. If clients need time to absorb release information then an organization needs to set some specific internal policies around completed QA. For example if it is determined that clients need 2 weeks to absorb release information and ask questions and internal teams need one week to draft and finalize client facing communications that means the product team should have a milestone that says 3 weeks prior to live all features should be through QA and a determination as to the status (in or out for this release) needs to be made. This is a pretty tight schedule for a quarterly release timeline.
Production migration for code varies depending upon what stage of maturity of their SaaS offering. If there are multiple client instances running different code bases then that strategy would need to be different than singe instance of code for all clients. It seems most likely that most SaaS organizations are somewhere in between with multiple instances of clients running the same code base. Running through some test migrations in a development or QA environment should be considered a necessary milestone prior to any production changes. The product team would be well served by engaging with the implementation teams to determine what would be the best candidates for testing (which implementations are the simplest? Which are the most complex? Which have the largest user population, etc are all questions that can help find the right implementations for testing).
A cautionary note here: No matter how diligent any development team is about ensuring dev and/or QA mimics production as closely as possible there are likely differences. These can be seemingly small (say slightly different versions of an application server or lack of monitoring software) to large (say no clustering or load balancing in dev / QA). These differences, even the small ones, can lead to failure once code is moved to production.
Up to date and quality documentation of the production environment as well as dev and QA environment can help here, however it is rarely done. This kind of documentation is boring and dull. No one want to actually sit down and write this documentation, even fewer people are willing to keep it up to date. A good policy is to add a formal step to any production change procedure to update the production documentation. This at least increases the chance that production will be properly documented.
It is also important that all hands are on deck for production pushes. This should include the QA and dev team as well as the implementation teams and client services teams. Frequently the people who deal with specific client implementation on a daily basis are best positioned to know the most crucial things to check. Don't underestimate the value of those additional eyes and make sure there is a clear process for those people to report any issues they uncover as quickly as possible.
Production migration for infrastructure is related but slightly different than migrating code. A natural tendency is to try to link changes to infrastructure to an upgrade window for all the application code. I would argue this is a bad idea, unless the new infrastructure is tied to the new code specifically. This introduces another variable into the process that exponentially increases the effort required to troubleshoot any issues that might arise. Ideally an organizations standard contract will include some sort of monthly maintenance window. It would be best to confine infrastructure changes to those windows as much as possible.
So this post turned into a much longer one than I initially thought. I should have probably broken it up into two parts. There is clearly more to say about this specific stage of a SaaS customer life cycle and I will try to expand upon these ideas in future posts. If you are still reading then kudos to you.
So at this point client is up and running, let's assume they are wildly successful and the relationship is going well. As the account management team (or whatever language your organization uses to describe this function) has been focused on sharing best practices and hitting all metrics the product team has been busily hammering out the latest version of the product.
Product Management and Product Development are discrete functions that are separate from managing implementations and relationships. This probably sounds like another obvious statement, but worth making. As tasks related to the core product require a different skill set than deploying and managing clients it is likely they are different teams within an organization. I am planning some future posts on both of these topics so I'll follow up on this thread later.
The challenges associated with pushing this latest version begin at the most seemingly innocuous place: What is this called? Is this an upgrade? Is this a migration? a push? some other word?
Upgrade and migration will typically trigger a whole host of associations for enterprise clients. Many of those associations are not pleasant ones, remember many enterprises are likely to still be involved with installed software. Think about the pain and costs associated with a migration or upgrade of some large installed software product, such as an ERP or HR system, especially if the system has been customized in any way (which is likely).
In addition to the possible negative associations words like upgrade and migration are likely to have, many enterprises are also likely to have a number of internal processes and procedures that are invoked once these terms enter the conversation. Some of the possible events that an upgrade or migration might trigger could include another round of UAT, additional security tests, and possibly having procurement getting involved if there are any costs associated. Ideally this issue will have been addressed during the sales cycle and also covered at the end of any implementation cycle, however it is pretty likely that the people involved in those cycles are either no longer attached to this project or have completely forgotten what was said during earlier phases.
All that being said there are three major aspects of all upgrades / migrations:
- Client facing communication
- Production migration for code, and I'll lump DB into this category
- Production migration for infrastructure.
Each of these should be considered carefully with a detailed plan that is shared between all parts of the organization.
Client facing communication is seemingly straight forward, but the decision to communicate at all to clients is one that will likely come up internally, especially If many / most / all of the product changes are focused on items that clients would never know about (say security upgrades, or changes to the way the application handles requests, or communicates between layers, etc).
In those instances it is theoretically possible that a client would never know. It could be tempting to simply perform these upgrades without any notification to clients. I would say this a mistake. Long term relationships with clients are built and trust and trust requires transparency. The possible downside of communicating to clients far outweighs the risks of not communicating. If something were to go wrong during the process that impacted uptime, or any other metric, you would then be forced to communicate to clients that something went wrong while upgrading. This would certainly not contribute to an atmosphere of trust and partnership.
Clearly any significant new release that would impact end users in any way must be communicated to all clients and are subject to all the same concerns.
The specifics of what exactly to include in client facing communications and the tone will vary from release to release. It is a bit of a tight rope act. The goal is to help clients understand what is coming, all the great new stuff that is included and how it makes their lives (and programs) more successful. This is the true power of SaaS. At the same time by making a release seem like too much of a big deal can generate concern and/or any of the issues mentioned previously. Most enterprise clients are risk averse by nature so that is important to keep in mind.
The communication should go out with plenty of time for clients to absorb and ask questions and have the majority of their fears / concerns addressed. If your release cycle is once a quarter client facing communication is one of the things that could be a challenge.
The specifics of a release will need to be locked down and guaranteed to be included if they are to be communicated to clients. In many cases this may not be known until all coding and internal QA has been completed. If clients need time to absorb release information then an organization needs to set some specific internal policies around completed QA. For example if it is determined that clients need 2 weeks to absorb release information and ask questions and internal teams need one week to draft and finalize client facing communications that means the product team should have a milestone that says 3 weeks prior to live all features should be through QA and a determination as to the status (in or out for this release) needs to be made. This is a pretty tight schedule for a quarterly release timeline.
Production migration for code varies depending upon what stage of maturity of their SaaS offering. If there are multiple client instances running different code bases then that strategy would need to be different than singe instance of code for all clients. It seems most likely that most SaaS organizations are somewhere in between with multiple instances of clients running the same code base. Running through some test migrations in a development or QA environment should be considered a necessary milestone prior to any production changes. The product team would be well served by engaging with the implementation teams to determine what would be the best candidates for testing (which implementations are the simplest? Which are the most complex? Which have the largest user population, etc are all questions that can help find the right implementations for testing).
A cautionary note here: No matter how diligent any development team is about ensuring dev and/or QA mimics production as closely as possible there are likely differences. These can be seemingly small (say slightly different versions of an application server or lack of monitoring software) to large (say no clustering or load balancing in dev / QA). These differences, even the small ones, can lead to failure once code is moved to production.
Up to date and quality documentation of the production environment as well as dev and QA environment can help here, however it is rarely done. This kind of documentation is boring and dull. No one want to actually sit down and write this documentation, even fewer people are willing to keep it up to date. A good policy is to add a formal step to any production change procedure to update the production documentation. This at least increases the chance that production will be properly documented.
It is also important that all hands are on deck for production pushes. This should include the QA and dev team as well as the implementation teams and client services teams. Frequently the people who deal with specific client implementation on a daily basis are best positioned to know the most crucial things to check. Don't underestimate the value of those additional eyes and make sure there is a clear process for those people to report any issues they uncover as quickly as possible.
Production migration for infrastructure is related but slightly different than migrating code. A natural tendency is to try to link changes to infrastructure to an upgrade window for all the application code. I would argue this is a bad idea, unless the new infrastructure is tied to the new code specifically. This introduces another variable into the process that exponentially increases the effort required to troubleshoot any issues that might arise. Ideally an organizations standard contract will include some sort of monthly maintenance window. It would be best to confine infrastructure changes to those windows as much as possible.
So this post turned into a much longer one than I initially thought. I should have probably broken it up into two parts. There is clearly more to say about this specific stage of a SaaS customer life cycle and I will try to expand upon these ideas in future posts. If you are still reading then kudos to you.
Subscribe to:
Posts (Atom)
