Identifying the Correct Customer

The truth of the matter is that 99% of the time, the true “customers” for any manufacturing, engineering, or service project are the internal stake holders. These stake holders (usually the executive business team) determine what constitutes a successful product or service delivery, regardless of the end consumer’s opinion. Put simply, if the consumer market loves a product or service, but internal business objectives aren’t accomplished through the delivery of the product or service, then the project will be deemed a failure. In general, if a product or service development team is to be truly successful, they will have to give focus to the wants and needs of their internal customers before all others.


Most people believe that the first step in creating a successful QFD is to identify the list of customer requirements. Although documenting customer requirements is key to ensuring that the “voice of the customer” is heard, there is actually an even more crucial first step. The very first task to complete when creating a Quality Function Deployment is to identify exactly who your “daddy” (i.e. customer) really is, and that task isn’t as easy as you might think.

Numerous QFDs fail (i.e. cease to be used or to be useful) because too many features are added to the relevant product or service in a manner that bypasses the QFD altogether. These assignments are made in a manner that circumvents the system in order to address “urgent” requirements. Unfortunately, as soon as a window is opened for non-customers to push “urgent” matters to the front of the queue, they stop using methodical processes for prioritization altogether. Soon, every pet project or feature gets identified as “urgent” or “imperative”, and the QFD falls to the wayside with the voice of the customer close behind.

This may seem like an easy problem to fix—all that needs to be done is to make sure that these “urgent” items get added to the QFD like every other feature or requirement. If needed, these items can be evaluated and rated before other requirements, but they won’t be worked on until they merit attention. The problem is that many of these urgent items would never warrant attention, according to the QFD, because the wrong customer was identified in the first place.

 

The Internal Customer

The truth of the matter is that 99% of the time, the true “customers” for any manufacturing, engineering, or service project are the internal stake holders. These stake holders (usually the executive business team) determine what constitutes a successful product or service delivery, regardless of the end consumer’s opinion. Put simply, if the consumer market loves a product or service, but internal business objectives aren’t accomplished through the delivery of the product or service, then the project will be deemed a failure. In general, if a product or service development team is to be truly successful, they will have to give focus to the wants and needs of their internal customers before all others.

Business Executives vs. Product Consumer

Hopefully, most executive business teams will be strongly influenced by their product consumers, but there are times where business requirements cannot mirror the wishes of product consumers. Consider for example features that prevent media piracy, such as duplication blocking for audio CDs or key coding for software. Consumers are unlikely to give items such as “piracy prevention mechanisms” high weightings on their requirements lists. Similarly, consumers are unlikely to include such things as “prominent branding”, “embedded advertising”, or “consumer tracking” on their critical-to-customer requirements.

Conflicting Business Initiatives

Another source of conflict between business priorities and those of end consumers is the issue of related business initiatives. Often times a business will try to augment the sale or distribution of certain products by adding strategic features to related products. For example, a technology company might impose limitations on their software such that it is only compatible with hardware produced by that same company. End consumers would probably prefer to have the option to obtain their hardware from the cheapest or best source. The business objectives, however, may be best served by motivating the distribution of one product line through its exclusive integration with a more popular or well-adopted product line.

Conflicting Consumer Groups

Another difficulty with attempting to base a QFD on consumer requirements is the issue of conflicting consumer groups. Many products are marketed to differing consumer groups with opposing requirements. Consider Internet search engines for example: the developer of the engine has two sets of customers: those who use the engine to find resources on the Web and those who wish to advertise via the search engine. Customers wishing to advertise may want to purchase top ranking positions or enormous, gaudy advertisements. The customers who are trying to search for information via the engine would be turned away but such tactics, however. Similarly, advertisers are not going to pay to advertise in ways that are too inconspicuous to be noticed (even if web surfers would prefer it that way). Thus, interviews made with either group exclusively would be unlikely to result in a practical list of requirements.

Government Regulations

A final conflict with basing a QFD on consumer requirements is encountered in those areas in which government regulations are applied. Frequently, the details of these regulations are of little import to the consumer involved. However, these regulations must be adhered to if the company producing the product or service is to remain in business.

Recommendation

Although most quality engineers and product managers would prefer to take their cues from the consumer of their product or service, the best sources for requirements on any professional project are the project’s internal stake holders. These stake holders have the best understanding of what the differing consumer groups are for the product, what the relative priority of those consumer groups are to the business, what the internal business requirements are for the project, and what government regulations need to be considered in relation to the product or service. In short, when listening to the voice of the customer, the “internal customer” should be given the bull horn.

Does this imply that the consumer’s voice is irrelevant to quality engineers and product managers? On the contrary, it is the responsibility of these engineers and managers to help their business stake holders properly understand the voice of their consumers so that they can properly integrate their consumer’s desires into their own list of critical requirements.


About this entry