The thing about App shipping schedules

I’ve come across an interesting article, Ship your app weekly | Karma that debates the notion and merits of how startups and companies schedule their shipping/release dates. iphone-410316_640.jpg 640×426 pixels

Klass raises an interesting point, that many companies are stuck in the pre-internet days of shipping apps once or twice a year, synonimous with the days when companies would physically ship boxes of software, where logistic dictates how practical it was to distribute something according to what frequency.

It seems that the archiaic process continued with the development of iOS and Android apps, where companies and startups are focused on packing is as much feature into each release, with the fear that they need to tick all the boxes before it can reach the light of day (or the App Store). Thinking about that, we are living in the era of Agile methodology, and doesn’t agile infer that we iterate and ship regularly? Sure in most cases its about internal development management, packing sprints and releasing internally, but when many startups work lean, utilising the public through regluar releases affords you the ability to have an extensive network of people who can provide constructive feedback.

Klaas has a nice quote from Parkinson’s law:

Parkinson’s law says: “work expands so as to fill the time available for its completion”.

So, rather than deliver a massive list of changes each release, build and release frequently, and provide one or two features, so that your customers know what has changed, and it gets the right amount of attention, so that you can get sufficient feedback (both good and bad).

More importantly, in my opinion, by introducing one feature at a time you also allow your customers to learn, to evolve, without the need for excessive on-boarding. To introduce something new, you need for them to learn and familiarise themselves with it, and evolve, whilst ensuring they are not overwhelmed. This is how Facebook and other major apps managed to introduce fancy features, by introducing them slowly, so that users can explore and find it themselves without being so perplexed.