Breaking The Fourth Wall

The term "fourth wall" is used in performance art to describe the invisible barrier between the actors and the audience. On occasion, a performance will "break the fourth wall" by having an actor address the audience directly. While there are many examples in classical plays, my own vivid memory of one example is of the Burns & Allen Show on TV, when George Burns would turn directly to the camera and talk to the audience, one-on-one, about what was transpiring on the show. There actually was no audience on the set, just a camera, but Burns broke the fourth wall just by acknowledging that an audience eventually would be watching the show.

As product development engineers, we often hide behind the fourth wall that separates us from our customers, the end-users of our product. We work on products, oblivious to the fact that they eventually will be interacting with our customers. We sometimes design products for ourselves instead of our customers, or ignore annoying little "features" that might drive customers crazy hoping maybe no one would notice, or design individual products without much consideration how a customer will assemble them into a system. In effect, we act on a soundstage in front of a camera, oblivious to the audience behind the fourth wall that will eventually view our performance.

Last year I had a rare opportunity to meet with a large customer. I got to break the fourth wall. This customer owned hundreds of our products, from desktop machines up to multi-million dollar high-end servers. Along with a couple of senior engineers from the other product families, we were to present our low-end, mid-range and high-end product roadmaps. While I went into the meeting with excitement and pride, I crawled out of there feeling like a wounded puppy. And I would go back in a second.

In the meeting, the first thing the customer mentioned was connectors. Connectors? We wanted to talk about processor architectures, memory capacity, and IO options. Who cares about connectors? Well, the customer cared. On our current high-end products, the serial console connector is an DIN connector, similar to most keyboard or mouse connectors. They found that if the cable is bumped or tugged, the DIN connector could fall out, requiring physical access to the datacenter to re-insert the cable. And very few individuals were allowed physical access to the datacenter. "Why couldn't you use a captive connector, like an RJ11 or DB9?" they asked. I had no answer.

The next issue they raised was the command line interface for managing our products. Each product family had different commands. And when two product families happened to have the same command, the options and arguments were often different. "We have to train our employees on three different command sets," they explained, showing a "cheat sheet" they issued to all their system administrators showing how to do the most common tasks on each product line. "Why can't you have one set of commands for all your products?" Again, I had no answer. We had created a great command line interface for our product line, with exactly the features and options our product needed. The engineers working on the other product lines did the same thing for their products.

The honest answer to both of the questions is simple: We failed to break the fourth wall before we shipped the product. The customer knew the answer; they were just trying to make a point and get us to realize it ourselves. Aside from the tongue lashing, the customer did praise our products: we did a great job engineering our products, but we could do better. And the customer expressed how happy they were that we development engineers were coming to visit them -- they were glad to see the fourth wall being broken and hoped that our encounter would have a lasting impression. It did.

In development, we need to break the fourth wall -- the invisible barrier that separates the developers from the customers. We need to see how customers use our products, understand their issues and concerns, and internalize their pain. And nothing helps internalize pain than feeling it first-hand. It's not enough to read articles, or listen to stories second or third hand. I learned a lot from that customer visit; the people who listen and read my story might only learn a small fraction of it. We need to get all of our developers out in the field, meeting with customers directly, accompanying our Service Engineers on customer calls, shadowing our Tech Support Engineers in our Call Centers, and talking to our Field Engineers (who in many ways are our customers as well). When we break the fourth wall, both our products and our customers will benefit.

Copyright 2007, Robert J. Hueston. All rights reserved.

Post a Comment:
Comments are closed for this entry.

Bob Hueston


« July 2016