Another ex-Associated Content article...from 2008
Here are some examples of great and not so great high technology products. The great products function as complete systems; and the teams that create them need to function as complete teams.
Isn't technology wonderful when it works correctly? Today's iPhone is an example of a high technology device which works the way that it should. Not so long ago the equivalent successful gadgets were the Palm Pilot, which for its day was so robust and reliable, and before that there were the Psion PDAs. These are (or were) devices which when you took them out of the box did not require inordinate time with the manual to understand. The interfaces and design are (and were) intuitive.
The teams that make successful products do not point fingers of blame at other organizations. They take ownership of the entire customer experience. You do not get the sense when you use one of these products that you are dealing with the output of a hardware team and a software team. The devices operate uniformly the way that you would expect them too.
Each of these devices had predecessors who had already established a hold on and defined the market to some extent. There were many little organizers before the Psion came along, there was the Newton before the Palm Pilot, and there had been many 'smart' phones before the iPhone. However, the teams that created the successful products were not put off by their ancestors. They also did not think in terms of incremental improvements of the products of the past. They were ambitious in their approach. The Psion team took on every aspect of putting a PC in your pocket. The Palm Pilot team looked at the difficulties of synchronizing email to a pocket device and created a very usable system. The iPhone team created a new and simple user interface paradigm that not only simplifies working with software it also simplifies the interface to the telephone itself.
However, there are a few devices and pieces of software around that leave me baffled as to how anyone could think that they were ready for general use. Take, for example, the cable television software that comes with our cable contract. This system seems to be extraordinarily buggy. The controller box needs to be rebooted once or twice a week. There are 40 or so buttons on the remote control for the box, it seems very complex, although I only use a subset of these buttons. The software itself is invariably slow to respond and temperamental. It is as though the team that wrote it did not have a good model for how to handle events from the remote control, and the system loses track of where it is, and everything needs to be rebooted. The time taken to reboot the box is also impressive and somewhat depressing if you want to watch a particular show and the system has chosen this particular moment to require a reboot. The most baffling aspect of this is the amount that the cable company wants to charge me to use their buggy software, and view their terrible adverts!
The Adobe Acrobat/Firefox plug-in is another example of a poorly crafted hand-off between two technologies. Sometimes the pair just works. Often they do not! I can never tell which behavior I will get; and if problems occur, I will need to stop Firefox, find and kill the out of control Acrobat process in the Task Manager, and then restart Firefox. Perhaps the next Firefox release will resolve this issue. And obviously, Internet Explorer brings with it so many concerns that it is not a viable solution to this particular problem.
However, these two examples of poorly constructed systems provide a hint as to where problems originate. In both instances, there is a clear demarcation between the two development teams involved. You know that you are leaving one program and going into another program when the Adobe plug-in kicks into life in Firefox. Every time I reboot the cable box, I get to see the trademarks and brand name of the teams that developed whatever software it is that runs that particular system. You get the sense that the Firefox team said 'not my problem' and the Adobe team said 'not our problem' and the result is the unsatisfactory user experience that probably stops many people from using either product.
From a customer's point of view, I would be happier if I didn't know that two development teams were involved and the product just worked as a single system.
Creating the environment for teams to take an overall users perspective is difficult. It takes visionary leadership and brave leaders. It is safe to say that Apple, Palm and Psion, during the creation of the iPhone, Pilot and Psion PDAs respectively had leaders who could look beyond internal politics and positioning and inspired their teams to create wonderful products for their customers.