The Remote Control Syndrome

There is a particular kind of product failure that everyone recognizes and nobody admits to creating. I call it the remote control syndrome.

You have seen it before. It is the interface with forty buttons, twelve sections, three navigation systems, and one tiny action that people actually use. Everything is visible because somebody, at some point, decided visibility was the same thing as usability. It is not. A remote control does not become easy to use because every possible function has its own button. It becomes a plastic reference manual with batteries. Software teams build the same thing all the time. We just make it more expensive, give it rounded corners, and call it a platform.

Every button has a backstory

Pick up an old television remote. The power, volume, and channel buttons are worn out. The rest look as if they have never been touched by human hands. There is probably a button labeled SAP, another that changes the aspect ratio into something nobody requested, and at least one mysterious control that appears to do nothing. Press it twice and the television may start displaying subtitles in Swedish. Nobody knows. This is what happens when every function is treated as equally important. The interface stops communicating priority and starts presenting inventory. The same disease appears in software products.

The dashboard has fourteen widgets because fourteen people had fourteen concerns. The settings screen has six tabs because removing one option would require a meeting. The main navigation contains links for features used by 2 percent of customers, but apparently those customers know somebody important. The product did not begin this way. It probably started with one clear idea. Then came the requests.

Sales needed an exception for a large prospect. Support wanted a shortcut for a recurring problem. Marketing wanted a banner. Legal needed three notices. Finance requested another export format. A manager saw something interesting in a competitor’s product while waiting at an airport. Nobody wanted to make the product worse. That is the annoying part. Every individual request sounded reasonable. The final result was still terrible. Products usually become complicated one sensible decision at a time.

The four horsemen of product complexity

In my experience, four forces tend to produce the remote control syndrome:

1. Design by committee.
2. Decisions made without useful evidence.
3. Arguments that sound logical but prove nothing.
4. Fear disguised as responsibility.

They usually arrive together.

First, too many people need to approve the design. Then nobody has enough evidence to settle the disagreement. The meeting fills with opinions wearing business casual. Finally, everyone becomes afraid of removing anything.

Congratulations. You now have another settings page.

Design by committee

There is an old joke that a camel is a horse designed by committee. This is unfair to camels. Camels work.

Design by committee usually does not mean that several people collaborate. Good products require collaboration. Engineers, designers, researchers, support teams, and product managers should challenge one another. That is how you avoid building something elegant, technically impressive, and completely useless.

The problem begins when collaboration turns into shared authority over every decision. When everyone must be satisfied, nothing can be removed. Every concern becomes a requirement. Every disagreement becomes an additional option. One person wants the workflow to be fast. Another wants it to be safe. A third wants it to support a customer who performs the task once every leap year. The compromise is usually a modal window with seven fields and an “advanced” section. Everyone leaves the meeting mildly unhappy, which is somehow interpreted as balance.

A product needs a clear direction. Someone has to decide what belongs, what does not, and which trade-offs the team is willing to make. That does not require a tyrant wandering through the office deleting buttons for sport. It requires ownership. The person responsible for the product should listen carefully, understand the evidence, and then make a decision. Not every opinion becomes a feature. Not every complaint becomes a roadmap item. Not every customer request deserves permanent residence in the interface. This sounds obvious until an important customer asks for something. Then the product vision suddenly develops flexible morals.

Users are not a product roadmap

Listening to users is useful. Doing everything users request is not.

Users are excellent at describing pain. They can tell you where they are frustrated, what takes too long, what they cannot find, and what prevents them from completing a task. They are usually less reliable when prescribing the solution. A customer may ask for another button when what they really need is a shorter workflow. They may request more configuration because the default behavior is wrong. They may ask for an export because they do not trust the reporting system. The request is evidence of a problem. It is not necessarily the correct design. This distinction disappears quickly in companies that confuse customer service with product strategy.

A request arrives from a large account. Sales marks it urgent. Product adds it to the roadmap. Engineering implements it. Design finds somewhere to put it. Support writes an article explaining it. Six months later, nobody remembers why the feature exists, but removing it is now considered too risky. The button has achieved tenure. The job is not to obey users. The job is to understand them.

Data helps, but it does not run the company

The obvious response to opinion-driven design is to ask for data. Good. But data is not holy water. Sprinkling numbers over a bad decision does not make it scientific. I used to say that numbers never lie. That is too generous. Numbers are perfectly capable of misleading people when they are incomplete, badly collected, or attached to a convenient interpretation. The numbers may not be lying, but somebody is often helping them tell a very specific story. A dashboard can show that engagement increased while politely omitting that users now need twice as long to complete the same task. Conversion can improve while cancellations rise a week later. Support tickets can fall because customers stopped using the feature. Everything is green. The building is on fire.

Data does not replace judgment. It gives judgment something better than instinct to work with. A useful process is simple: Start with a hypothesis. Decide how you would recognize success or failure. Test the idea with the smallest reasonable amount of risk. Observe what people actually do. Then make a decision. The difficult part is agreeing on the question before seeing the answer.

Teams are surprisingly talented at choosing metrics after the experiment. By an astonishing coincidence, they often select the metric that proves the person with the most authority was right. That is not experimentation. That is numerology with event tracking.

Anecdotes are cheap

Without data, teams tend to promote anecdotes into laws.

“My wife did not understand it.”

“One customer complained.” “Nobody has asked us to remove it.”

“Our competitor has the same feature.”

These statements may be interesting. They are not conclusions. Your wife may be correct. The customer may have found a serious issue. The competitor may have spent six months testing the solution. Or none of those things may be true.

The point is not to dismiss feedback. The point is to understand its weight. One confused user is a signal. It is not the entire market. Ten requests may indicate real demand. They may also come from ten customers who all belong to the same unusual segment. Silence may mean satisfaction. It may also mean people gave up. Good product teams collect these signals and investigate them. Bad product teams turn whichever anecdote arrived most recently into a priority. This is how roadmaps develop mood swings.

“Everybody else does it”

Competitor research is valuable. Copying competitors because they probably know what they are doing is less valuable. You can study another product to understand conventions, expectations, and possible solutions. You cannot see the decisions, constraints, internal politics, or failed experiments behind the interface. Maybe that strange workflow converts extremely well. Maybe the chief executive designed it on a napkin. Maybe the company is already replacing it. You do not know.

Seeing the same pattern in several products does not automatically make it correct. It may simply mean everyone copied the same original mistake. The phrase “industry standard” has protected many terrible interfaces from serious examination. Sometimes the standard exists for a good reason. Sometimes it exists because nobody wants to be the first person in the meeting to ask why the emperor needs three dropdown menus. Use familiar patterns when familiarity helps the user. Do not use them as an excuse to stop thinking.

Logic is not evidence

Another common problem appears when a reasonable-sounding explanation is treated as proof.

“This is simpler, so users will prefer it.”

“More options will make customers feel in control.”

“The button is larger, so more people will click it.”

“People expect the settings to be here.”

All of those claims might be true. That is what makes them dangerous. A plausible explanation feels complete. It saves us the inconvenience of checking what actually happens. Product teams do this constantly. We tell ourselves a story about user behavior, build the feature, and then defend the story as though the customer signed it. When the result is bad, we rarely question the original reasoning. Instead, we add another feature to fix the previous one.

The remote control gains a second page.

The proper response to uncertainty is not endless debate. It is a test. Put the design in front of people. Release it to a small group. Compare alternatives. Watch where users hesitate. Measure whether the change improves the outcome that matters. A four-hour meeting about button placement is not rigor. It is four expensive people avoiding an experiment.

Fear is not a roadmap

The final horseman is fear. People sometimes describe this as the “lizard brain,” the primitive part of the mind that reacts to threats before rational thought gets involved. The neuroscience behind that model is oversimplified, but the metaphor remains useful. Every company has a lizard in the room.

What if users hate the redesign?

What if revenue drops?

What if support volume increases?

What if we remove something and three customers complain?

These are reasonable concerns. Problems begin when concerns become automatic vetoes. The existing product feels safe because its failures are familiar. Everyone knows where the bodies are buried, and there is probably a dashboard for them. A new design introduces unfamiliar risks. Even when it solves an obvious problem, the organization often prefers the current mess because the current mess has documentation. So the team preserves the old workflow, adds the new workflow, and gives users a setting to choose between them. Now there are two messes.

Fear creates exceptions. Exceptions create settings. Settings create buttons. Soon the product includes several generations of decisions layered on top of one another like an archaeological site with a billing system. Risk cannot be eliminated. It can only be managed. Test with a limited audience. Define what failure means. Make the change reversible when possible. Monitor the results. Expand gradually. That is responsibility. Keeping every old decision forever is not responsibility. It is hoarding.

Apple also got things wrong

Apple is often presented as the company that ignored everyone, trusted its vision, and produced perfect products through the sheer force of Steve Jobs staring intensely at a prototype. The real story is more useful because Apple also made bad design decisions. The early iPod worked because it reduced a complicated task to a few controls. The wheel made scrolling through large music libraries fast, and the device could be operated comfortably with one hand. Then Apple introduced the third-generation iPod in 2003 and moved the playback controls into a separate row above the wheel. It looked clean. It was also less comfortable to operate. The thumb had to move between the wheel and the buttons, and the interaction lost some of the physical simplicity of the earlier design. Apple did not solve this with the iPod nano a few months later, as I wrote in the original version of this article. The Click Wheel appeared with the iPod mini in 2004 and later reached the fourth-generation iPod. The iPod nano came afterward, in 2005.

The important point is not the exact family tree of small white rectangles. The point is that Apple iterated. It tried a solution, learned from it, and converged on something better. The company maintained the goal of simple, one-handed control while changing the implementation. That is what strong product direction looks like. It is not the ability to predict the perfect design before building anything. It is the ability to recognize when the current design is wrong without turning the correction into another layer of complexity. Apple did not avoid mistakes. It avoided preserving every mistake as a preference in the settings screen.

Simplicity needs an owner

Complexity happens naturally. Companies grow. Customers ask for things. Regulations change. Teams discover edge cases. New markets create new requirements. Old decisions become dependencies. Nobody needs to manage this process. It manages itself.

Simplicity is different. Someone has to defend it.

Every new feature should pay rent. It must justify not only its development cost, but also the permanent burden it places on the product. Someone has to maintain it. Someone has to test it. Someone has to document it. Someone has to answer support tickets about it. Every user who does not need it still has to navigate around it. That is the true cost of a feature. The code is often the cheap part.

A useful question is not "Can we add this?" Engineering can usually add it. Given enough coffee and a flexible interpretation of the quarter, engineering can add almost anything. The better question is “Does this deserve to exist in the product forever?” The answer should occasionally be no.

Removing things is product work

Adding features looks productive. There is a ticket, a launch, a release note, and perhaps a small celebration involving cupcakes. Something new exists at the end. Removing a feature looks suspiciously like admitting that the company was wrong. So features remain. Even abandoned features remain. They become “legacy workflows,” which is the polite name for mistakes with customers.

But subtraction is part of product development. A feature that no longer serves the product should be removed. A setting used by almost nobody should be questioned. A workflow created for an old constraint should not survive merely because the constraint once existed. Of course, removal requires care. Measure usage. Identify affected customers. Provide migration paths. Communicate clearly. But do not confuse careful removal with permanent preservation. A product cannot remain coherent if it carries every decision it has ever made. At some point, the attic needs cleaning.

The cure

The remote control syndrome does not have a clever cure. It has a set of boring disciplines that must be practiced repeatedly. Give the product a clear purpose. Give someone responsibility for protecting that purpose. Listen to users, but investigate the problem behind the requested solution.

Use data, but do not allow dashboards to make decisions by themselves. Treat opinions as hypotheses. Test uncertain ideas instead of debating them until everyone loses the will to live. Make changes in controlled steps. Remove features that no longer earn their place.

Most importantly, remember that every option has a cost. A product does not become simple because the team has good taste. It becomes simple because somebody keeps saying no to perfectly reasonable requests. Without that discipline, every product eventually becomes the same object: a rectangle covered in controls, designed to do everything, and pleasant to use for almost nothing. Every button will have a justification. Every section will have an owner. Every setting will have a customer who once requested it. And somewhere inside the interface, buried beneath years of reasonable decisions, will be the simple product you originally intended to build.