Release management, or “How to de-version your app”

Executive Summary: Through the use of anecdotes and a heavy dose of quotation marks, we analyze the traditional “beta/version 1” release cycle of our application and conclude that “version 1” doesn’t make much sense.

We had an interesting conversation the other day at BookedIN on releases. A few weeks ago, we “released” a beta version of the application. But if you check the website now, there will be no mention of the word “beta”.

One of the things we have always tried to be cognizant of is our target user. We look to many companies and products for inspiration, such as 37 Signals and AgileZen. But they have a very different target market than we do. Users of Basecamp and AgileZen, we assume, are somewhat technically savvy.

We are targeting small business users, many of whom may not be familiar with the technical jargon that we’ve become accustomed to. It was for this reason that we did away with the word “beta” in our message in favour of “limited free trial” which, while not exactly the same thing, is more universally understood.

Now with the free trial released, our attention turns to “VERSION ONE”. That is, we decide which features we want to include in the ultimate premiere release of the product. Then we go away and try to get them all in before our mythical “release date”. Which is stupid and we considered this model for all of about 78 seconds.

The “go away” part was the first thing to get thrown out. This being a web application, there’s no reason to keep the current incarnation of the app as it is until version one is released. Very quickly, we decided that “beta” isn’t in fact a one-time release. It’s a period of time in which you are constantly fixing things and adding features. Once we finish a useful feature, we release it. Once we have all the features we want for version one, it’s ready to “leave beta”.

More recently, my friend and I had a discussion about timelines. We are highly motivated to have “version one” ready by year’s end for various reasons. So we set that as our deadline and made plans to discuss which features absolutely had to be included in that release.

Now, we are both very familiar with the Iron Triangle/Pewter Scale but all the same, we were both kind of surprised at how easy it was to fall into the common managerial trap: We HAVE to release by year’s end. All of these features HAVE to be included. And we can’t increase our budget or add people. Nor do we want to skimp on quality seeing as one reason for this venture was specifically so we won’t have to deal with the types of apps that are the result of, shall we say, a particular brand of hillbilly relationship.

After we realized the trap we were about to step into, the conversation changed slightly. What exactly was fixed? The budget, certainly. And, to our mind, the time frame. That is, we placed a high priority on releasing a paid version of the app by year’s end at the latest. Also, quality is not negotiable.

Which leaves, of course, scope as our sole source of flexibility. Once that was decided, we had a whole different notion of “version one” and versioning in particular. What is version one anyway? It’s the collection of features included in the first release of the product. And if that’s flexible, then why decide which ones have to be included in the first release?

Better yet, if the features to be included in version one are flexible, then maybe we can play with the release date a little. For example, instead of saying “we release on December 31, 2010”, why don’t we evaluate the app at regular intervals? So at the end of October, we look at what we have and decide “does this have value?” If not, we keep plugging away and in a couple of weeks, we’ll ask the question again. Once we get to the point where it *does* have value, we “release”. That is, we make it available to the public and start charging.

During this discussion, you’ll notice there’s no mention of the word “version”. There’s no “coming up in version 2”. Instead, we sort the stories we have by priority and start at the top. As they are completed, they are “released”. (Within reason, of course. From a marketing perspective, releasing a new feature every two weeks can be just as detrimental as not releasing any for three years.)

I don’t mind admitting this discussion got me a little giddy, not least because it means a potentially earlier release date than we had planned. It’s pretty liberating in some respects. There’s no looming deadline and it puts less pressure on the developers, neither of whom need this kind of pressure to prove their mettle. Instead, it puts more planning on my friend and I to plan things properly and make sure the important stuff is done first and not left until the last minute.

Amir Barylko is a senior developer who is helping us maintain quality in our code. In his projects, he likes to always be in “release” mode. Which means we should always be working as if the application will be released at the end of the iteration. I hope I’m not twisting his meaning when I claim that this is what I think he means.

I’m not sure something like this would work in every situation. Our development team is already tearing through stories at a good clip even without fabricated pressure, so there’s no need to hold them to a deadline. I can’t imagine how we could make them work any better than they already are so all it would do is add stress and potentially mess up their feng shui.

Besides which, this is a web application with a monthly subscription. The whole notion of version releases seems steeped in the pre-package software world where distribution and marketing come into play. (“New in version 2! Ten percent more features for 25% more money!”) Since there are virtually no distribution costs, there’s no need to saddle ourselves with the corresponding release strategy.

