Friday, May 16, 2008
IT Product Disasters: Part 1 Of Many
We all have our own set of up close and personal product disaster stories. Just like when we're out driving and end up having to wait in traffic because there was an accident up ahead, we always hope that they won't have cleared it completely out of the way by the time that we get to the head of the line because we really want to see the horrible thing that happened. I believe that IT product disaster stories serve the same purpose: an opportunity to professionally rubberneck.
One of my stories (there are many) goes all the way back to the beginning of the '90s. I was working for a huge telecommunications equipment vendor who had started to believe the trade rags and had invested heavily in a new type of phone technology called ISDN. Basically, this was a first try at moving from the old school analog signal over copper to a new all digital signal. From the get go the deck was stacked against this product. It was created by engineers for engineers. From a user point-of-view there was no really big compelling reason to switch. Oh, and if you did switch, then you had to get all new telephones and all new connectors put into the wall.
I've never see so many people work so hard to try to make a pig fly. It turns out that this was a solution in search of a problem. After spending way too much $$$ trying to push this product onto an unwilling public, ISDN slowly morphed into a form of DSL and is now finally being put to rest.
So what can be learned from this product wipe-out? First, you have to clearly identify what problem your product is going to solve (and why it's a big deal). ISDN didn't really solve a problem for the customer, it only solved problems for the phone company. Next, you always have to be laser focused on just what the customer facing benefits of your product are. You always have to be broadcasting these benefits and then, this is key, listening to how customers respond. If they don't care, then you may have a dud product on your hands. ISDN had lots of extra bandwidth; however, in the early 90's nobody knew what to do with it.
Not every product will succeed. However, a good product manager keeps his/her eyes open and knows when to either change the product or walk away early in the game BEFORE it's too late.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment