A few weeks ago, my esteemed colleague Bryon Moyer wrote an article entitled “Just Who Is the Customer?” In this article, he identifies the “toll-taker” or “gatekeeper” as a sort of semi-villain who takes decision power away from the consumer for his own gain. Bryon makes a well-supported case, but I’d like to propose an alternative question and an alternative explanation:

Just What is the Product? 

As electronic engineers, we design things like circuits, chips, boards, boxes, and “systems.” It is very rare that we design something that stands atomically and autonomously alone. Just about everything we envision and engineer is a cog in some larger machine, and just about everything we design uses someone else’s end product as a component. We take the products of others’ work, add our value, and hand that up the food chain to some other team who adds their value, and so on. 

At some point, of course, an end-consumer buys the thing. Usually, in our mind’s eye, the “thing” comes in some shrink-wrapped box. Historically, that box has defined our concept of the product. Over the past couple of decades, however, that box notion has begun to break down. We don’t really buy a “phone” – we acquire a device that provides one component of a complex communications service. The phone is meaningless without the network, and much of the actual product is behind the scenes – cell towers, switches, millions of miles of fiber and microwave links, countless computing engines, and the services of a small army of technicians, maintenance personnel, customer service agents, and other parties – all of whom are essential to the successful operation of the “thing” we are buying.

As a customer, then, what we are buying is often more an “experience” or “service” than a simple product – even though we plunk down the cash for something in a shrink-wrapped box. We are purchasing the ability, as I did last week, to stand on top of a glacier in Canada and communicate with an associate in California about a meeting with a company in Asia, then pull in help from Oregon to coordinate the meeting. Then to immediately post a vacation photo of the glacier to a social media site (on a server located who-knows-where), which was seen by my mother in Texas only moments later. This is not something that comes in a box. (This is also where one might point out that I should get a life and not be that guy walking around on the glacier looking at his phone, but – back to the topic at hand…)

It’s pretty clear, for example, that FPGA companies are designing components – meant to be used in the engineering efforts of others, but FPGAs themselves are the end product of an FPGA company. And, an FPGA as a product is a lot more than simply a chip. FPGA companies must deliver software, services, IP, development boards, and a host of other elements in order to create the experience their customers (engineers) require.

With the line between product, service, and experience becoming so blurred, and with the complexity of products rising dramatically, we are also reaching a juncture where the majority of customers use only a tiny fraction of the capability of most of the products we create. There was a time when a television set was one of the most complicated things you could purchase. That television set had three controls: power, volume, and channel. Just about every consumer who bought that device fully understood the purpose and operation of those three controls. They used all of the capabilities of the device on a regular basis. Today, the average consumer who purchases a smartphone or a computer uses only a tiny fraction of the capabilities of the device. The bottom line is – today’s consumer understands very little about the capabilities and operation of most of the electronic products we design.

This user-understanding gap arises, not because today’s consumers are less intelligent, but because today’s products are vastly more complex and capable. Nobody needs to use all of the capabilities of a smartphone. The device is so rich in features that even a small subset of those make it a satisfying purchase for the average user. 

From an engineering perspective, of course, there must be a “system engineer” responsible for the big picture of how this big product operates. One of the jobs of this system engineer is to figure out the sandbox in which the user can play. If the system has options, configurations, plug-ins, applications, or other means of customizing the services it provides, someone needs to define the boundaries of those user-modifiable parameters. When those add-ons and modifications can come from third parties, system engineers need to determine the consequences and the adaptations required to accommodate this third-party addition to the value chain.

When products were simpler, so was this role. Today, though, with product ecosystems that sometimes span thousands of features and potentially hundreds of third-party expansion or alteration possibilities, it’s a daunting task. Further complicating the matter, the difference between the level of understanding a system engineer must have of the system and the level of understanding the average user attains is enormous. This gigantic gap in familiarity directly attacks one of the most important skills of the system engineer – customer empathy. The system engineer, with an immersive wealth of knowledge about the complex product they are creating, must be able to put themselves in the mind of a user who knows (and cares) almost nothing about it.

So, often, the “gatekeeper” that Bryon’s article describes may be nothing more than a visionary system engineer trying to manage the quality of a complex product by exercising some control on the number of possible variables affecting the behavior and performance of the thing they’re designing. While it might seem attractive to leave this somewhat in the hands of the potential customer, the complexity of many of today’s products, combined with the limited scope of use of the average customer, can make that a dangerous gamble. 

Further complicating the matter is the scale of production required for many of today’s products to hit their price targets. When you have to mass-produce devices in enormous quantities in order to be competitive, you lose the option of offering a wide gamut of options and product variants. The cost and complexity of creating and supporting a wide array of versions of a single product can be prohibitive. By the time a phone support technician wades through the long list of questions required just to establish which version of the product the customer is using, what aftermarket add-ins are installed that might affect the problem at hand, and which components may be missing from this particular customers’ configuration, patience may have worn thin. In order to create a product use and support experience that is in line with what today’s customers expect, it is usually necessary to simplify and streamline the product itself, and to restrict the flexibility we allow the user in modifying and customizing it. 

As engineers, we don’t generally like people to limit our creativity – even with products we buy. We tend to want to customize, modify, and tune everything we use to suit our own particular needs. In fact, most of us would much happier if anything we purchased for our own use also came with schematics and source code. But engineers are anything but typical consumers, and using our own wants and needs as a model for what we design is a mistake. However elusive it is, we need to build that empathy for the casual, uninformed customer, and design something that will create a delightful experience for them. If that results in a product that happens to make us happy as well – that’s a wonderful bonus.