SaaS as a user experience tool

Software as a Service (Saas) is an intriguing way to solve the problem I describe below. First, of of the reasons enterprise users want to avoid change is because of the cost of deploying the changes. SaaS allows a product to make changes without any deployment cost. Next, it allows incremental improvements to be made to the software. One of the great things about websites is the ability to make small, frequent changes. These small changes are not disruptive to regular users yet over time it allows substantial improvements to be made. Application middleware that requires user installation and maintenance don't inherit this benefit. But SaaS can solve this problem - buying the middleware doesn't mean you have to take it and install it and host it and maintain it... it just means you have access to it.

There are problems with this approach, of course. The biggest of which, to me, is the ability to extend a product with third-party software, which is critical in building a viable ecosystem for middleware. How do you extend something that you don't host yourself? This is tricky, but it's solvable.

Although SaaS is a new buzzword, it's not a new concept. But given the amount of time and expense that customers spend on installing and maintaining middleware, not to mention the user experience benefits, it might be useful to push the boundaries of SaaS to include traditional middleware offerings.

On release cycles, change, and stability

Users hate change. Once they invest in learning a product, they don't want it to change, even if the changes are theoretically for the better. In enterprise software, they are particularly interested in the stability of the code base AND the stability of training. If they have a large organization trained on one version of an product and we tell them, "We've changed everything in the new version! It's way better!!", they do not get excited. They get nervous and start calculating migration costs. Users want to settle on a stable release of the product and stay there until something happens that forces them to move (like the product going End of Service). Users tell us to stop putting out new releases... slow down... extend the release cycles. Users hate change.

Users want their new features added to the product, and they want them added NOW. Sure, the product is pretty good, but without features X, Y, and Z, it simply isn't good enough. And with enterprise software, when a customer tells us they want X, Y, and Z, chances are they are paying a LOT of money for the software, so we damn well better listen. Of course, each customer has a different list of what X, Y, and Z are, they don't care about the other customers' requirements, and they hate unnecessary change. "Unnecessary change" means "changes that my company doesn't need." Users do not want to wait for their favorite features to be added.

This dilemma is particularly difficult for user experience practitioners. Customers don't want to retrain, yet we're only got, perhaps, one opportunity every two years (depending on the length of the release cycle) to make improvements in the product. By essentially saving up all the improvements for two years we inevitably introduce fairly major changes with each major release - which is bigger change than customers want AND slower change than customers want.

What's the solution? It's possible that the answer is "there isn't one", but I'm wondering whether Software as a Service isn't a pretty good way of getting around the problem. More on that in my next post.