Cloud computing has been around for a while now. Most of the unicorns of today have been built on cloud technology taking advantage of its scalability on demand. But the established big enterprises have been slow in making the move to the cloud. As difficult it is for the enterprises to make a move from using on-premise software to a SaaS-based, similar is the situation with the enterprise software companies developing it. The transition from an on-premise offering of software not just needs a tectonic shift in the technology and architecture of the product but also in the product strategy, engineering processes, organization culture, product culture, and partner ecology.
Product Strategy:
Helping your customers/users transition from on-premise software to your SaaS offering would really need a well thought and well-rounded product strategy. It is very different then just making your customers move to a newer version of your on-premise software, that itself is not easy in most cases with the enterprise customers. Most of the enterprise software companies who have been unsuccessful in helping their customers make a decision for transition to cloud have missed three critical points, which is about serving the three broader personas as per the Jobs to be Done Framework. These three personas are:
- The product Lifecycle Managers.
- Product User
- Decision Maker.
To Serve the Product Lifecycle Managers
Transition roadmap: Enterprise customers are invested in your on-premise software in terms of their business continuity and data. So, having a transition roadmap from on-premise to the SaaS offering is of utmost importance especially for the ones who will be responsible for maintaining the lifecycle of the product implementation. The transition roadmap that you present has to take care of 3 dimensions:
- Customer’s existing data.
- Customer’s existing licenses
- And the delta in learning.
To serve the Product Users
Build a value proposition: Customers invest in enterprise software to solve a problem. And if their existing investment in your on-premise version still serves them well, they do not really have a reason to move to the cloud, just because you think it makes sense for your business. As a product manager, you will have to expect a lot of resistance from the customers of your existing offering. What will help you drive your SaaS offering right through that resistance of the users is the higher value proposition that you provide? The functionalities that you support should be on-premise++ along with a faster time to market and a reduced learning curve.
To serve the Decision Maker
Pricing: When pricing your product, you will have to take care of one thing, that is the perceived value you are providing through SaaS in terms of reduced CAPEX for installation hardware(CV), faster time to market(TMV), richer functionality(FV), better user experience(UXV) should outstrip the subscription cost of your SaaS offering. Below is the simple equation form to imprint it in your brain.
CV + TMV + FV + UXV > Subscription Cost
Engineering Process:
One of the biggest changes that happen when moving to the SaaS model from on-premise is the delivery cycle. The on-premise delivery cycles are longer, typically with one major release a year and bug fixes through the patch updates as and when required. Not only the engineering team’s mindset but also the engineering processes are tuned to these longer delivery cycles.
While moving to SaaS means monthly releases. Monthly releases in SaaS results in immediate update of the software for all the customers and thus instantaneous adoption and super short feedback time on the release. Unlike on-premise were developing and packaging and making it available to the customer was the only goal, SaaS brings in additional responsibilities of getting the software piece deployed, making sure there is a minimum downtime to the customer install, their existing data is not lost, and essentially what was working and not changed is definitely not broken. But when you are pushing a new piece of software every month, it is not possible that it is flawless every time. So, to make sure the customer experience is good and the impact on their business due to the issues in the software is minimum, the bug fixes need to be delivered efficiently with the least possible lead time. To make this happen you need to have:
- A comprehensive DevOps strategy in place, and as part of it a mandate should be to have very elaborate test automation in place as well.
- To ensure there are least hiccups in your operations, for the software deployed on a public cloud, you need to have the ability to predict and be proactive about the infrastructure issues, application issues, and network issues. I am not asking you to be a soothsayer or to hire one but adopt AIOps to automate your operations and make it predictable too. This will become an input to the DevOps making it really effective.
Organization Culture:
If the teams have always been shipping on-premise software with longer release cycles, onus on the service partners/customer teams to install and maintain it on the customers hardware, it will take a lot of conditioning from the organizational culture perspective for the same team to adopt the SaaS mindset. You may have question, what is so different?
Difference is in the business model. It is now a mix of product and service delivery. This change in business model virtually effects all the departments of the organization and not just the product teams.
Sales Team: For sales, it is no longer about selling licenses and then showing up for renewable, but about getting customers to subscribe and then adopt the SaaS offering. With no hardware CAPEX involved, the only way Sales and pre-sales can keep the customers interested and invested in the SaaS offering is by aligning with the customer’s goal, solving his/her problem, and making them successful.
Product Team: Apart from the inbound activities to make sure the right product is getting build and delivered they will have to ensure that the customer is being apprised frequently about the offering, the new features, the new use cases being served the road map through various modes of information delivery. They also have to be a bridge between the presales and the engineering to ensure customer success and be brothers in arms with presales for the adoption.
Engineering Team: The engineering teams are no longer just responsible for shipping new functionalities in the software but along with the operation folks, also have to ensure the SaaS offerings high availability, scalability, and a minimum impact on the customer’s business due to maintenance or fix deployments.
Product Culture:
When an organization plans to move to offer its software as a service (SaaS), it also has to ready itself from the product culture perspective. The reason is, with the SaaS offering you are not just offering a product that solves the problem, but you also manage the installation for your customer and thus you are in a service business as well. The availability of the environment and hence the business continuity is an expectation that the customer would have from the product team. To build this mindset, you will have to build a product culture where:
- Product and Ops teams collaborate to own the SaaS availability SLA.
- Support and Product teams to work together for a quicker turnaround time for the issue resolution.
- Product Management and Sales working in tandem for better adoption to make the customer successful.
Partner Ecosystem:
Like for any enterprise on-premise software, a strong partner ecosystem is very critical for the success of your SaaS offering. With the aim of SaaS offering replacing the on-premise one, you will be stepping onto the maintenance business along with the reduced implementation lifecycle (if you have developed your SaaS right) of your SI partner. To keep their business interest on in your SaaS offering, so that they advocate about the product to their customers, for whom they are the trusted advisers. But to make this happen, you will have to invest in the partner ecosystem by:
- By offering free periodic Product Trainings: This will help your SI partners to build the skillset in their organization and be ready with the bench strength for future projects.
- Support for POCs and Implementations: In the initial phase of the product growth you should be ready to help your SI partners with both the POCs and also with the actual implementation when and where required.
- Building Extensions: Help build SIs develop extensions on top of your products, which will help them serve the niche use cases of your and their customer. This will help them stay invested in your SaaS offering as a partner.
Identifying the areas that would need the desired changes and strategizing and executing to help make the transformation as smooth as possible would need some serious Leadership in the organization.
Cheers!
Very good to one
Thanks…