The fact that it’s a monthly subscription model is also a contributing factor. It means we can charge based on the value of the features that are currently in the app. So initially, we may charge less than we originally expected because there aren’t as many features. As we add features, there is potential for adjusting the price accordingly. Of course, we won’t jack the price up every time we change the colour scheme but it’s a fair (and hopefully accurate) bet that most customers will recognize an increase in value when the time comes to re-evaluate.

Time, and our marketing department, will tell, I suppose.

Kyle the Pre-released

This entry was posted in BookedIN. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Michael Fever

    Forget versions just go with build numbers or go by years. Either way you’re covered… if there is next level up then you could call that the pro version.

  • MikeL

    In my current development projects, I frequently release updates. So rather than adopt a version number scheme such as 2.0, 2.1, etc. I use the date of the release as the version, using the format:

    So the second release of the day would be:


  • Kyle Baley

    Ah crap, I don’t need to look that up. I remember that rule every time I hear the chorus of The Doors’ Touch Me. Can’t believe I didn’t catch that.

  • Mark

    “Instead, it puts more planning on my friend and I ” is incorrect grammatically. You want “Instead, it puts more planning on my friend and me,” even though it may sound a little odd. Look it up.

  • DanW

    Version numbers are only useful when more than one ‘feature set’ of an app is in use. Look at Office 97, 2000, XP, 2003, 2007, and 2010. All are currently in use, so the version numbers are needed so people know which feature set they’re working with.

    But with a web-based app you only offer a single feature set at any given time, so version numbering would just be confusing.

  • twh

    For web-based applications, I like the idea of simply having “Updated on October 5th, 2010″ instead of a version number. Have that notice a hypertext link to all of the release notes.

  • Nick

    @Kyle Sure let’s “take this offline” :)

    I do understand that systems aren’t perfect, and sometimes stuff gets lost!

  • Kyle Baley

    @Nick: We haven’t received so much feedback that we don’t get excited at every single piece of it. We have been fielding some already and do respond to everything. In fact, there is an auto-responder on the feedback form that we have specifically to let people know their feedback was received so I’m wondering if there is a problem with the service we’re using. If you don’t mind, could you ping me at kyle at baley dot org?

    Re: when are web apps versioned
    Yes, you’re right, this isn’t a grand revelation. It’s a thought process I went through to come to the same conclusion. It’s more a function of what I’m used to in the corporate world as well as dev tools like CruiseControl, TeamCity, and Rietveld.

    Difference between these and Hotmail/Gmail/BookedIN. The former are (or could be) installed at the client whereas the latter have (more or less) a single instance running for everybody.

    Re: pricing comments
    Let’s not get too alarmist. The price doesn’t go up automatically with every new feature. Nor may it go up at all. Maybe there will eventually be tiered pricing based on features. At this point, a few days after having decided to go this route, all we have are possibilities.

    I do agree that increasing the price is not something to be taken lightly but it is more common than one might think. Based on discussions with other vendors, price adjustments happen all the time. Many even say it’s harder to lower the price than to raise it. My partner in this venture has more experience in this area than I do and is better at explaining the counter-intuitiveness of the idea.

    Perhaps a little too early in the process for this much transparency…

  • Nick

    You may be in pre-release/secret beta/limited free trial – but I suggest that as you are making yourself visible on the web that you take customer feedback seriously already.

    I have been emailing some specific questions through about what you will support/ how you will work as I am evaluating these kind of products for our business and had zero feedback, not even a “thanks for your interest”.

    Makes it difficult to think about trusting my business to you.

  • Henning Anderssen

    I’d be very careful to increasing the price. Customers tend to respond quickly to increasing costs, so it is always easier to lower the price than increase it.
    However, as long as it is clear that this is an introductory price while you guys flesh out the service I guess it is easier to increase it.

  • Vinn Pham

    since when web app ever disclosed their “version”?

    do you see? Hotmail Ver.10? Gmail Ver.4?

    and if you have more feature added to each version…your sub fee goes up and up? what if the client dont need the added bells&whistles?

  • Steve Py

    A couple considerations. Yes, with a subscription-based service it will be much easier to justify releasing features rather than versions. The important thing will be to keep your customer-base informed of what’s currently in the works and roughly when it will be available, and also, base the priority of what gets worked on next on customer feedback as much as possible. For a subscription to be seen as valuable, especially if the price can go up, customers need to know what’s coming up, and about the current new features.

    Features definitely need to be sandboxed and tested (UAT) before being released into the wild. This can be a challenge if you want feedback from the real world especially when changes affect existing features. You can take the Yahoo! Mail approach with 2 versions running, but that will cost money and at some point you have to pull the plug on one of them because they’ll take a long time to rot on the vine.