Good vs Bad IT Product Managers

So what makes one IT product manger any better than another? I've spent a lot of time both working as a product manager and working with other product mangers and I think that I've got this figured out. I think that we can all agree what a good product manger looks like: they have successful products that customers want and internally everyone wants to work on their product because it is recognized as a "good place to be" from a career point-of-view. On the other hand, a bad product manage is also recognizable because their products are struggling, nobody really understands what they do or why they are any better than anyone else's products and internally nobody is excited about working on anything that touches this product.

So how do good product managers get that way? The key is that really good product managers know their product and the environment in which it operates inside and out. This is the one thing above all others that sets them apart. All too often, program managers get placed into product manager positions (I mean after all, aren't they really the same thing?) and don't make the transition that is required to fully become a product manager.

Program managers (and bad product managers) tend to focus on just the day-to-day parts of creating and launching a product. Good product managers do the same; however, this doesn't take up all of their time. Instead, good product managers spend a considerable amount of time trying to prepare customers for the new product / features and making sure that end user feedback gets back to the product developers even as the product is being created.

You would think that at least bad product managers would have projects that run more smoothly because of the extra time that they invest in program management activities. However, this is generally not the case. I believe that the extra level of motivation that the rest of the team brings to a good product manager's product development program allows him/her to spend less time managing the process and more time making sure that the product will be well received.

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.

Well Aren't You Special?

So what makes being an IT Product Manger any different from being a regular product manager? Hey, we're better! Well, maybe not BETTER, but we do see ourselves as being part of a very special group: technical professionals who have also been invited to live in the business world.

What this boils down to is the simple fact that what sets IT Product Managers apart from all others is that they need to be good at doing three things (at the same time of course):

1. Think/Act/Breath Like a CEO: simply because you are. An IT Product Manger IS the CEO of his/her product. It is not a stretch to say that the product will succeed or fail based on it's Product Manger's abilities. How's that for some pressure?
   
   
2. Understand the Bottom Line and Up Time: cut 'em in half and you'll find that IT Product Managers don't just have a left brain / right brain thing going on, they've also got a tech / biz thing happening. As we move from meeting to call to meeting, we are constantly shifting gears in order to deal with both sides of the company. We are the bridge between to very different worlds.
   
   
3. Be A SME: this is the key. This is the one feature that distinguishes a Product Manager from a Program Manager. IT Product Managers have to be Subject Matter Experts. We have to truly know our products from the inside out as well as the technologies that they use and why they are needed. More than any other feature, this is what makes IT Product Managers so special -- the immense amount of knowledge that we need to know in order to be able to do our jobs.
   
   

I think that it was Charles Dickens who said "... It was the best of times, it was the worst of times." For IT Product Managers it couldn't be truer. There are times that we feel, move, and act with all of the power of a true CEO. However, then there are those times that we feel overwhelmed with the complexities of everything that we still have to accomplish.

No matter, now you have found this blog and together we shall find a way for you to overcome all problems. Exactly how you are going to do this is a topic for a future posting...

What The Heck Is An "IT Product"?

Good question,eh? I define an IT product as being a piece of code or a service that a firm's IT department delivers to a customer. The customer can be internal (ex: email or expense reporting tools) or external (ex: CRM, ERP, virus detection, anything that MicroSoft makes, etc.) You're IT department probably delivers a long list of products and services. This leads to the question...

Are you creating the right IT products? Does your staff have a polished and efficient product management framework with which to capture IT product requirements, develop the product, and then roll it out to your eager and waiting customers? Or is your IT product development process a mess: wrong products, missed schedules, and unhappy or (even worse) disinterested customers?

Hey, who ever took classes on this stuff? We all focused on programming languages, databases, and the odd English Lit. class. Well, they say that it's never too late to learn and it turns out that Product Management for IT products and services can be fairly easy and straightforward if you understand what you are doing. In this blog we'll share with you the good, the bad, and the really ugly things that you should both be doing and not doing.