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?

There has been a lot of ink wasted on “Best Practices” for SaaS vendors. From my point of view, most of them have been either self-serving (use our services, platform, secret sauce) or suitable only for framed embroidery beside your desk. We’re going to waste some more….

But hopefully we will have something more significant to add

We come to this from study, experience on all sides of the discussion, and not a few “issues” we’ve had to deal with at one time or another. We don’t have all the answers – but there is a strong group of consultants coming together who can easily fill in the gaps where we would rather step back.

We’re kicking this off with a webinar “The Business Implications of SaaS Multitancy” tomorrow – July 16, 2009 – 12pm Central Time. I will be joined by Lincoln Murphy of 16 Ventures and Rick Chapman of SaaS University. We’re going to be discussing what multitenancy is in the SaaS world and what it offers from a business point of view. If you are unable to join us – look for me to add the presentation link here following the webinar. (But – do join us! you can ask questions and comments – but only if you join!)

A lot of this push comes from the questions we get and a simple thought:

We can only be successful if our customers are successful.

So while we might build a great application for a client – if they don’t understand SaaS Marketing, Pricing, Technical Operations, Customer Support and a host of other issues and plan for dealing with them – they have a high chance of failure. That doesn’t serve us or our customers.

To deal with this we have spent the time to build a consulting framework that exposes significant holes in planning early in the process and now have a SaaS Readiness Audit™ service for helping SaaS vendors assess where they stand. We’re going to be covering different areas of best practices on the blog, in continuing webinars and in a series of SaaS Conversations we will be announcing more about next week.

We’re passionate about building a body of content and a community of expertise that can help our clients and advance the state of SaaS products in the marketplace. So we’re purposely not planning this based on our own area of work alone. We’re bringing together a group of recognized independent consultants from many areas of interest – who we know and can endorse. We will be talking about current issues that are in the news and more importantly – those issues that are critical to success for SaaS vendors.

So please – join us and add your own thoughts, questions and perspectives to the conversations!

A lot has been said about what Software as a Service is and is not – and we’ve been part of the noise. I really feel however there is something bigger going on. There is a tsunami coming and SaaS is only one of many waves.

People have said SaaS is:

• A delivery method enabled by the spread of low cost broadband
• A technical architecture (multitenancy) that provides higher efficiency and lower costs (in the best implementations anyway)
• A business model led by direct responsibility for service to end-users
• An alternative to the traditional capital investment model of software licensing
• A low cost way to take advantage of applications and services for SMBs
• Gaining acceptance in enterprise business
• A potentially disruptive business model that could end the dominance of traditional software vendors
• An opportunity that allows new players to “level the field” against intrenched industry leaders
• A flash in the pan that will eventually morph into some other even cooler marketing-led hype.

I would say all of these things are true – and more – or less. In another way however, these observations miss the point. An illustration might help:

Business as Usual

In the “traditional software vendor” business model, the buyer is the ultimate customer. If the buyer is a company – no matter how large or small – the buyer is the filter between the people who use the application and the vendor. If you add in a sales or service channel, a secondary source, the relationship with end-users becomes even more tenuous for software vendors.

Think about that.

Most buyers don’t want to be constantly involved with their vendors and the bigger the company the buyer represents, the more that is true. So, if a vendor relationship comes down to a purchase and maybe a license renewal every two or three years – fine. Near renewal time, there are opportunities to push for new features, fix nagging problems, and maybe switch to a new application. Just as often, renewal periods are time to leverage the “choice” to change to get better terms. Even more importantly – renewals are generally concurrent with new product versions so that vendor sales and buyer interactions are orchestrated. Marketing and sales insure that the conversation at renewal time is more about the “new features in this version” rather than the new features needed by specific groups of end-users.

So how is SaaS different?

Power to the End-Users

In the SaaS business model, the “wall” provided by the buyers between end-users and the software vendor is nearly eliminated. SaaS is a service relationship and the vendor is directly responsible for “user experience.” The buyer enables subscription or transaction payments on an expense basis and turns the operational relationship over to the software vendor. Software-delivered-as-a-Service. Oh….

Now the daily concerns about why the application doesn’t quite meet expectations can go directly from the end-user to the vendor and in most cases – since this is outsourcing in reality – the buyer expects nothing less. Put that beside the truth that high renewals are key to survival as a vendor in a SaaS business and you begin to see something important. The software vendor – to be successful – needs to consider a new way of operating.

Enter “agile” product development and “the agile business architecture” stage left.

The same wave that is gradually taking hold in software development is now being adapted to service-based business operations. Except – we haven’t really acknowledged it yet. How does a SaaS vendor insure retention and stay ahead of competition in the dynamic world of the Internet? By eliminating the artificial renewal period version change, proactively engaging with end-users (support), mining the business intelligence that is now in their hands (aggregated usage), becoming the face of a service instead of a label on an install CD (social media and marketing). By co-opting competition and finding ways for them to join in (APIs and marketplaces). By eliminating long design cycles in favor of a system that can embrace continual, targeted improvement and that responds to a changing landscape. By becoming truly Agile for the same reasons the idea has taken hold in development.

The truth is that the problems that became apparent when outsourcing first hit customer service in consumer goods are just as important when an application becomes a service. A service provider who ignores the end-user’s context, that can only respond when you have reached the head of the queue and then only read from user manuals isn’t going to win at SaaS. Creating more hurdles for the end-user to jump over so you have less interruptions during the design cycle doesn’t make you more agile. Being Agile is about flexibility, response to change, and finally responsibility for success at a very individual level.

In a world where Moore’s Law is an accepted reality, where even GM has to downsize to become more competitive – we also have to accept that change is now the constant and we have to rethink how we organize and work. The principles behind the Agile Manifesto are being applied to successful business more and more every day. Because we – at Scio – believe this is a critical subject you can expect more about agile business architecture and for SaaS vendors – how it can be enabled in the application itself – in the future.