SaaS: 10 Ways to Fail – Part 1

They say everybody likes lists. Miles of virtual paper have been inked in pursuit of the “best recipes for chocolate chip cookies,” the “worst airline food,” and to complete the theme – the best diet plans. Ok then- we’ve got a list:

Ten Ways to Fail as a SaaS Company

Introduction

This little list comes from reading some recent blog entries like the post our friend Abe Sultan of Apprenda wrote for Datamation – How to Fail Miserably as a SaaS Company and my own conversations with software company executives. Before anybody says it – it is not every way there is to fail at SaaS. And like any limited list covering a big subject – the items are over broad and not necessarily indicative of the most common ways to fail.

But that said, these are the things that really irritate me and I’m sure irritate those who have lived these errors – as happens in the life of an entrepreneur. So, if you are or are considering offering a product with the SaaS business and delivery model, you might want to think about these common trip points:

1. Provide your licensed software in a hosted delivery model

I put this one first because it is probably one of the most common errors I see and one that we and a lot of other consultants in the field have, in one way or another, suggested at one time. I don’t suggest it anymore because I have seen what happens all to often when what started out as a simple little test exercise becomes a raging white elephant. What’s wrong with this idea?

• Your licensed product is very unlikely to be a good candidate for a SaaS product. This is a “test” of something you can never sell, maintain, operate or scale to reach a decent market. So – what are you testing? This is what is known as SoSaaS. Vendors of licensed products, especially high-value, line of business applications, typically aim their product at the top of their vertical market. It’s just more cost efficient for sales and marketing. The product is loaded with features that satisfy that end of the market and tuned for skilled install by client IT personnel. If it penetrates the 100 top accounts – it’s golden. SaaS products are built to sell and scale to a much wider market. If you can’t do that you are very unlikely to recover your hosting and maintenance costs – much less further development costs in a SaaS model.
• If your experiment is successful at even a minimum level, it will eat your licensed sales. This is equivalent to killing your milk cow for food right after the new calf is born. Best case is to design your initial SaaS offering to reach the needs of the “second tier” and maybe a larger section of the market. This is where the general rule of thumb “80% of value is derived from 20% of the features” comes into play. Leave the rest of the features, that continue to be of value to the top end of the market, off the list. Those customers with the licensed product won’t abandon ship overnight for the more focused SaaS product.
• And the biggest reason – these initiatives tend to color thoughts about moving to a full SaaS offering. The longer they go on, the more you focus on making the failed ASP model of service work. Don’t be Sisyphus. There is nothing to be learned here that you can’t figure out on a spreadsheet with a few links to articles. Costs won’t work out, maintainability won’t emerge and if customers do sign up in droves it will kill you. …And no, ASP in the Clouds is not a magic pill. You just automated part of a bad choice. Chutes and ladders only make the process of rolling the rock up the hill slightly less onerous.

2. Don’t test your market.

I love this one. It is so simple but somehow so counterintuitive to the culture of innovation that has built up over the years. We’ve all seen it. We’re invited to talk about a product from a new startup and the first thing we’re asked to do is sign an NDA. The office is dark and there are gatekeepers to insure competitors can’t get in. There is a sense that we have a new truth hidden in our product and when we release it to the world customers will smile and run to our door. We just don’t want someone to steal it before we finish it and release before we do!

This is an old technical/patent-pending/hardware product approach. 99% of SaaS does not and never will bring forth new technology, software process patents not withstanding. SaaS is expertise wrapped in an on-demand delivery system. It is a service and should be sold as such.

As Steve Blank as so elegantly put it – there are no truths inside your office. Get out and meet the target market before you spend on developing the product whether it is entirely new or a 2nd tier offering of an existing product. Talk to end-users. Show them demos, ask them if they see the value of what you are offering. What would they pay? What doesn’t it do that would make it more valuable? Listen. Take notes, make changes, recycle. After the process reaches a logical conclusion you will have something you can specify and sell. In fact you will already have your beta test pool.

