3 Costly Product Development Fails: Lessons Learned

We all make mistakes, but when a product development process fails it can have far-reaching financial and competitive consequences. Here are three classic examples of preventable product disasters that high tech developers are still learning from (and laughing at) today.

Microsoft Vista: Too much, too soon

When Microsoft launched its new Vista operating system  in 2008, it soon realised it had a big problem on its hands. Vista needed more powerful machines than the mass market, at that time, could provide. Intel had pushed Microsoft to certify underpowered, inexpensive machines, and Microsoft had caved in.

The result was a product that performed terribly for many customers and was dogged with bugs and compatibility issues. Before long users who had upgraded from Windows XP to Vista were all reinstalling their original OS. Apple were quick to capitalise on the perception that PCs were slow, plagued with problems and generally outclassed by the Mac. All of which helped fuel its ascent to technology behemoth, and gave us a few good laughs at Microsoft’s expense:

The value of document management system for sustainable product development

Lessons for agile development

There were clearly unique pressures at play in Microsoft’s decision to release Vista when it did, but it dealt their reputation a body blow at a key time in their struggle with Apple.

But if seamless, backward compatibility was an ‘essential’ part of Vista’s commercial plan, maybe Microsoft should have delayed the launch until this was achieved - or changed the specs to ensure other goals could be met without compromising the performance of a vast market of legacy machines.

It’s a lesson in the importance of following product development best practice from ideation and R&D, through to proof of concept and delivery. These are the rules that all brands, great and small, are bound by. A key part of any development process is organising and agreeing on delivery priorities, and making sure the end product achieves them. Functional requirement documentation should list the essential, desirable and ‘nice to have’ features of any product. There should be systems in place to ensure the ‘essential requirements’ are agreed on and have been met before release.

A closer look at Document Control for ISO 9001

Late to a party that never really started

Releasing products too early or too late is a constant risk for those involved in high tech development. Release an unfinished or unstable product and you risk disappointing customers and losing loyalty. On the other hand, endless delays can risk losing product momentum, capitalising on customer enthusiasm, or even missing opportunities altogether.

Here’s another famous computing product beset by development delays and launched at precisely the wrong moment: The Sony eVilla.

Launched in 2001 the eVilla was an ‘internet appliance tool’, whose only function was to access the internet. Through its interface you could write emails, browse the web and ‘play video’. All based on a subscription model, of course. The product took 18 months to develop and was half a year late, by which time the moment of the ‘internet appliance’, if there ever really was one, had well and truly passed.

Eclipsed by the affordable PC revolution and by an internet that was demanding more flexible and sophisticated software, the Sony eVilla was simply unable to perform. The product was pulled almost instantly and all its customers were fully refunded. As their spokesman gloomily admitted 3 months after shipping started:

 "The product did not meet our expectations, it did not operate as planned."

Maybe Sony couldn’t have predicted the seismic changes that were about to take place in our personal computing habits. It’s true that plenty of other brands experimented and lost in this space.

But there were many other mistakes made in this development process. And what kind of monster thought we might want to browse the web in portrait, anyway?

It’s not rocket science... Except when it is

Collaborating at distance is a modern reality for companies, but you need the right tools and procedures to really make it work.

In 1999, when NASA outsourced work on the rocket boosters of its Mars Orbiter Satellite to Lockheed Martin, something went badly wrong. NASA was using metric measurements but their UK based collaborators assumed otherwise. The result was rocket boosters that propelled the craft in the wrong direction and a multi-million dollar mission lost to heliocentric space for all eternity.

Apparently, the potential problem was picked up and reported prior to the project being signed off, but because the correct form was not used to log the issue, corrective action was not taken.

As Edward Weiler, NASA associate administrator for space science commented ruefully after the event:

“The problem here was not the error; it was the failure of NASA's systems engineering, and the checks and balances in our processes, to detect the error. That's why we lost the spacecraft.”

Lessons from the Space Age

The lesson here is simple, adopt a system that makes it easy to monitor the work of collaborating partners and track potential problems centrally. Choose tools that facilitate easier communication between parties through a single platform, with notification and approval processes that cannot be circumvented or ignored.

Any product development process is fraught with the risk of failure. But if the tools you use to manage these processes embody a ‘risk based’ approach to the challenge of high tech design and build, many of these pitfalls could be avoided.

Still, mistakes do happen. And, however bad things seem, maybe you can console yourself with the thought that you haven’t made a simple maths error which consigned a $125 million satellite to the oblivion of deep space.