The UX of monthly release cycles

Several years ago, I went to a P-Camp Unfonference.  (It was fun and I strongly recommended giving it a try.)  It was at that conference that I realized how long most release cycles were.  They were running quarterly releases or longer.  One company was still on CD releases track once per year.

Software as a Service (SaaS) products do not require executables or CDs to deliver their upgrades.  They don’t have to worry about who is on what version.  They just update the web application and the next day, everyone is on the new thing, like it or not.  This solves all kinds of problems (and introduces other problems).

When you can update the product without worrying about burning millions of CDs and shelf space, you can release at will.  Literally, you can patch the site whenever you want, even mid-day.  This raises a critical question about the frequency of upgrades that are desirable from a UX standpoint.

Delivering too many updates will lose the Christmas Morning effect. Delivering too few updates means you are rolling up a ton of changes and it can become overwhelming. Clearly, a Goldilocks amount is required.  Not to frequent, not too seldom.  Just right.

I believe monthly releases are the right size for companies that are less than 500 people big.  There is a natural calendar in people’s brains that maps to the Gregorian calendar.  It’s easy to remember the May release rather than the 2.1.4 release.  Time is an important factor in software.  How much are you delivering in what time frame?  These are measures of agility and productivity that play into whether your customers think you are a good partner or not.

Going quarterly is a good idea for a bigger company that just can’t get all its ducks in a row in a month time span.  However, for any startup, this should be a problem.  Going shorter (2 weeks) works for the early stages of a startup and even beyond, but the user will lose some context around the updates.

Whenever you can use existing psychological anchors in your UX design, you should.  Why fight the human brain when you can leverage it?

2 thoughts on “The UX of monthly release cycles

  1. I’d make the frequency of releases depend on a few factors:
    * User community (developers, power users, “consumers”)
    * Maturity of the product
    * Smoothness of the update process
    * Nature of the updates (bug fixes, performance improvements, UI changes, added core features, added optional features)

    I personally am disturbed by Firefox plugins updating often bi-weekly with the interruption of my starting the browser and there is in most cases no benefit for me (multiply this per compueter/VM and it becomes very annaoying). Especially if the end result is a new page forced on me that tells me I have a new release, but does not tell me what really is the cause of the urgency or the added functionality.

    I also disapprove of my app changing w/o my consent and me controllign the timing (automatic updates of Windows, Nah!)

    So if you go more frequent than quarterly, make it a point to deliver smooth bug fix or performance improvement only releases between the quarter. Or if you are in start-up mode, deliver a beta track that updates bi-weekly, but also offer a hund and dried version, where the features are usable and changes don’t distract me from doing actual work.

    Afterall the invention of the “personal computer” was successful, because the end-user controlled all the resources. The same is true for software, wether OS, installed apps, Saas or anything else.

  2. @Kaj: All the examples you gave weren’t SaaS. They were desktop apps (or OS). I’m describing a totally different world when the app just is updated. Like or Gmail.

Whatya think?

%d bloggers like this: