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.
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.
Comments
I've found that choice modeling can be useful when combined with other research techniques in this way. The resulting data can be used not only to understand what is preferred, but how valuable each element is, how much more important certain elements are than others, and potentially how much a customer may be willing to pay for a product with a given set of features and attributes. Conjoint analysis has long been used to identify the value of each attribute of a product or service.
On one project I worked on, choice modeling was extremely helpful at pointing out a major discrepency between problems and willingness to pay for them. While solving a number of other smaller problems would be beneficial for our target customer, they expressed more of a desire to have their major problems solved more easily. However, we realized that they would not necessarily pay much extra to solve that bigger problem better, but they would pay more to solve those other smaller problems.
Jeff
My Blog
I agree, except I think it's crucial to keep in mind that customers don't have the expertise to prioritize features.
For example, most customers know whether ease of use is important to them, but few customers know whether a wizard-based interface is the best way of achieving that ease of use.
So, as you suggest, the goal of asking customers about features should be to gain insights about the problems they want solved.
The variations you describe are all options in the game as described in my book. What I find in practice is that when your prioritizing "problems" and/or "benefits" to be realized, the Innovation Game(R) 20/20 Vision provides better results. When you're prioritizing feautures, Buy a Feature produces better results. The distinction occurs in how people associate tangible dollars to specific features (things I can do) in the product. So, sometimes Product Managers should be focused on features, sometimes on problems, sometimes on the economic impact of solving a problem, sometimes on the benefits a feature provides, and so forth. Ultimately, that's why there are 12 games in the book (and several additional games that we play that aren't in the book). The trick is to pick the right game for the question / customer.
What concerns me is the emphasis on features over problems.
One of a product manager's primary responsibilities is to uncover the problems that motivate feature requests. Features are solutions to problems. Having customers buy (Buy a Feature) or rank (20/20 Vision) features keeps them in solution space.
That's why I like applying these games to problems, not features. Unfortunately, I could find only one sentence in the book (which, by the way, I wholeheartedly recommend to anyone involved in product innovation) that suggested applying Buy a Feature or 20/20 Vision to something other than features.