After countless of long nights, weekends and personal sacrifices, the software product is finally deployed to the customers ready to reap in all the ROI that was promised. Instead, the product is greeted by users that don’t really care about all the features or hard work that went into it. The product becomes littered with features that will never be used and others that will be changed so much to the point of re-design. This happens too often. So why does it happen and why do we let them get to this point?
First problem is unclear or incomplete product strategy and vision. If you don’t know where you’ll be in the future with the product, how do you know what you want now?
The most common problem is making a complete brain dump of every possible feature that could ever be requested and adding them to the requirements list. What happens is that the project has hundreds of requirements to fulfill and what’s worst is they all are ranked as high priority. The biggest problem with this strategy isn’t that it will take a long time to deliver a product with so many requirements, rather that this is a clear indication that the customer doesn’t really know what they want (see the first problem above).
Since the customer doesn’t know what they want, you can be sure that many change requests will follow or worse, they just won’t use the product after it is built.
So how do we fix it? Force customers to make up their mind?
We need to have a good idea of what the business problem is first, then come up with a product vision and strategy to solve the problem. This should be at a high level. Only then can we move on to gather requirements in small packages in order to stay flexible to the ever changing business world.