Prodject part five - How are products managed?

As I previously noted, the product manager (or whatever you call him or her) is responsible for managing the product portfolio. And there are various ways in which this could be done.

http://www.flickr.com/photos/oreilly/ / CC BY 2.0

The most common way to do this is with the hallway conversation. Here's an example:

BILLY: Hey, Jim!

JIM: What's up, Billy?

BILLY: Wouldn't it be cool if the user could incorporate blinking icons into our spreadsheet product?

JIM: Well, some would like it, I guess. How long would it take to do it?

BILLY: Already done. Jane and I coded it last week.

JIM: Anyone tested it?

BILLY: Jane and I did.

JIM: Will the customers like it?

BILLY: Of course! What's not to like?

JIM: Cool!

Now some people would argue that the organization that employs Jim, Billy, and Jane is completely without process. Those people are incorrect; this organization has a process. The process is undocumented, and many of us would sniff our nose at it, but it is a process.

Donald McNaughton shared a process in his presentation - or, more accurately, a process outline. He didn't go into detail about what should take place at each step in the process. But anyone who's seen any industry process will recognize the aspects of McNaughton's process outline, which has thirteen steps. Here are the steps as I tweeted them:

1. idea screening


2. product manager


3. project proposal


4. product coordinator


5. (cross functional) portfolio mgmt committee


6. project team


7. project plans


8. stage & gate


9. project team leader (review @ each gate)


10. portfolio mgmt committee (review @ each gate, maybe kill)


11. monthly project status update


12. product coordinator


13. #prodmgmt review

Some of you are familiar with what's going on here, while some of you may not be. Suffice it to say that this process, in parallel with other processes with which I am familiar (specifically Motorola's "M-gates" process, an adaption of stage gates), includes the following basic approaches:

http://www.flickr.com/photos/harpreetsingh/ / CC BY-ND 2.0

• Decide what you're going to do before you do it. Whether you use detailed financial analyses or stick your finger in the air, you need some way to convert an idea into an approved project.


• Track progress. Divide your project up into stages (perhaps major stages, perhaps major and minor stages). Motorola numbers its M-gates in reverse order, from M-15 through M-0. Much of my work at Motorola centered around M-11. I knew what subtasks were required to reach M-11, and who had to do them.


• Review. McNaughton mentioned two types of reviews - a stage review, and a scheduled review. In the first review, you look at all of the stuff that needed to be completed for the stage, and then decide whether you can to proceed, delay before proceeding, or kill the project altogether. In the second review, a group of people gather on a weekly or monthly basis to see how the project is going. You can't just rely on the stage review - what if you never complete all the work for a stage? The scheduled review will catch that.

Now there are various ways in which you can implement this. Motorola, as I have mentioned, had their own way of doing this. When our division was part of Motorola, we tailored Motorola's methods to our own business needs. (Automated fingerprint identification systems are managed differently than radios and cellular telephones.) FriendFeed has their own way to introduce products, as does Beatrice.

http://www.flickr.com/photos/brostad/ / CC BY 2.0

Now some organizations may have very complex processes. I'd be willing to bet that a company that's providing a Space Shuttle component uses a different process than the one that the FriendFeed folks used. The important thing is to use the process that is right for you.

What about Agile?