Driving from the Backseat

An article^[1] about the spectacular failure of high-tech startup company General Magic is revealing. The author innocently touches on the root cause of the product's lack of success when she says that Marc Porat, the president, "launched his engineering team to design the device of their dreams." There is no irony in her statement. It seems perfectly natural for the engineering team to do the designing, yet that is precisely the cause of the problem. Later in the article, she quotes one of the engineers as saying, "We never knew what we were building. We didn't write specifications until 8 to 12 weeks before we finished." Again, neither the engineer nor the author notes the irony. The article seems to suggest that things would have worked out better for General Magic if only the engineers had drafted those specifications a month earlier.

^[1] Michelle Quinn, "Vanishing Act," San Jose Mercury News West Magazine, March 15, 1998.

No matter how early in the development process specifications are drafted, they cannot substitute for interaction design. And no matter how hard they try, programmers cannot consistently arrive at a successful design. Not only are their methods, training, and aptitude wrong for the job, but they are caught in a strong conflict of interest between serving the user's needs and making their programming job easier. Yet, in company after company, software engineers are allowed to control the development process, often from start to finish. Sometimes their control is overt, but more typically it is indirect.

I witnessed this subtle control at a very successful, midsized Silicon Valley company. At the meeting was the president, a very savvy, veteran businessman who founded the company, along with the senior programmer responsible for building the product. The president showed us the product and demonstrated its power, which we could clearly see, but we could also see that its power was hard to use and its interface was overly complex. Our design team and I instantly recognized that the programmers had "designed" the product while they constructed it in the way a beaver "designs" his dam while he builds it.

The president complained that a competitor with a weaker product was stealing away market share. He was at a loss to explain why because he knew that his product was more powerful. Although the president had called us in to help him fight off the competition, he had given his senior programmer the authority to take whatever action he deemed appropriate. It was clear to us that the product badly needed some behavioral changes, and we presented our case to them both. To us, it was a simple and straightforward redesign project that would take a few months of effort and would make their product enormously more useful, practical, powerful, and pleasurable more competitive. However, the senior programmer astonished us by asking that we not actually make any changes to the product's interaction. He considered it just fine the way it was. He felt that the product's market difficulties stemmed only from the company's sales force not being sufficiently well trained in the product's use. He wanted us to prepare some in-house promotional materials so their salespeople could be more effective. He was in complete denial about his product's shortcomings, despite the incontrovertible evidence that an "inferior" product was beating it.

Programmers devote so much of their time and energy to learning about software that it was inconceivable to him that his users would not want to take the time to understand his work. He was willing to accept that the problem lay with his own company, but not with his role within it. He blamed the sales force for not helping the customers learn about the product. He was willing to do the work to solve the problem by accepting the task of developing the new training aids, yet he was utterly oblivious to any hint of his own culpability in the product's fall from grace.

The high-handedness of this engineer was breathtaking. Not only was he blinded by his own pride in his demonstrated ability to build a powerful product, but he was blinding his boss the president to his obvious inability to design it in such a way as to make their users happy.

The company's product was the first of its kind, pioneering a new method of tracking manufacturing systems. The company was a fast-growing darling of Wall Street with a spectacularly successful initial public offering of stock two years before. The company had been praised in the business press and lavished with awards from civic and business groups. It seemed that it was doing everything right, and its market capitalization certainly attested to its success.

But success like that is watched just as closely by competitors as it is by its investors, partners, and other supporters. The company's competitors clearly saw the strength of the market, and just as clearly saw the weakness of this company's product. They could see how powerful and feature-packed it was, but they could also see that it was a dancing bear. It delivered new functionality, but it didn't make its users happy. It danced, but it didn't dance well. It didn't take a rocket scientist to spot the vulnerability of this company, so the competition copied many of the features of the product but made its product easier to use. Its management reports could be understood and manipulated by managers, while the older company's reports were obscure and static. The upstart competitor had stolen 60% of market share away from the older company with a product that was less powerful!

The president's own engineering background hampered him. It had helped him to create his powerful product, but it now stood in his way, making it difficult for him to see what an obstacle his senior programmer was. Deeply ingrained in the software-nerd ethic, he saw his senior programmer's attitude as perfectly normal, while our team was flabbergasted. The president was not in charge. His senior programmer was driving the entire business from the back seat.