The Early Bird Gets … Left Behind?
One of the fundamental principles of agile programming, and something that’s leaked out in to other less trendy development methodologies is the notion of “release early, release often”. In a nutshell it says you should release your software product quickly and then update it when you have a new feature or two. It’s fundamentally different to the old style approach of releasing an application when it was finished and everything was complete.
On the whole it’s a great way of doing things. It limits scope creep. It allows you to get feedback very early in the project. It ensures you’re moving forward. This is all brilliant. But that’s not to say it’s perfect.
The problem with “release early, release often” is that users often expect to see more than you’re giving them. Someone signed up as a “beta user” still has expectations that the product they’re using is going to work; releasing before your feature set has the minimum number of things required to make your product useful will put off the users who are most likely to be enthusiastic adopters of the product once it’s complete.
Broken things, ugly things, even experimental things are features a beta tester will take in their stride. Missing things though, especially things that limit the functionality of the product to the point where there’s no reason to use it, mean there’s no reason to carry on trying. The user will walk away.
That’s a key problem for a start-up. Coxing users back after they’ve given up on your app is far more difficult than getting them in the first place. I’m not going to mention any start-ups by name, but it’s something I’ve seen several times in the past month, and I have given up on the app each and every time. As yet I’ve not been back. I wish those apps well for the future, but I also know that the start-up I’m a part of at the moment will be learning from their mistake.
February 10, 2011 - 4:58 pm
This. Last year I was working on-site for a company who went through many of these same issues – they felt obliged to move into beta with an extremely reduced feature set. Heartbreaking to see, as it was clear that every enthusiastic user who had preregistered interest was a user that was basically lost forever.
Promising ‘there’ll be a point to this once all our unique features are in place’ is not a valid strategy.
February 12, 2011 - 4:16 pm
There’s definitely a difference between ‘minimum possible feature set’ and ‘minimum usable feature set’. I totally agree that going to the (beta) market too early is a recipe for failure.
The compromise is probably to have a carefully vetted prototype/alpha stage where you can hold the hands of a few testers/prototype users and ensure that the conversation continues between customers and developers.
I guess the key message I get from your post is the utter importance of managing expectations at every stage of the development from prototype -> alpha -> beta -> release.
April 14, 2011 - 1:20 pm
‘Minimum Viable Product’ encapsulates what you should head for. The ‘product’ bit is very important because it implies the necessity of a market- i.e. your service must have enough utility for your end user to want it.