Skip to main content

Buy a Problem

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.


Jeff said…
You have a good point -- product managers should be focused on the problems, not the features. However, having customers help prioritize features can be useful when there are several different ways to solve the same problem, or several different problems that from your perspective all appear to be of equal priority, or to understand whether it is more important to solve a minor problem that happens frequently or a major problem that happens infrequently.

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.

My Blog
Roger L. Cauvin said…
"[H]aving customers help prioritize features can be useful when there are several different ways to solve the same problem, or several different problems that from your perspective all appear to be of equal priority, or to understand whether it is more important to solve a minor problem that happens frequently or a major problem that happens infrequently."

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.
Luke Hohmann said…
Roger -
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.
Roger L. Cauvin said…
Thanks for sharing your thoughts, Luke.

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.

Popular posts from this blog

Why Spreadsheets Suck for Prioritizing

The Goal As a company executive, you want confidence that your product team (which includes all the people, from all departments, responsible for product success) has a sound basis for deciding which items are on the product roadmap. You also want confidence the team is prioritizing the items in a smart way. What Should We Prioritize? The items the team prioritizes could be features, user stories, epics, market problems, themes, or experiments. Melissa Perri  makes an excellent case for a " problem roadmap ", and, in general, I recommend focusing on the latter types of items. However, the topic of what types of items you should prioritize - and in what situations - is interesting and important but beyond the scope of this blog entry. A Sad but Familiar Story If there is significant controversy about priorities, then almost inevitably, a product manager or other member of the team decides to put together The Spreadsheet. I've done it. Some of the mos

Interaction Design: the Neglected Skill

Your product development organization has a big, gaping hole in it. (Be prepared to feel defensive as you continue reading.) One of the most important roles in product development is the role of interaction designer. An interaction designer designs how the users will interact with the product and conceptualize the tasks they perform. He decides whether, for example, the user interface will be command driven, object oriented (clicking on objects then specifying what to do with them), or wizard based. The interaction designer decides the individual steps in the use cases. Every company has one or more people that play the interaction designer role. Usually, those people have little or no expertise in interaction design. Sadly, they typically don't even realize how unqualified they are. Let's see who typically plays the role at companies. Engineer . An engineer is an expert on building what is designed. Yes, an engineer may know how to design the internal structure of the hardware

Stop Validating and Start Falsifying

The product management and startup worlds are buzzing about the importance of "validation". In this entry, I'll explain how this idea originated and why it's leading organizations astray. Why Validate? In lean startup circles, you constantly hear about "validated learning" and "validating" product ideas: The assumption is that you have a great product idea and seek validation from customers before expending vast resources to build and bring it to market. Indeed, it makes sense to transcend conventional approaches to making product decisions . Intuition, sales anecdotes, feature requests from customers, backward industry thinking, and spreadsheets don't form the basis for sound product decisions. Incorporating lean startup concepts , and a more scientific approach to learning markets, is undoubtedly a sounder approach. Moreover, in larger organizations, sometimes further in the product life-cycle, everyone seems to have an opinio