The Joy of SaaS part 2 — the engineering and product edge

Dolphins in Santa Barbara Harbor by Chiradeep Vittal

In a previous article, I examined some of the financial imperatives that make CEOs of software companies that sell licensed, on-premises software eager to jump on the SaaS bandwagon. Wall Street is in love with B2B SaaS for the predictable stream of revenue and the impressive growth rates of these companies — and richly values these companies.

But there are operational reasons to adopt the SaaS delivery model that every executive apart from the CEO appreciates. For example, the VP of Engineering has much to love about the SaaS delivery model:

• She doesn’t have to provide support for older versions of software. I recently dusted off a Windows 7 laptop that I hadn’t used in 9 years. It booted up and promptly downloaded a bunch of software updates. That’s because Microsoft is still spending money to ensure (perpetually licensed) Windows 7 computers still work. There are some estimates that up to 30% of the engineering effort in a software vendor goes towards maintaining older software versions. With SaaS, potentially 100% of your engineering effort goes towards innovating for the customer’s needs.
• The software doesn’t have to be endlessly customizable / customized for different types of customers. Typically, every customer gets access to every feature and every improvement. Engineers can spend more time on innovation instead of on knobs. There is no need to maintain a giant matrix of hardware, OS, and database version compatibility.
• Techniques such as canary release allow safer delivery of new features — if a feature doesn’t work, it can be quickly rolled back. Once installed, on-premises software is very hard to change.
• On-premises software is notoriously hard to maintain — critical security patches are left pending by the customer’s IT department for months for various reasons — adding to the reputational risk of the software vendor. With SaaS, there is no such burden.
• Continuous and frequent delivery of new features means that schedule risk of big quarterly/semi-annual releases is mitigated.

Product managers benefit immensely from the SaaS delivery model:

• Copious usage metrics give them data about which features are popular and which bets did not pay off -often in days or weeks. With perpetual license software, product manager often had to wait months or years (or forever) to find out where customers were deriving value.
• They can perform live experiments (such as A/B testing) to test out hypothesis and product improvements.
• By observing user behavior (using product intelligence tools), product managers are able to quickly improve user experience thereby increasing retention.
• Data (usage, user experience insights, uptime reports, SLO, etc.) gives them a shared understanding with Engineering about concrete product goals. This improved collaboration reduces confusion and improves service delivery.
• Data science and machine learning techniques can produce additional insights and value for customers and drive unique features that competition cannot easily duplicate without access to the same data.
• Quicker release cycles mean faster learning and improvement.

The marketing department similarly wallows in the ocean of data obtained by SaaS delivery. Trial / free customers are highly qualified leads — and with SaaS it is easier to observe their behavior and move them down the funnel to conversions. Data also greases the collaboration with product management — with shared data-driven goals around growth and retention.

Likewise, the VP of Sales appreciates the highly qualified, high quality leads from trial / free customers that need to be converted to paying customers. With perpetual licenses, a sales person tries to sell the most valuable package of software because they know that they will not have a great chance to come back and upsell the customer in the near future. With SaaS delivery, upsell is easier since the incremental cost to the customer is spread over many months. As usage grows organically within the customer, there is potential for more revenue even without talking to the customer. Sales cycles are shorter too since there is not much to negotiate (in terms of implementation scope, timeframes, and so on).

In my previous article, I highlighted a few reasons why it is hard to transition from selling perpetually licensed software to true SaaS delivery — it takes time for the entire organization to learn the new way of doing business. In my next article, I’ll focus on the new skills required in engineering and product organizations moving from packaged software to SaaS delivery.