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.