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.

What is “Quality”?

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.

Using QFD

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 voice of the customer

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:

• Conduct surveys or interviews in written or verbal form and ask customers what they want or need. They will tell you how they experience a particular problem and probably also already suggest (part) solutions.
• Look at an existing product (or a similar one) that you want to improve and analyze it.
• Observe customers while using a product or encountering a problem your product will try to solve. This is one of the most reliable methods to gain insight into the problem space because you do not depend on people remembering and telling you every important detail. It is best paired with asking questions while observing.

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.

Prioritizing

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.

• Basic or must-have qualities: These are expected qualities. If you have them, no one cares; if not, customer satisfaction will be affected very negatively. They are unspoken, meaning customers do not ask for them — for example, a product search in an e-commerce app.
• Performance qualities: These are used to compare different products and see how they perform. Customers actively ask for them, such as the amount of included storage space in a cloud storage service.
• Attractive qualities: They are the opposite of the basic qualities. Customers don’t know they might want them before stumbling upon them in your product. They boost customer satisfaction but don’t hurt it if you don’t have them.
• Indifferent qualities: Qualities that customers are indifferent to or aren’t even aware of. They are often technical aspects that customers don’t notice or don’t care about.
• Reverse qualities: These actively hurt customer satisfaction and should be identified and avoided.

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.

The House of Quality (HoQ)

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.

Master- and Subcharts

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.

Final thoughts

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:

• QFD aims to ensure that customers get a solution to their problems.
• Don’t stop at what the customers tell you they want. Dig deeper and find out why they want it and what the actual underlying need is.
• No two companies are alike. An approach that works for one company may not work for the other. QFD has to be tailored to you and your workflows.
• QFD is usable for physical goods or software products as well as to analyze and develop services.
• Don’t aim for completion. The last 10% take 90% of the time.