New Version Every Other Week – Part II

In part one I covered some principles that allow us to sustain a rate of a new version every two weeks.

In this post I’ll discuss some of the customer facing challenges and how to overcome them.

Enterprise software customers have grown to fear new product versions. Upgrades are as joyful as Freddy Krueger inside children dreams. One would expect that such customers would be very hesitant to change code every two weeks.

In reality , this is not a big issue,for the following reasons:

• Industry standards – Nobody knows what “version” Google.com or CNN.COM or PayPal.Com  is running.  And frankly , nobody cares. It is a question of accountability, and if the service provider has accountability, the very basic notion is that upgrades are his problem to solve.
• Trust – it the service performs well for a year, customers trust the update process.
• Compatibility – obviously, external API’s have to be honored and  backward compatible. But there is really no reason to change them very often.
• Visibility – since there is no explicit external “version number” ,the customer are much less intimated by changes.
• Terminology helps. “Updates to the platforms” sounds much better than “Major new release”. But terminology can’t be the only solution. Vendors tried “HotFix”, “HotFix Accumulator”, “Release Candidate”, “Service Pack”, “Feature Pack” and “Early Availability” but customers still hate bugs. Branding alone is as impressive as re-naming the janitor as Chief Operations Officer.
• Industry Standard 2 – even though SalesForce has only two release in a year, their SLA allows them to have four hours of downtime(upgrade) time every month.
• Industry Standard 3 – Chrome updates itself without asking the user for permission. Windows updates , which used to be tightly controlled by IT, seems to be working very well for quite a few years.

leonardo dicaprio

• Visibility 2 – concerned customers get a deep dive into the multiple safety mechanisms mentioned in the previous post.
• Communication – as a SaaS provider we know what features are used and by whom. If we know we want to change a feature, we speak to these users before we commit the changes.
• Isolation – we built an externally strong isolation model in which multiple features can run simultaneously , using only a single code base. This capability allows setting different “virtual release clocks” for every customer.
• The benefits – in the end of the day, these releases are done to answer customers business needs, not to re-factor code. The customer get a lot of new functionality in an amazing pace, without paying for huge upgrades , software subscriptions or professional services fees.

To summarize, using a mixture of process, technology and adaptive product management turns frequent versions to Leonardo DiCaprio Rather than Freddy Krueger.  BTW, It is worth while reading how some companies deliver 10 versions per day.