Differentiating Customer Needs from Product Features
/Often product functions or features are confused with customer needs. In our world a customer need (also called "customer requirement") is an attribute that expresses some part of problem a customer is trying to solve. A product feature is specifically how the customer's need will be fulfilled. A product feature is also called a "how." The thinking behind this comes from Quality Function Deployment (QFD) practices.
So we need to distinguish between a "want" and a "how." Most of the time we see people going out to get the voice-of-the-customer (VOC) by asking customers to evaluate "guesses" at what is wantedby showing the customers the features of a proposed new product or service that is to be developed.
These features are in fact HOW the problem is going to be solved, but what I always want to know is WHAT PROBLEM IS BEING SOLVED by these features. This problem is more extreme as the complexity of the technology increases. Most new products fail (>90%) for a variety of reasons, one predominant reason we see is that it they are the WRONG product since the problem it was designed to solve was never clearly articulated before the product was developed. How many times have you heard, "This is a product searching for a problem to solve, or a customer that wants it, or a market need to fill!"
For example, you show me a prototype of the car you want to design. You tell me about the unique features it has like its high performance motor that also runs more efficiently than any car on the market today. I am impressed. You ask me if this feature appeals to me. I say of course. You report back to the design team that your VOC validated their superior intelligence and foresight. Later you deliver the finished car to me, but I reject it because it does not meet my needs. What happened?
Well, I said I had a transportation problem. You rushed to the solution and showed me your new car idea. But, had you spent the time to understand the problem I was trying to solve, you would have learned that I needed to transport containers to China in the fastest, most cost effective manner. Possible alternative solutions (i.e. the hows) could be ship, plane, or rail. If "lowest cost" was my driving requirement then I would need either a rail or ship solution. If the problem involved overseas transport then you would have needed to dig deeper into the possible shipping alternatives to see which solution best met my NEEDS. This example was exaggerated to make the point, that there is a difference between a requirement (a want) and a solution (a how).
Another Example
"Controllability" was defined by the target customers as one of the key needs. "Manual Dimming" and "Adjustable Light Levels" were identified as being ways to fulfill the need to control the device -- expressed by customers. Until doing this analysis the team was showing target customers long lists of proposed technical features (many of which meant nothing to the customers) and asking the customers if they liked or wanted them. They found it hard to define what was really needed or valued by the customers and what was just "nice to have." Further, they really didn't have a clear understanding of the problem the customer was trying to solve. But they had lots of data!
Back to the example... There was a long list of features we scored against each weighted customer requirement. This gave us a prioritized list of product features. An example of the scoring is provided here. These scores were validated by the target customer group.
We were able to determine which features were most valued by the customer and able to simulate how the prioritized list changed when the weighting of their needs changed. What if "controllability" became the most important need? How would this change the rank order of the product features? It turned out that different market segments and applications prioritized their needs differently. So the model was used to simulate various product configurations, depending on the segment studied.
Why do this? In this case it was to focus the limited development resources on creating the product functionality that the first customers would most value -- i.e. deliver the right product at the right time.
Being able to separate customer needs/requirements from product features/functions is key in getting at the root-cause of the problems the customer is trying to solve. Find the solution and then define the product around this and it generally results in a successful product... assuming it is delivered when the customer wants it!