"Boiling the Frog - Don’t shock your users!" by Greg White

In software or web product development, it’s tempting to test the full extent of your development team’s technical capabilities. However, one needs to keep in mind the users’ appetite for change or lack thereof. We should remember the story about boiling the frog when introducing new functionality. If you put a frog in boiling water, he’ll jump out. But if you put him in cool water and slowly turn up the heat, you’ll soon have a boiled frog because he won’t notice the gradual increase in water temperature until it’s too late.

One development project I had the privilege of leading a few years ago involved replacing outdated dial-up access software with a web-based delivery platform. Maintaining the dial-up network cost the company tens of thousands of dollars each year and the internet enabled us to implement several functionality enhancements. Another advantage of the web-based platform is that we could deploy enhancements and fixes as needed without requiring clients to upgrade. Finally, our support centers would be able to support just one version of software.

Despite the prospect of a significantly better tool, our user base had a mixed reaction as announcements of the coming new system went out. You see, we didn’t have the most sophisticated user base. This was 2004 and some still didn’t have full internet access. Many of those who did were not very comfortable with common internet interface functionality. They were happy with the old system.

What we did to avoid shocking 26,000 users at once, choking off our revenue stream and burying our support centers in the process, was to carry over some of the UI design features from the old software and migrate users in phases. Despite the product management team’s request for several post-launch releases, senior management approved one post-launch release to address any bugs that might slip by. This didn’t allow for a phased rollout of functionality. While desire and capability for more robust web design features was there, the decision was made to replicate some of the features of the old software in the new system. Turning up the heat slowly, if you will.

Despite these efforts, we still received quite a bit of push-back from the user base during the migration process. The end result, though, was the loss of only one client. The support centers were never burdened beyond capacity. Within six months, everyone had become accustomed to the new system. Some early detractors admitted preferring the new system. Our rollout was a success!

Ideally, we would have followed up the initial release with several introductions of new functionality over the months and years that followed. The reality was that one post-launch release became four and then development was shut down in favor of other projects. Five years later, the company embarked on a very expensive project to redevelop the delivery platform which also required another shock for the user base. In the years between the two major development projects competitors had developed more sophisticated interfaces that helped them to gain market share. It would have been cheaper for the company and easier on the users if enhancements were introduced gradually over time.

The growing popularity of Agile development is testimony to the importance of introducing new functionality incrementally. Frequent, incremental enhancements give the impression of consistency to users and allow product management the flexibility to respond to user feedback and changing market conditions.

Whether your company uses Agile or not, remember the frog and ease your users into the future.