Ask the Customer
/
Introduction
Based on our research work with best-practice teams we’ve developed a 5-step voice-of-the-customer, or “VOC” process for aligning customer requirements with product requirements in order to determine what customers value most. The customer’s requirements are their “wants” and the product requirements are “how” you will fulfill those wants with your product or service.
This process permits the development team to focus the creation of a new product on what customers actually want and deliver it when they want it. The prioritization of customer and product requirements focuses finite resources where they can add the greatest value--this focus accelerates development cycle-time.
If all else fails… ask the customer… seems obvious, but in our experience, actually asking the customer what they want is rare, especially in the technology business. Rather, we hear technologists say, “they don’t know what they want until we show it to them…this is leading edge stuff” and so on… There is a reason 9 out of 10 new products fail… could this be one of them?
Five-steps to getting VOC (voice of the customer)
“What they say they want” is the listening part
“What they mean and intend” is your translation of what they said
“What this means to us” is your conversion of their wants into a product definition
“What we will produce” is the physical or digital manifestation of these requirements
“What they say when they see the solution” is your demonstration of the product to confirm it is what they wanted
The process is iterative and can occur many times during the development cycle. Best practice teams continually confirm the products value using this process throughout the development life cycle.
What they say they want… Getting VOC is done through face-to-face meetings with many customers around the world. You have to sit with them, online meetings don’t work well for this task. What they don’t say is as important as what is said. Assessment instruments such as questionnaires and visuals are critical to uncover customer needs. We keep asking “why” in order to get at the root needs. This is easier to do when you focus on the problem that the customer is trying to solve and how a new product might provide a solution to that problem. But focus on the problem.
What they mean and intend… is your interpretation of what the customers said. This is a critical step and may require multiple visits to customers to reconfirm that what you heard--is what they actually said and meant. Sometimes this reconfirmation helps customers better articulate what they want. We often say, “In other words, what I understood you said was (blank)…. and is this correct?
What this means to us… is your translation of their wants into a product definition. The product definition is the specific way you are going to meet the customer wants. We also call these the “hows,” this is how we are going to implement (in the product) those specific requirements the customer expressed. This is often called the PRD (product requirements document), but it explains on paper or in a prototype form what the product will look like and do.
What we will produce…. is where you put it all together… what they said they wanted, how you interpreted their needs and now what it looks like all together. Depending on the product, these vary from digital simulations and engineering prototypes, to pre-production units that the customers can touch or use.
What they say when they see the solution… is where you show it to them.
Iteration
Best practice development encourages early prototypes and uses these to refine customer needs and wants. This process accelerates the cycles of learning and causes faster alignment between your new product concept the customer’s needs. It is typical to see multiple iterations of this throughout the dev-cycle. But it must be managed or it can be a recipe for endless feature creep and schedule delay.
Most common failure… we see is when teams start with “what they will produce.” If VOC is done at all in these cases, they take their idea to the customer and ask “what do you think of the product we are going to release in Q3 of next year? Most of the time customers nod with approval or just shrug, and then the marketing team runs back to the developers to confirm they are on the right track. Later, when the product is released it fails in the market. Why? Many cases we have studied indicate that the failed product did not meet the customer’s needs. The process of listening to the problems the customer was trying to solve, understanding what this really meant, and how it could be manifested in the product--was bypassed because the developers were guessing that they knew what was needed or that once the customer saw it, they would buy it--the days of “make it, and they will come” are long gone in the technology world.
So if all else fails, ask the customer!