Tracking Your Product Development: What Works, What Doesn't

The job of product management often takes on a program management flavor when it comes to keeping track of how the development of a new product is coming along. It's probably important that I come right out and say that product management is a completely different job than program management; however, the two worlds do intersect when it comes to tracking product development. How an IT product development project is tracked is one of the ways that you can distinguish between a good product manager and a bad one.

So what's a product manager to do? More often than not, I've found myself having to create a means to track the status of a project that is creating my product. Often this project will include external firms, internal development, marketing, sales training, etc. As anyone with an IT background can tell you, there are countless ways to track a project like this; however, too many of them are cumbersome, awkward to use for IT products, and don't really do a good job of answering the questions that you (and your management) will be asking.

Physical File Folder w/ Sticky Notes: In all honesty, I have several IT product management friends who successfully use this system. They are all females and I'm not sure if this has something to do with why it seems to work for them. What I do know is that when I've tried to use it, it's been a complete disaster. This systems only requires you to put all pertinent information into a single file folder and then carry it around with you at all times. Critical information such as dates and contact info can be written on Post-IT notes and stuck on the inside of the file folder. Forget PDAs and laptops, if you know where your info is, you can answer just about any question quicker than your competition. The downside of this system (for me) is that it's not visual -- you can't tell where things are by looking at a summary of the information. Additionally, you need to occasionally spend time and resort/organize your folder in order to make sure that you have up-to-date copies of everything. I always run out of time to do this and then the whole thing just falls down.

Microsoft Project: everyone in IT likes this tool (at least deep down). We like it because it's complicated enough that we feel like if we feed it enough information it will tell us what to do. I have seen some very detailed Project plans; however, I've never really seen an IT project successfully use this tool. Much of the tool's functionality does not pertain to an IT project. One of the big problems is that very few people seem to have copies of Project and so you end up sending out PDF versions of the plan. Then you get busy, the plan doesn't get updated, and things fall apart.

Microsoft Excel: This is my weapon of choice. Everyone seems to have a copy of this application so you can share files and folks can make changes to it if needed. There really is no learning required in order to be able to use it. As a committed visual learner, I use Excel to make lots of colored progress charts. More often than not, I color in cell by cell to show the status of a given set of tasks. When the colored rows are stacked on top of each other, then you can quickly see the overall project status. Oh, and this can easily be copied into PowerPoint presentations to be used at the next mandatory product status meeting.

So there you have it, three different ways to track the status of an IT development project. There is no one perfect answer and what works for one may be different from what works for others. In the end, it's just important that you have a system that allows you to quickly answer the questions that you know are going to be coming your way.


Tags: Excel, Microsoft Project, project, status chart, tracking

What Medical Doctors Can Teach IT Product Managers

Once an IT product has been funded and staffed, there is very little that will cause it to be halted or the original decisions that caused the product to be funded to be revisited. This is probably a good explanation as to why so many IT products are so poorly received by their intended audience when they finally make it to market. It also explains why IT product managers have such a hard time getting respect from within their own companies. Maybe it's time to look outside of IT for a better way to do this.

It might seem like a bit of a stretch at first, but the medical profession has been dealing with "bad product development" issues for years. In the world of medicine, the consequences of errors, bad judgments, and flat out mistakes can be very severe - death. One of the leading causes for these medical mistakes are caused by doctor misdiagnosis. In these cases, a doctor relies on his set of experiences and his limited knowledge to make patient decisions. The fancy name for this type of flawed decision making is Comparative Ignorance. What's really interesting here is that we in IT do exactly the same thing - we decide what products to move forward with based more often that not on what we've seen work in the past. In a field like IT where everything changes so rapidly, it's decisions like this that have a tenancy to result in poor product feature selection or just flat out bad products.

So how have doctors gone about solving this problem? Hospitals convene regular review meetings which are attended by everyone: faculty, nurses, medical students, etc. At these meetings they revisit patient cases that had poor outcomes and they discuss what happened, why it happened, and what can have been done to ensure that it does not happen again. The result of these meetings is that everyone comes to understand that nobody is perfect - we all make mistakes and can learn from others' errors. In IT, reviews of the formal decision making process are rare. Even our brothers and sisters in Sales have what they call After Action Reviews (AARs) in which they review lost sales opportunities in the hopes of identifying what changes need to be made in order to avoid another sales loss.

Often times a product manager will have a "wrap-up meeting" as a part of the formal product development process. However, since IT products rarely ever reach an "end", these meetings never happen. Perhaps if we put our foot down more firmly and held detailed product review meetings at fixed milestones in the launch process, then we'd be able to learn from ourselves and things would be easier the next time around!


Tags: Comparative Ignorance, poor decision making, product review

Face-To-Face Meetings: Online vs. Offline?

How many of you have seen this: you've called a technical face to face meeting to resolve some key product issues. You've carefully coordinated the meeting time with everyone's schedules and you've been sure to make sure that you've included folks from all impacted departments. Imagine your joy when you see that just about everyone has actually shown up for your meeting. Imagine your disappointment when everyone whips out their laptops, powers up. gets a wired/wireless connection, and *poof* they mentally vanish.

So why are we having this meeting? I can't tell you how many times I've been in one of these meetings when someone gets asked a question, looks up from their laptop and says "I'm sorry, I was working on my email. Can you repeat the question?" I generally don't really like meetings all that much and it's events like this that cause them to take way too long. If you introduce IM into the equation, then you have folks in your meeting merrily typing away in one or more active conversations even while your meeting is going on. Arrgh! Why did they even bother to come?

So what's a product manger to do? Stomping your feet, rolling around on the floor, and shaking your finger at offenders are all possibilities; however, I'm not thinking that they will really accomplish the goal. What is the goal? To have a face-to-face meeting with all parties attending participating and engaged in the conversation and problem solving. This is a huge problem and we have yet to really work out the social issues that it brings up. For example, if your boss attends and opens his/her laptop, then what are you going to say to him/her?

I don't have any magic solutions, but one powerful force that you can bring to bear is peer pressure. If before the meeting occurs you loudly and clearly tell everyone that the use of laptops and Blackberrys will be banned during the meeting, then nobody can really object. If you hold the line and actually kick out active Blackberry users that will also send a clear message. Careful though -- if they don't leave, then you will have lost face with the rest of the attendees. Finally, make you meetings exciting and engaging. People do other tasks because they are bored. If you remove the boredom, they may even forget about their laptops/Blackberrys/iPhones for at least awhile.

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.