Source: Alex Shuper on Unsplash+
If you have ever looked into Quality Management Systems, you may have encountered Quality Function Deployment (QFD). This abstract-sounding methodology originated in Japan and was developed by Yoji Akao in the 1960s to incorporate customer needs into the entire product development process.
QFD was developed with physical goods in mind, but it has found its way into the service and software industries over the years.
In this article, I want to give an overview of the method and discuss some advantages, disadvantages, and ways to use it in an agile environment.
People use the term quality colloquially in different ways. A product can be of good/high or bad/low quality. It can also have certain qualities.
Before the introduction of QFD in the 1960s, quality was often measured by the number of complaints customers would have about a product. However, this can only be considered after the product is in the customer’s hands. In QFD, quality is understood as the degree to which a product satisfies the needs of the customers. These needs must be considered not only when developing the product but also when developing all the processes surrounding the product development.
The basic steps of using QFD are to capture the voice of the customer (VOC) and translate it into the underlying actual customer needs. You then find the technical characteristics of your product and use them, and the customer needs to build the house of quality (HoQ), which will be explained later. Depending on your product and your processes, you can feed the results into further quality charts similar to the HoQ to consider your customers’ needs throughout the development process.
Capturing the VOC is one of the most critical steps. If it’s unclear what problem customers have, how can a product solve it? There are two sides: the problem space and the solution space. When gathering requirements, you should only consider the problem space. If you let your requirements get influenced by possible solutions or technical problems, the solution space shrinks unnecessarily, and you may omit great innovative solutions later in the development.
There are many ways to gather customer needs, for example:
Now, you know what the customers want but don’t necessarily know what they need. Often, customers already request specific features, but instead of putting them right on the roadmap, you may want to learn why they need them. Finding out the underlying problem opens up the solution space and may lead to great solutions that are better than what was initially requested.
Not all things customers want weigh the same. Some features are always expected by customers, and others may not be missed but will excite customers if they are available. It’s important to identify in which category a customer demand falls. Not only does it help you prioritize, but it also helps you prevent missing an important feature that could make your product fail on the market.
The Kano model categorizes product features (qualities) and examines how they affect customer satisfaction.
In the Kano model, there are five categories.
Over time, categorization can change. A feature that used to be attractive can be a must-have in the future. You have to be especially aware of that when you are working on existing products for many years.
Another valuable tool for prioritization is pairwise comparison. It’s often challenging for customers to choose what is most and least important to them. Directly comparing just two customer needs at a time is more manageable than considering them all at once.
The method is simple; you have every element you want to compare in the header row and the header column. Then, for every row, you compare the importance of every column element to the header element of that row. You can use 0 as less important, 1 as the same importance, and 2 as more important. It’s enough to do the top part of the matrix and fill out the part below the diagonal with the opposite number of the corresponding cell above the diagonal. At the end, you calculate the sum for each element at the bottom. The results are the prioritization. You can use the absolute values or normalize them and use the relative values.
If you search the internet for information about QFD, it may seem that it consists only of filling out the HoQ matrix. However, as I described above, there are other necessary steps as well. Without deep knowledge about the customers’ needs, there would be no house to construct.
In the HoQ, you relate customer needs to the technical characteristics of your product. The goal is to find out which characteristics are influenced the most by your customer’s needs and, therefore, should be focused on the most. A characteristic could be application size, operational cost, or computation speed.
The left part contains the customer needs with their corresponding weights, while the house’s ceiling contains the product’s technical characteristics. For each need and characteristic, you enter a number that indicates how much the two relate to each other. You often see nonlinear scales used, for example, 0 for no relation, 1 for little relation, 3 for medium relation, and 9 for high relation. This, however, can skew the results and artificially boost some characteristics over others. I would suggest using a scale of 0 to 3.
After you populate the whole matrix, you calculate the results. For every column, the score in each row is multiplied by the weight of the row’s customer need and then added together. Like in the pairwise comparison, you can normalize the result to get the relative score for each product characteristic. The score tells you which characteristics impact your customer’s needs most and which characteristics you may need to focus on the most. This is especially useful if you’re limited by time and resources (which is probably always the case).
In addition to relating customer needs and technical characteristics, you can use the roof of the HoQ to analyze how the different characteristics affect each other. This is usually done by writing a “+” for a positive correlation, a “-” for a negative correlation, and a circle or nothing for no correlation. The arrow icons above each characteristic indicate if a lower or higher value is desirable. In the above example, the positive correlation between application size and operational cost means that lower application size will result in lower operational costs. On the other hand, the negative correlation between operation cost and computational speed tells you that a higher computational speed will increase the operational costs.
The right side of the HoQ is reserved for competitor analysis. Each column represents how well a competitor’s product satisfies the customer’s needs. You then rate the product of one or more competitors for every customer need. This allows you to see where the competition is already strong and you have to keep up, or where they are lacking, and you can sway the customers.
Often, people stop at the HoQ. However, the results can be fed into further matrices to analyze the impact of customer needs on every part of the development process, such as the tech stack you are using, your workflows, or how you do QA.
Constructing these matrices can take a lot of time and effort, depending on the number of customer needs and technical characteristics. Therefore, using them may not always be possible or even make sense, especially in a fast-paced agile environment. Building MVPs is less problematic in that regard because you (hopefully) work with a smaller set of elements.
But there are other ways to make it work. For example, if the software you build always has a similar foundation with customer needs that always apply, then the master-and-sub chart approach might be for you.
For the parts that never change, you would construct the master charts once and create the sub-charts for the new parts only, resulting in much smaller charts and, therefore, much less work. Of course, customer needs and technology are constantly changing, so small changes will need to be made over time.
QFD can be an excellent methodology for keeping everything and everyone customer-focused. It adds structure to the development process and promotes communication and discussion within and between teams and departments. But you have to be careful not to mindlessly follow numbers. If product characteristics end up with a rating very close to 0, investigate why that may be the case. There could be essential customer needs that have not yet been found.
If you work in an agile environment, and especially when working on MVPs, you need to find the right balance between completeness and keeping your matrices small enough that the overhead of continuously adapting them does not diminish their benefits.
Some final thoughts: