Why Can't IT Product Mangers Get Any Respect?

Let's look at the respect pyramid that, although unofficial, exists in nearly every IT organization. If we start at the top, then we find the Subject Matter Experts (SMEs) who are the people who really know what's going on both in the company and with the technology. These are the people who make sure that the team is really solving the right problem: "That won't work because that's not the way that we take orders for that product..." Just under them you'll find the legacy crew -- those folks who have been working on a system or a technology longer than anyone else and are the ones that everyone goes to in order to solve technology problems. Beneath them you will find the code rockets. These are the folks who have an amazing ability to turn out code or other productive work seemingly overnight. When a schedule gets tight, they are the ones to turn to.

Once you get this far down on the IT respect pyramid, things get a bit boring. That is until you get to the bottom. I've got good news for the IT Product Management world, we're not at the bottom. I truly believe that the bottom of the IT respect pyramid is reserved for the good souls who work on the Quality Assurance (QA) team. Just above them (doing better, but not by much) are the Program Managers. The bad news is the Product Managers sit just above Program Managers which is way to close to the bottom of the pyramid if you ask me.

This, of course, begs the question: why? How did IT Product Mangers come to live so close to the bottom of the respect pyramid? If you take a look at who is up at the top, you'll notice something very interesting: the most respected people in an IT organization are givers, not takers. Sure there are exceptions to every rule, but this is most often the case. Way down at the bottom of the respect pyramid you find the folks who are viewed (rightly or wrongly) as basically being takers, not givers.

This sad realization generates the question, so what can be done to improve the lot of IT Product Mangers? Clearly Product Managers need to find a way to be seen as givers. So what do we have to give? The three quick answers that come to mind are direction, status, and understanding. Direction has to do with making sure that the IT team knows what they are working on and what problem it is designed to solve. Status means making sure that every member of the team fully understands at all times how the product is coming along and what the outside world thinks about the product team. Please note that an occasional "Status" email does not even come close to accomplishing this goal. Understanding is the most important and the most difficult to do. The IT team lives an insulated life and often times does not understand why certain decisions are made or why the team or the product is viewed as it is. It is the Product Manger's responsibility to monitor all of these things and relay them back to the team in terms that they can understand.

Can IT Product Managers climb up the IT respect pyramid? Yes, but it won't be easy. If you are willing to give it time and constant attention, then you will eventually find yourself on top of the pyramid of respect and isn't that where we all want to be?

Force Majeure: What Is It and Why Care?

While reading the Wall Street Journal last week, I happened upon a very small article that mentioned that Alcoa, the large metal processing company, had declared a force majeure on alumina (also known as aluminum oxide which is used in aluminum production)deliveries from its operation in Western Australia. This somewhat boring legal term caught my eye because I've worked on a number of contracts that had a "force majeure" clause; however, I never really understood how or when it could be used. Well now thanks to Alcoa I know.

In Alcoa's case, there was a file and an explosion at another company's gas-processing facility. It's going to take at least two months to repair the plant and restart the gas supply. It turns out that to process alumina and turn it into aluminum requires a lot of gas. This means that Alcoa is going to have to cut their output and therefore forced them to declare a force majeure.

What does all this talk of aluminum mean to you? If you live in Australia, it probably means that you should go buy beer and lawn chairs right NOW because prices will probably be going up. For all other product managers, this should serve as a reminder that if your product relies on another vendor, that force majeure portion of the contract is not just "contract boilerplate" -- it really can be put into action. You need to spend some time thinking about what you would do if the unthinkable happened -- force majeure was declared. A backup plan/vendor is always good to have. If that's not possible, then a good P.R. campaign and working out the next steps that you would need to take with the folks in the legal department would be good to do.

How To Work With Sales

At the end of the day, the whole purpose of any IT product is for it to be a success. In the commercial side of the house, this means that it needs to be bought by customers and therefore more often than not, you need sales people. What strange creatures they are indeed!

In order for your IT product to be a success, you need to learn how to work with the folks in sales. Despite what TV and the movies tell us, not all sales folks are like WKRP's Herb Tarlick. Instead, they are almost the complete opposite of IT staff: outgoing, people orientated, not always good with details, multitaskers, and often befuddled by technology (but quite good with anything that they need to sell with -- like cell phones). All too often, IT Product Managers are tempted to stand with the rest of the IT crowd and laugh at them. However, you really don't want to do this -- you desperately need their support for your product to be a success.

