What’s In a Name Anyways?

The company has a lot of strengths – the ability to name products has never been one of them however. Certainly the subject matter has something to do with that. There is only so much that even the most creative product managers can do given the nature of middleware and systems management software. It is just inherently boring stuff.

Before the product is given its official external name by TPTB, it usually has a code name attached to it so that everyone working on the project has a convenient label to apply to product artifacts and design materials. Many times the code names make more sense than the official name (to the developers at least). By the time the official product name is christened, sometimes you are left wondering what those folks doing the naming are smoking.

A couple of years ago, the component that I was working on went into the Official Naming Factory and came out with the sanctioned moniker of “Tivoli base services”. I kid you not. Note the capitalization there. Maybe the worst, most generic, and non-descript label ever invented. One should never underestimate the depths to which these product naming specialists will sink when given an opportunity. I think I spent the better part of 2008 and 2009 bitching and moaning about that name to anyone that would listen. But don’t worry – we remedied that last year with a new name: “Tivoli’s process automation engine”. Enough said.

In 1993 I was working on a tiny skunks works-type of project with four other developers. We were exploring and prototyping the use of the Smalltalk language under the OS/2 operating system for use in network and system configuration management products in the IBM Networking Software Division (NSD). The code name for the project was SCOOP (System Configuration Object Oriented Prototype) – short and sweet and the acronym wasn’t even that much of a stretch from what the software actually did. The developers loved it. SCOOP showed promise and we were given the budget to develop the prototype into a product. By the time SCOOP made it to market, it was officially named “IBM NetView Network Planner/2”. Rolls right off the tongue doesn’t it? Hard to believe that 18 years have since passed.

When I first came down to the park in 1988, NSD was using local rivers as project code names -Neuse and Eno were two big NetView projects that I remember that used that policy. In the early 90s, at least a couple of products were using weapon systems as code names – I worked on a project named Tomahawk that was hatched briefly after the Persian Gulf War.

Enough about ancient history. Last fall, I participated in a 6-week task force that explored the feasibility of converging two existing products into a new merged product. The task force included various technical leaders from the two products being considered for the merge. Neither of these products is selling as well as the leadership thinks they should and there is functional overlap between the products that is causing confusion for our sales force and, more importantly, our customers.

So we developed product design, architecture, and cost estimates for this new thing. A decision was made in February to actually go forward with that decision to merge those two products – as well as a third product - into a new, single, converged offering.

There are always casualties associated with these kinds of mergers. Winners and losers. When there is significant duplication and overlap in functions between the products, then some components get reduced in scope and or get phased out altogether. The software industry uses the term deprecated to refer to these losers.

For instance, that work that I did in January (blogged about here) got shit-canned. Sent to the big bit bucket in the sky. I developed it and got it working. Shepherded it through test. Wasted a month’s worth of weekend overtime on it. By the end of February, the converged product fireball had fallen right on top of it. Splat. It will never ship to customers. Oh well.

But back to product naming. So what do we call this new product? We had been referring to it as the “Converged Service Management Solution” informally. Last year during that task force, this thing was loosely referred to with the acronym TSLM. That was really confusing because we actually shipped a version of our product last year for the Software-As-A-Service market called TLSM. TSLM vs. TLSM. Dyslexia anyone?

In late March, the leadership sent out an email requesting candidate code names for the new converged product and a week or so later a winning name was chosen: and the winner is…

Pittsburgh

Wow! Well that is interesting I guess. I didn’t want to pee in anybody’s cornflakes about that name – it certainly beats the hell out of TSLM. But Pittsburgh is actually located at the confluence (not convergence) of the Alleghany and the Mon. Oh, and in our new product’s case, there are actually three products being merged into a fourth. Four Rivers Stadium? I guess it is close enough for now.

At least four of us (that I am aware of) on this new team have Pittsburgh in our background. Three of those four are Pitt Grads so my alma mater is well represented. I have also noticed that a large number of folks seem to omit the h when spelling Pittsburgh. I am of course making it a point to correct those misspellings.

The convergence of three separate products into a new fourth product also necessitates an update to the organization structure. So the last couple of months have been interesting as the new product organization has been rolled out. I find myself now working for a new manager under a new second line manager and with an almost entirely new set of department members as colleagues. Pretty exciting (and hectic) times. It is shaping up to be (yet another) busy rest-of-the-year. Forgive me if the blogging velocity isn’t quite what it was last year. Blame it on Project Pittsburgh.