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.
Interesting note: the first draft was written on my Blackberry while sitting in the Starbucks at 4th and Seneca in Seattle.
I've been to Seattle several times, but yesterday was my first underground tour of the old city. The story is a prime illustration of the importance of proper planning.
The original city was built on a tidal plain. The elevation resulted in tidal flooding which prevented the sewer system from functioning properly at high tide. When the Crappers, the original toilets named after inventor Thomas Crapper, were flushed, pressure from the up-hill part of town caused a violent back-flow into low-lying homes.
To raise the sewer system, city streets were raised by 8 feet or more. Retaining walls were built between the sidewalk and street. Fill dirt was brought in to raise the streets and sewer lines. This put the sidewalks and first floors below ground level. Getting around town became difficult, horse droppings fell onto the sidewalks during rains (Remember, this is Seattle!) and many falling deaths occurred. To rectify these issues, the city built sidewalks at street level, effectively sealing off the first floors. This spurred a rat population explosion which promoted widespread disease, prompting city officials to condemn the first floors of most buildings. A lost underground city was created.
The story of underground Seattle shows us what happens when we don't have a good plan for our products and allow outside factors to drive our product roadmap. Without proper strategic product planning, we end up with incongruous products and product components as well as infrastructure that doesn't efficiently meet market needs.
How much "duct tape and bubble gum" is holding your product or infrastructure together? How much more difficult does this make your job? Make life easier for yourself and your customers. Have the big picture in mind when you do your product planning. Don't let your Crapper explode because you failed to anticipate future needs.
OCPM's leadership team plus guest contributors share their insights on product management, product marketing, professional development & personal branding.