/ Product Management

Looking to the Past

The Dude went to a trade show this week, not a newsworthy item in itself, but he was able to reconnect with a lot of old colleagues and friends.

A job the Dude left in 2009 due to grossly incompetent management, he left behind two major developments. One, a new product offering that was a blend of technology, and “good enough” capability to expand the market, the second was a transition in the architecture of the product control software.

The Dude carefully crafted both sets of requirements to prevent engineering from screwing them up. He was halfway successful…

The hardware

At the time, the company had a new platform. It was kick ass, world beating technology in their space. The problem: It was overkill for the vast majority of the market, and the price was out of reach.

The concept was simple, take the fundamentals, reduce the specs, substitute some adequate, but much much cheaper hardware, and it becomes a general purpose, large audience system.

The MRD was crafted to ensure that engineering didn’t back out of the task (they hated not designing at the bleeding edge) at hand.

The Dude noted the launch, but since he was on to another company, and another industry altogether, he never got to see it up close.

This week he got to lay his hands on it. Wow. He even got to look under the hood. Son of a bitch, they did what he asked, and it is a thing of beauty.

Of course, the marketing team that took over couldn’t help but fuck it all up. They added bells and whistles to it until it is almost as expensive as its bigger brother. Now there is no low cost product, and the difference in price between the high end and this “affordable” model is small.

Sigh.

The Software

When the Dude worked there, the main control package was ancient. It was a DOS program that someone migrated into a Win32 application in the mid 1990’s (it originally ran on Windows NT 3.51 for the true geeks) and it was a mess. About 2005, he convinced management that it was time to architect a new platform. The duct tape and bondo that kept being applied to this long past its prime application was just not cutting it.

A ground up rewrite, with a truly segmented, layered approach and full 64 bit clean code (as our data sets were often approaching the limit of a 32 bit world) was approved.

Late in the project, and too close to the time that the Dude said “Fuck it, I’m out” the UI got serious attention. There were provisional interfaces, but it was almost identical to the original UI, designed for the time when 800×600 SVGA was the state of the art in computer monitors.

The Dude got the acting VP/GM (who was also the Executive VP) to agree to bring in a consultant to guide the process. Truth was, the EVP had worked with a few UI consultants over the years, and was on board with the idea, not too much selling involved.

But they went cheap. Very cheap. Since it wasn’t the Dude’s problem anymore, he just stepped away.

What they developed and launched? Well, it sucked. Frankly, it looks like a ADHD squirrel wrote it. Workflow is clumsy, the analyses are hidden and hard to find. It isn’t intuitive, and it takes longer to do simple tasks that the older software.

This makes the Dude sad. A chance to really make a world class application, to be the benchmark, turned into a turd.

Reflections

As a product manager, you often kick off a program, giving it the best start possible. However, success requires a steady hand during the development and implementation, with minor course corrections to ensure that things don’t go too far off track.

The Dude has been a few places, and he is proud of his “children” but it does hurt to see how they went wrong.


Like what you see? Sign up for our newsletter

Looking to the Past
Share this