Challenges of Enterprise SaaS
This article is a continuation of the Part-1 called Enterprise SaaS where I shared my own definition of the term.
As everything in Enterprise or large scale professional apps, delivering Software as a Service comes with a specific set of challenges.
On-premise bolting
The original legacy product does not exist in a vacuum. It lives in a decade old eco-system.
SaaS as a product model is often not an organic decision made by the product team based on extensive ethnographic user research. It is rather top-to-down executive decision aiming to change the company revenue model. An obvious shortcut is to take the existing on-premise product and deploy it in a cloud hosted environment — thus turning it into SaaS.
Currently available technology stack including Docker, Amazon or Azure is allowing teams to make this happen. It is even kind of cost effective to run as an array of single tenant apps to overcome the multi-tenancy gap. However, products that were never designed as SaaS would not magically turn SaaS in a hosted environment. There is no shortcut to a good design other that matching the product features to real user goals. And if real user goals are not in the cloud, a hosting model would not change this fact.
It is virtually impossible to retrofit the whole SaaS product experience, from effective try & buy, learning, subscription, product installation, and customization. The scope is just too big and there are many other tools involved living in the tribal knowledge product eco-system that are already used to configure, install, extend or customize the product. These products remain to be Remote Desktop limited versions of the original instances and they can't compete with organically developed single-purpose SaaS products.
Measuring the success
What gets measured gets done. Literally.
On-premise product teams are not used to transparently measure their own success. Typically it is someone's else job, but even if the data are available, they are very abstract to be used to improve the product itself. I am still surprised about how many product teams have no clue on basic metrics such as:
- How many users used my product last month? Last year?
- What is the revenue coming from new users over the last month?
- How many users used my latest release vs. other releases?
- What is the most frequently and least frequently used feature?
Enterprise selling is a tricky discipline, and with long renewal cycles and secured on-premise environments, it might appear that it is impossible to obtain the data. But even when some of the insights are available as reported metrics, they are not immediately available to the product teams.
Teams are often presented with abstract numbers that they can't effectively use to design the product or prioritize their backlog. NPS is widely accepted relative measure used to track product quality over the time and benchmark large product portfolios. I know it has its place in the UX Design toolset, however, I still share my skepticism and reservations towards NPS. I just happen to know too many hardly usable products with a relatively good NPS numbers and I never met a single one Agile team actively using NPS to drive their backlog.
Organizational silos
Turn data into insights. Insights into actions. Actions into outcomes.
When companies try to adapt to the SaaS environment, they use existing roles and organization structure to support a completely different product model. As a result, data are often tracked and insights are shared over powerpoint reports. But the following action is missing, and companies have no way to evaluate the outcome of these initiatives.
For a relatively simple activity such as Trial conversion funnel evaluation, it takes more than 10 different corporate teams to collect the data fragments. Each team is responsible a different customer journey step, making the communication around the single conversion goal almost impossible. The illustration bellow highlights, how the overarching ownership is just missing. Who out of 10 teams is responsible for the visitor's drop between Step 2 and Step 3? If the marketing team is responsible, what exactly (action) they can do to improve it (outcome) if they do not own the product backlog?
A true SaaS product is swarmed around the product and a strong Product Owner. It does not mean that a focused specialist is not involved to work with the team. Quite the opposite, a highly performing team is aware of its own limitations and skill-set gaps. They need a search engine optimization guru, brand marketer or copywriter. But these roles are working with the product team. As the Agile team is responsible for its own success, the team also takes ownership of the product success evaluation and data-driven improvement actions and outcomes, thus taking a lead in analytics implementation and data collection.
Learning by shipping
It ain’t iteration if you only do it once. Jeff Patton.
Typical enterprise team is valued and recognised for features delivered on time. The moment the release is pushed out of the door, its someone's else problem and the backlog is already full of features for the next release. Even that the teams are doing "Agile", in best scenarios this means a validation before the actual release and fixing found issues. After the release, the product is only improved based on the negative feedback reported by users, and often deferred to specific team labeled as "sustaining work".
Since the organization is not built around the constant improvements of the product, there is a noticeable push-back to even obtain the analytics or telemetry data. People would find creative excuses to build a custom super-sophisticated data collection automation databases that are 10x more complex that the product it should measure. Teams would spend years planning this sophisticated data-collection intelligence. But the basic stats can be already obtained by loading a log file into Excel and Google Analytics account can be created in a minute.
There being no internet, we had to sign up volunteers, and then we would put the special version on a bunch of floppy disks and mail it. The volunteers would install, and then we would have to get on a plane and visit the computer that had version and to take all the data. Steven Sinofsky for Mixpanel.
Since iterative learning by shipping is not integrated into the team's DNA, any reported usability issue feels as a failure. Team leadership perception is that it is something that the team could prevent when following procedures more tightly or by coding harder.
Product Marketing
An established company carefully builds its own image through the product announcements that mostly contains exaggerated product pitch. This might be OK for a traditional PR with one-way information stream. In the SaaS world, the same approach makes the product itself feel less honest and artificial. At the end of the day, anyone can try out the product, validate the message accuracy and turn himself into a Gartner analyst.
A carefully curated PR message about how the product is awesome and breathtaking is just sent into the wild using various digital channels — social media or blogs. A typical example is a blog post evaluating the product by someone, who never used the product or who is not part of the team who build it. If you open a Twitter account, how are people engaging with the product announcements — are they organically replying, quoting, are there twitterstorms found under controversial posts? Or it is just a list of one-way announcements.
SaaS product marketing is everyone's job. Team members are sharing their honest personal stories from the factory, appearing at public domain specific conferences, and their own digital presence is supporting their mission. Regardless if they deliver code, UX design, business value or innovative marketing campaigns, they are all passionate about their own domain. Together they are forming a picture of a competent team where each member knows what he is doing.
Conclusions
It is not easy to transform existing product teams to support SaaS product model, and even more challenging to change whole organizations. For this transformation, I see as an urgency to focus more on actions and outcomes and less on tools and technologies.
This would help domain experts to grow their respective expertises and companies would be less buried in endless technological discussions. A classic example is telemetry and analytics. Teams coming from on-premise world are focusing on designing sophisticated telemetry systems instead of focusing what they want to achieve with the data. Once these systems would exist, the products would not become better, as the culture of continuous improvements and data-driven actions is still missing.
With SaaS it is even more important to work across the silos — from Sales to Marketing, Product, UX Design, and Engineering. My ideal model is a Product team (1 or more Scrum Teams) with single one Product Manager fully responsible for whole product experience — from Try & Buy through product features or retention.
