In my last entry, I described the Buy a Feature innovation game. One of the shortcomings of the approach is that it focuses on features instead of problems.
Unless they are product designers, your customers likely do not know how much a feature is worth to them. What they know - or at least what you can elicit from them - is what problems they currently face and how much those problems cost them.
Before your product designers decide what features to include, they need to know the product requirements. As I've mentioned, requirements are simply a manner of expressing, in measurable terms, the problems that customers want to solve and avoid.
So Buy a Feature can put the cart before the horse. Your team needs to understand the problems customers want solved, and how they prioritize them, before jumping into features. And once your team is considering various features, why do you need customers to prioritize them for you? Your team's job is to weigh the features in terms of how well they address the requirements (which have already been prioritized), not to engage customers in a separate effort of prioritizing features independently of the problems they solve.