Sunday, July 15, 2007

A prescription for creating great products

Have you ever thought about what causes a company to create a bad product?

I could quote from dozens of sources that have extensively analyzed the work environment; ranging from immature technologies, lack of executive focus, passing through the rising cost of supporting pension plans, incompetent vendors, unmotivated work force, and on and on.

Instead, I offer one thought that summarizes them all:
"People do not create bad products because they are incompetent;
they create bad products because they cannot tell the difference."

The quality transfusion

My best advice to any business trying to end a losing streak on the market is to expose each employee to a product recognized as the best in its segment. It should not be a competing product; while you are trying to copy their product, they will be busy building something better - not to mention the potential of copyright lawsuits.

During the next department meeting, place an iPod on the table and talk about it. If you are feeling venturous, skip the meeting, and take the people to a BMW dealership to inspect a 3 Series.

Tell them to take their time, turn the knobs, touch the material, operate it. Hint: Do not take your entire department to the BMW dealership if you really want a shot at a test-drive.

Letting them see and touch a product recognized for its excellence will infuse their senses with something new: the feeling experienced by a customer purchasing a great product.

Knowing the difference

The next time your team designs something that does not live up to that experience, they will know. And by knowing the difference, they will go back to the drawing board and will ask what is missing until they get it right.

It may take several trips between prototypes and sketches, but fear not, the losing streak will be over on the first one.


BRyan said...

This seems like a great idea. Can we get the teams to do this before they write the requirements?
Usually the problem with mediocre goods or products is that the requirements gathering stage is either skipped or not paid enough attention to. That leads to the 'can't tell the difference' part, since "Hey, It was developed according to spec!" becomes a get out of jail free card.
Also, sometimes the basic content is Compromised leading to the less than optimal product.

Denilson Nastacio said...

I think it is more than requirements. Surely, requirements play an important role, but the "can't tell the difference" statement is spread along the entire chain.

There are gaps even on good specs written over several months. Some J2EE specs come to mind. The question is how the "team culture" fills those gaps when they need to make a choice in the middle of the project. Compromises are a necessity, but a team that "can tell the difference" knows which compromises are acceptable or not.

As an example, just the other day a friend of ours test-drove a Saturn Outlook, which can cost north of US$40K with all options. They liked everything, but mentioned a cheap Saturn plastic emblem at the center of the steering wheel. Milling that piece out of a aluminum or using a denser piece of plastic would have cost virtually nothing compared to the price of the car and would not have cast a shadow in their otherwise good impression.

Featured Post

Crowds in the clouds, a brave old world