In Part 1 of this list we covered the first five points – so if you haven’t read that already, I encourage you to go and read that first. For everyone else – here’s the remaining five points in my hit parade:
6. Plan a yearly release cycle in conjunction with industry trade shows.
For marketing, product managers and developers with any experience in the software industry – this is a natural tendency. For the past 30 years, release schedules have rode the waves of industry events like clockwork. Because of the close association with end-users, a subscription renewal cycle which is frequently 30 days, and the “standards” set by industry leaders like Salesforce, Amazon, and Google – SaaS users expect a steady drip of improvements that have no set schedule. Waiting for some arbitrary “release date” is unnecessary and counterproductive. If the application is properly maintained and architected, the update will take place without any disruption to service.
Unlike upgrades to locally maintained applications – where IT departments had to schedule and plan for application upgrades and possible failures – those issues are now considered to be the domain of the service vendor. It has been outsourced – this is a core part of the service clients are paying for. Frankly – end users don’t care how it is done as long as there is no significant business disruption. Instead they are delighted to find a new feature that solves one of their problems – assuming all parts of the SaaS operation are meshed and working properly. The steady drip of improvement builds user loyalty and increases application “stickiness.”
7. Provide customized versions and features for specific customers.
In software development, this is known as “forking” your development or branching to produce a different, but concurrent, version of an application. Developers try to avoid it like the plague because it greatly increases risk – later changes may not be compatible with the customization done for a specific instance. In traditional installed software, with long release cycles, it was often done by system integrators or vendor professional services. It is an expensive practice that necessarily limits the ability of the customer installation to take the next version. So – they “sandbox” new versions and thoroughly test them before deployment. This may put them several months behind the release schedule of new versions, but it has always been considered a necessary evil in enterprise software deployment.
In SaaS, the tactical reasons for allowing individual instances and customer specific customization become operational nightmares. Now the steady flow of upgrades (point 6) becomes a significant cost issue for service maintenance. It requires more resources, planning, and risk. With the narrow margin of most SaaS operations, it can quickly become an issue that impacts reliability and profitability.
Proper SaaS product management provides two ways to get around this potential bump in the road:
- SaaS applications are architected to be configurable (rather than one-off customizations) to meet the demands of their market. Available configurations are consistent across the application and limited (if at all) only by feature bundling and pricing. Configurations are tested as a part of the normal development cycle without any special conditions. If a new customer requires a new element in configuration, product development evaluates the market and development effort required and makes a decision at the strategic level as to when and if the new configuration might be available. When it is completed – it is available to all clients and part of the standard application.
- If the customization would be to enable integration with other applications in the client portfolio – this is handled at the API level and possibly by external services (like Boomi) that can transform data for specific purposes. This separates the client side needs from the application and allows them to be “loosely coupled” instead of tightly integrated. Product development has to insure that the API remains consistent or at least clients with API integration are notified before critical changes – but beyond that – the service is available to all users consistently – not a limited few who have special needs that have to be evaluated individually.
8. Start with a free version to test the market.
This has been a common mistake by SaaS vendors – led by the many general consumer services available from companies like Google. Few vendors have the income of a Google and advertising-led income is really only possible for the most successful consumer applications.
Let’s say it clearly – The initial assumption of worth is equal to what you charge. If you charge nothing, you will get a lot of drive-by users who have no interest beyond trying to see what the service is all about. Taking input from free “hanger-ons” that have no intention of becoming paid subscribers is very dangerous. Where they want to lead you has nothing to do with profit and user retention at the subscribed end of the market.
That doesn’t mean a 30 day free trial is not a great way to onboard users initially. But – there still has to be a limitation and a stated worth. Users may decide it isn’t worth the price after trying for a few days. They will allow their test subscription to lapse and they will drop off. The rate of conversion from trial to subscribed becomes a clear indicator of the effectiveness of marketing (funnel formation) and product development (trial conversion and subscriber retention). It also doesn’t mean that “Freemium” packages can’t work – where the basic application is free but key services have a cost.
Pricing is a delicate dance between value received and money paid. In service offerings, the best case is always to provide more perceived value than the service costs. At worst, they can be roughly equal – but if they are out of balance to the cost side, subscriber retention will suffer greatly.
9. Build the richest, most complex offering for day one.
This approach is symptomatic of technical marketing and traditional software sales. For years, applications have been sold as technology with comparisons of feature lists. So, the natural tendency is to say – “We do it all! We’ve got all the bases covered!”
This approach leads to several issues in SaaS:
- Long, costly development cycles that produce a large feature set with no user-driven demand. How do we know the features we’re building are critical? What tells us the money and time spent will be returned in subscriptions? Go back to point 2 in this article. 80% of value is derived from 20% of features. There are always features that are necessary regardless of value, but as they rise, they increase cost and complexity for end-users.
- Developing new features into a very complex application becomes increasingly difficult over time. A smart SaaS vendor will generally break out potentially complex new capabilities into additional but separate services as Salesforce has done with Force.com. This keeps the core application focused and allows the new offering to “stand on its” own and seek its own audience.
- Complex applications require more time for users to become productive, training, and support. These are all costs, whether they are borne by the vendor or the client. They reduce adoption and put retention at risk. If the complexity is truly necessary it needs to be compartmentalized so that users can either take it on gradually or upgrade to “professional” versions when they are comfortable with basic functionality. Time to initial productivity with a service needs to be as near zero as possible.
- Complexity doesn’t sell itself. In fact – it drives people away. Think “Evolution – Not Revolution.”
10. Ignore change and agility.
Taking the sum of all the previous points, you should be able to see one thing stand out – A SaaS business is not your father’s software business. It is driven by change and renewal. It responds organically to market and user demands. It grows based on successful market adaption. I call this an agile business and so do many others. It is nothing less than a complete rethinking of how a business organization “works” at every level. It is both cultural and process-led.
This is not the Agile Manifesto – while still acknowledging it comes out of the same guiding principles. Putting a homily up in reception will not make it happen. Ignoring the issue will not make it go away. You can let the issue grind you down over time or you can accept it, plan for it and execute strategically.
So – that’s my list. What’s yours? What’s tops on your agenda?