SaaS Blogs

One of the much-touted benefits of single instance, multi-tenant SaaS is the ability for ISVs to respond to market demand and introduce new functionality and versions of their application to their entire customer base relatively easily. In other models, this was a nightmare and would actually dis-incentivize creativity and “staying ahead of the game.” This was understandable since the cost of distributing a new version was significant so it happened conspicuously as a major event in the lifecycle of your application. SaaS, however, encourages a continuous flow of new functionality to customers along with a “community feedback loop” to quickly absorb reactions and execute compensating actions based on that input.

One issue I have when people tout the aforementioned benefit is that it’s always from the R&D side of things. SaaS can also offer the same benefit from the pricing and business strategy side. This is true, however, only if the SaaS offering was built to support flexibility in that fashion. Let’s look at the antithesis of flexible business capabilities. Your company has architected and deployed the world’s greatest SaaS offering. It’s single instance, multi-tenant, scalable, and you can roll-out new functionality at the drop of a hat. Things are going smoothly until one day, the VP of Marketing comes in and says that their is a huge opportunity if we can reorganize the applications feature set to target certain verticals, and that the pricing strategy needs to move from monthly to quarterly in the existing segment in order for growth to continue. Oops, we didn’t think about that. The VP of Marketing has the authority to make that sort of strategy decision, but the app doesn’t care. It  was built with all the technological bells and whistles, but no one put thought into allowing the business folks in your company to independently make decisions without requiring R&D to intervene and make code changes. You’ve effectively architected an application that hampers the companies ability to “think on it’s feet” and make either reactive or proactive moves.

The key when building a SaaS offering is recognizing that it is the center of interaction and discussion at your company. How responsibilities are divided up in your organization and how the different teams and departments interact with it must come up in conversations related to implementation. You should ask yourself questions like:

1. Can we roll-out new functionality or bug fixes easily?
2. Can sales & marketing reorganize how the application is sold or marketed without intervention from R&D?
3. Can support teams gain access to normally sensitive or restricted information (such as execution logs, etc.)?

The more you can integrate your business’ concerns into your implementation decisions, the more agile and responsive you can make your business.

Do you feel that agility is under-appreciated and/or under-utilized in the SaaS model?