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.

Comments

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.

Jeff
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

Use Case as a Black Box

Consider the following use case: Purchase Items Actor: Purchaser Precondition: Purchaser types at least thirty words per minute and has a web navigation efficiency rating of at least 40. Postcondition: For the average Purchaser acting at full efficiency, the number of seconds elapsed is no more than 30 + 20 * n, where n is the number of items purchased. The name of the use case represents a functional requirement. What does the product do, or enable the user to do? Purchase items. What are we to make of the preconditions and postconditions? What relationship do they have to the requirements for the product? Answer: the preconditions and postconditions are the nonfunctional requirements attached to the functional requirement . Another way of expressing the nonfunctional requirement would be as an attribute and associated constraint: Usability: For a Purchaser who types at least thirty words per minute and has a web navigation efficiency rating of at least 40, it shall take no

Henry Ford's "Faster Horse" Quote

You may have heard the ( apocryphal ) Henry Ford quote: If I'd asked customers what they wanted, they would have said "a faster horse". Over at the On Product Management blog , Saeed gives his take on this infamous quote. He "hates" it, and gives some compelling reasons. Saeed is spot on in his explanations. Personally, I think the quote is great, but it's a matter of interpretation. The valid point of the quote is not that it's a bad idea to facilitate a conversation with your market to better understand it. The valid points are: You must ask the right questions to get valuable answers. You must interpret the answers thoughtfully - often outside their direct meaning - to glean reliable information. Asking questions is not always the best way to "listen" to your market. (E.g., sometimes pure observational studies are more reliable.) Nonetheless, I find the quote is helpful to combat "armchair product management" in the