So what's an IT product manager to do? Simple: spend some time and learn to understand this beast known as sales people. One of the best ways to start is to attend a company-wide sales meeting. These are incredible events and they can be real eye openers. What you will discover is that a sales meeting is actually a recharging event for sales folks. Engineers look with amazement as sales people hand out awards to themselves and tell each other how great the company's products are and how weak the competition is. What we don't understand is just how lonely a sales job can be. IT folks get a chance to recharge every day when we interact with our peers -- we all acknowledge each other's skills and get respect for this. Sales people on the other hand spend their days being told "No" and having their products labeled as too expensive or not having the right set of features. A company sales meeting is how they recharge.

Realizing just how difficult a sales job can be means that an IT Product manager can change how you interact with sales. If you provide them with material and facts that they can just pick up and use with customers (no reformatting or rewording needed) then you've made their life easier. If you listen to what they have to say about your product and if you show them that their feedback is being worked into the product, then you'll win a friend for life.

Getting the sales team to be on your side is the first step in being the IT Product manager for your company's most successful product ever...

Got A Minute? The Power Of Meeting Minutes

The difference between an effective product manager and an ineffective product manager often comes down to the little things. One big "little thing" is how you deal with meeting minutes. It was years ago when I was up to my neck in standards bodies work for the ATM protocol, a participant who was much wiser than I was took me aside and informed me that whoever had the role of secretary had the most power in the process. When I asked why, he explained that nobody could ever remember what was talked about during the meeting and whatever came out later in the minutes was always treated as fact no matter what was actually said.

This is a powerful truth that has ramifications in the world of IT Product Mangers. In all of the face-to-face meetings and phone conferences that we participate in quickly blur together as we move through the week. All too often folks seem to repeat themselves meeting after meeting going over issues that have already been discussed. This is simply because nobody remembers what was discussed or agreed to in past meetings.

Sometimes meeting minutes are produced; however, they are generally hard to read/use and quickly discarded. Consistency is the key to long term minute success. If you want to be an effective product manager, then you need to grab the meeting minute bull by the horns and become the source of minutes for all of your meetings and calls.

What makes good meeting minutes? The #1 thing that readers are looking for is how they are impacted by the minutes. This means that you should quickly document what the meeting was about and when it was held. Then after that you need to list the actions that came out from the meeting. Each action need to contain three things: what needs to be done, who needs to do it, and when it needs to be completed. Here's what an action should look like:

1. Action: Investigate why warp engine continues to malfunction during light speed jumps.
Assigned: Hans Solo, Due: 07/04/08

A small important point is that actions should be grouped by who they are assigned to (all of Hans' actions should be listed one after another). If during a meeting important conclusions were reached, then the should be listed BEFORE the actions. These should look like:

1. Conclusion: It was agreed by all that the Empire should be overthrown as quickly as possible.

This will always be a short list and listing it before the actions means that everyone will look at it before they go searching for actions that have their name assigned to them.

Remember the famous saying: "History is written by the winners." The same thing can be said about product management minutes and actions!

The Best Way To Communicate Is...

Here in the comfortable 21st Century, IT product managers have many different ways to communicate with their boss/team/etc. However, just because you have a lot of ways to say something, does not mean that you are using the correct way to say it.

Email is all of our favorite (ok, how about most used?) communication tool. We get emails, we read emails, we send emails. The problem is that it is all to easy to view email as our only communication channel. We've got others:

1. Email
2. Instant Messaging
   
3. Phone
4. Written Note
5. Physical Visit

Both emails and IM messages suffer from a key failure: they lack any way to communicate emotion. "Come to my office" is a message that, depending on the emotion with which it is delivered, can have many different meetings.

Let me wrap this discussion up with a true story that will help me make my point. One Friday afternoon (these things always happen on Fridays) I got a call from my product's development team leader. He told me that the feature that a VP had requested be added to the next release of the product would not be making it into the product because his team did not have any requirements. I thanked him for the head's up. Hung up the phone and briefly considered how short my career was going to be once the VP discovered that we had apparently ignored his request. I then called the requirements team and asked if they had requirements for this feature. Their team lead told me that they couldn't start working on those requirements until they got funding to do so. I then called the folks in finance and asked if funding was available. They said "sure, just tell us where it needs to go." A quick call back to requirements confirmed that they could have the requirements done by the end of the day once funding was confirmed. A final call to development secured me an assurance that the coding would be done by the end of the weekend if the requirements were available by the end of the day. Whew -- problem solved.

The take-away here is that the phone calls were the key. Everyone had already been sending emails about this issue, but that had not solved the problem. It's the small things that make an effective IT product manager.

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.