I was looking through my library of NPD books the other day and happened to open a chapter on Quality Function Deployment (QFD). I am sure most of you know that QFD is a structured product development process which translates market requirements into a program to create, manufacture, and deliver value to the market.
QFD has possibilities but ….
Based on personal experience using QFD, I see the potential possibilities it can offer. However, a couple of things you need to be aware of it you decide to implement QFD in your NPD process.
First – this is a very complex and involved tool. While your team will get some value with a basic understanding of how it works, it will require a major investment in time and resources for your team to really understand and use it correctly. There’s no getting around that.
Secondly – and the point of my article today – QFD is only as good as the inputs (voice of customer) you put into it. This is true for any design method and tool you use. If you feed garbage into it, you will get garbage out of it.
Up-front discovery process is essential
One of the things that I have found troubling with QFD is the absence of a front-end discover process to identify and rank the most important needs that customers have. I believe in general, up front research to discover real requirements is an issue a lot of development teams struggle with and a root cause to most product failures.
QFD often focuses on requirements need based on what has already been done in the past. That’s fine if you want to create incremental improvements. But this won’t provide you the insights to create new and exciting innovations.
Do you really know what customers want or are you guessing?
QFD depends on identifying important customer desires up front. Get those wrong, and the house of quality turns into a house of cards. My guess is that most teams rush through the problem identification process and just assume they know enough, or worse, think they know better than the customers.
I remember reviewing a couple QFD projects for a client where the sales guys decide that they were the voice-of-the-customer. And because they were sales guys, they did a great job on selling to the development team their knowledge of “market realities.” And no surprise, the company created a series of “me-too” products that the sales guys couldn’t sell … I know, a shock!
So why does this happen?
Well for one thing it takes a lot of work to really understand what customers want, and development teams are under constant pressure to reduce cycle times. So they just skim through the discovery process with the hope that will save time off the development cycle by relying on internal opinions to drive innovation. A good formula to miss the mark and waste a lot of time on launching ho-hum products.
A lack of structure to discover what customers want
But I also believe development teams lack a structure to systematically research and define what customers really need. Sure they talk to lots of people, probably collect lots of data – but then what? What do they do with the information and how do they translate it into reliable requirements they can innovate around, whether or not they use QFD as a design tool?
Jobs-to-be-done innovation framework provides valid inputs to QFD
Looking back on a couple of articles I published early this year – Underserved and Overserved Outcomes Provides the Guidepost to Innovate Around and Using Opportunity Scores To Define and Create Differentiated Products Customers Want, I discuss how to use the jobs-to-be-done innovation framework to identify important underserved outcomes and using the index scores to create a unique set of requirements that provide the guidepost to innovate around.
The output of the jobs-to-be-done innovation framework can be used as the inputs to QFD’s house of quality – based on a systematic approach that validates what customers want and what they struggle with. If you use the J2BD innovation framework, there will be no excuse for not understanding customers wants up front. Your likelihood of launching a successful new product using QFD will greatly improve.
Building a solid foundation for your House of Quality
Of course QFD is one of many tools development teams can use to translate customer requirements into winning new products – but if you plan to use QFD, then use J2BD to uncover what customers really want up front so you can build a house of quality on a solid foundation.
Here’s to creating a solid foundation for your House of Quality
Kevin