Yes, maybe your competitors will get wind of what you are considering. I hope they do. I hope they short cut the process and spend thousands on bringing out a product without a verified market. Tell them they can’t wait. Go into that dark room and scope that product right now…

3. Ignore business operations.

This source of common failure is so broad it can cover a many articles. And it has. A SaaS operation is different at every level – marketing, sales, implementation, support, maintenance, development – and much of the operations side is expressed as part of the application itself. The online marketing site needs to hook directly to payment, provisioning, implementation and client admin so the new user can get authenticated and in front of the application right after paying. Subscription renewals are automated. Feature bundling and pricing is updated once and is expressed through out operations immediately. Community feedback is integrated into support and product development. None of these operations exist in a traditional software business.

Metrics can guide operations, but the organization itself needs to be aligned with new practices to take advantage of what the metrics tell you. “We have many users dropping off their company accounts before they have recovered the cost of acquisition.” Ok. This is not a bullet point in a slide – it is a question: Why? Someone has to track down the reason and fix it before we burn through a lot of cash. A successful SaaS business is about being proactive. If you wait to feel the pain, it is already too late.

4. Ignore architecture, services, environments and/or reliability

This is another point that is frankly too broad. Such is the nature of lists. This breaks down to a few points:

• SaaS products need to be brought to market economically. See point 2. Your product is going to have to change after release. There is no ultimate truth or one size fits all development solution for SaaS products. Operations (point 3) typically take as much as 60% of development effort if they are developed as part of the product from the beginning. If you can take advantage of a service or platform or tool or outsourcing to lower your risk, development cost and time to market – do it. If your product is properly architected, you can add critical services when you have a proven market and it makes sense to offset income temporarily to capture an ongoing service cost.
• SaaS products need to be architected to be maintainable, tunable, configurable, and stable across the growth pattern expected of a successful product. We change the tires on properly architected SaaS products going down the freeway at 70 miles an hour all the time. We don’t change the framework and drive train without serious consideration. It means pulling over and stopping and that is a hit against reliability.
• SaaS product planning is not software development as usual. You need to know the pitfalls and getting it wrong can be very costly. Get help. Do proof of concept runs. Don’t stumble about in the dark trying to deliver a product. You will find out too late if you are wrong and need to re-architect the product.

5. Ignore end users.

This is the one that broadsides traditional software vendors. Vendors of locally-installed, licensed business products sell to purchasing and key executives. Traditional product users receive what they are given. It is already paid for. Unless it is tragically flawed, they will be trained to use it productively . If they fail training they are moved to other work or let go as “untrainable.” Conversations with end-users are limited to a few words at trade shows and association meetings.

SaaS may be purchased in much the same way, although increasingly line of business users are tasked to do the research and build the internal business case themselves. But, once the subscription is purchased, the clock starts ticking. This subscription is an ongoing part of overhead. What is it contributing to productivity? Is everyone using it? End-user feedback is now front and center. There is seldom any training. A SaaS product is expected to be intuitive and the uptake is expected to be measured in hours if not minutes. If it takes days or weeks to bring new users online, it is a failed experiment from the beginning.

SaaS product management is also tightly linked to end-users. There is a lot to consider in the delicate dance of product strategy and user-led response and we will cover those issues in coming podcasts and articles – the point for now is that SaaS vendors are directly responsible to end-users for their experience. There is no IT department operating as the go-between while fielding first level support questions. If end-users are not satisfied, they will do one of two things – invent their own workarounds or return to their previous tools. Either way they will cease to advocate the service and in many cases will actively lobby to have it shut off. In the case of an on-going overhead cost – they will be successful.That means ultimately the SaaS vendor will lose revenue and may not cover costs. When cost of customer acquisition exceeds lifetime value or end-user loss exceeds new customer uptake – the cost of operation will start exceeding profit very quickly.

Sadly, we’ve reached the logical limit for number of words in an article that people can digest in a reasonable period of time. So, there will be a part two of this article where we will cover the other five points of the ten. Can you already guess what they are? Join us in part two.

Follow Me on Twitter