When a manager "sells" a major project to employees or customers it will be tempting to make promises about how easy the transition will be. The manager hopes that by downplaying the pain involved in transitioning from one way of doing things to a new one, users will be more enthusiastic about the change. This is a shortsighted strategy. While the users initially may be more enthusiastic about the new system if you promise a painless transition there are two major problems that are created:
- Release length is increased
If you can not release as long as there is a risk of causing pain for some users the release date will by necessity be pushed back. Features will be included in the release not because they have a high value, but because there might be users that will be disappointed otherwise.
- Users tolerance of pain is reduced
Users will often be prepared to accept a lot of pain as long as they are prepared for it. The most common gripe about pain in transitions is: "They promised us that this would be painless and look what happened". It is the broken promise that creates the frustration, not the pain in itself.
Bad pain is the result of broken promises and of features that turn out to be useless. It is a feeling of disappointment and waste. Good pain is the focus that comes from having to live without valuable features for a while. Good pain is a tool that makes it much easier for stakeholders to prioritize. Instead of speculating about what they might need, users can describe features that they know will be useful. Good pain is the result of minimal releases and a realistic management of expectations. Bad pain is the result of bloated big bang releases and unrealistic promises.