Some signficant organizational and architectural changes should be enacted to be successful at developing a common product that meets all of your clients specific needs.
Organizationally you will need to change from directly delivering requests of clients to a situation where the development team delivers requests to a product owner within the company. Once you do this, the development team is not working for the clients of the company anymore, the only client that should matter to the development team is the product owner in YOUR company.
The product owner will have to gather requirements from the mutliple clients and determine a common set of requirements that will make the majority of them happy. The development team only needs to worry about making the product owner happy.
Architecturally it helps when designing a product that has a wide array of customer needs to make it as configurable, extensible, decoupled, scalable and componentized as logically possible.
Some good approaches to doing this would be to take the many different pools of requirements and find out what pieces are common amongst all of them. These common requirements will constitute the core of your featureset. Everything that is slightly different than the core can be determined as a configurable feature, setting, or perhaps a whole unique feature that is seperate from the core. Make these seperate features as componentized as possible and spec it out well.
Your customers may look at different features that are currently disabled for their installation of a product and may realize that they might actually want that feature too.
Finally, try to be a "Defensive Designer" without violating the YAGNI principle. This can be a fine line to traverse, but it is a very real possibility that certain architectural and design assumptions can cause you to develop yourself into a corner, causing the need for major refactoring in a future release. Assumptions are CRITICALLY important and should be closely detailed and scrutinized in your technical specifications. An incorrect assumption can cost you dearly later. A good way would be, "I know that the customers are pretty certain that they would like this component to work this specific way, but just in case, I am leaving the option open that this COULD change in the future without causing the need for a major revamp." Sometimes this is as simple as proper componentization and decoupling, other times it borders on possibly developing features that were not requested. You have to make that judgement call for your situation.