Before I actually moved into this position I always wondered what exactly is that PMs do? Not surprisingly, even now I meet a lot of people who wonder what is it that PMs do. Of course, these guys are mostly either developers or testers. Now that I have been in the role for about an year, I certainly understand the PM role much much better. But this does not mean that I understand what every PM at Microsoft does. In fact, part of the reason for the mystery might have to do with the fact that the PM title did not have a specific role assigned to it (until now). In other words, if you hear of someone who is a PM it still is hard to say what exactly he/she might be doing.
Genesis of the PM position:
The oldest document I have found at Microsoft which talks about the Program Management role is an excellent paper titled “The Art, Science, and Profession of Program Management at Microsoft” by Steve Madigan. Now that we have entered the age of blogging, I feel I can quote a few words from that paper:
Jabe Blumenthal originated the role of program management at Microsoft. While I don’t know the whole story, and I wasn’t even at the company at the time, I believe he took his case to Bill Gates, describing what he believed to be a missing part of the process of software products design. We were missing a separate role of product definition and design that should sit “between marketing and development,” but should a “marketing” function, inwardly focused on building the product. Over time, Jabe’s original concepts have held true, although as we’ve done more and different products, the role has evolved into it’s own fully recognized discipline and reporting structure.
The Missing Piece:
If you look at the above description of the PM role, it exactly fits the role of what I call a Feature PM (more about this later on). This is the traditional PM role. Overtime, the job description for the PM role evolved more along the lines of “get the job done” and all kinds of roles were branded as PMs (this is my guess since I wasnt there at the company back then). One did not have sit between the development and marketing teams to be called a PM.
Developers, Testers, and PMs:
It is not uncommon for developers and testers to feel that PMs arent contributing enough to the product. That is a broad sweeping statement but bear with me for a while. And these sentiments are more prominent among new employees although it isnt limited to that group of employees. And if you dont believe what I am saying, just take a look at comments section on MiniMicrosoft. The perception is that PMs just walk around carrying their fancy laptops from one meeting to the next. Now I know that isnt true at all…although it is true that most PMs have laptops and attend many more meetings than devs and test!
Most people just dont realize what all it takes to build and sell a useful product. Engineers (developers and testers), almost always, think that just having the right set of features with great quality and performance is enough. When you become a PM you get the first taste of what all (or what else) is involved; products succeed or fail for almost unbelievable reasons ranging anywhere from poor documentation, legal issues, poor marketing and a billion other reasons. When one begins to understand these other factors that make or break a product, then one begins to understand the PM role. But understanding these doesnt come naturally to engineers. See engineers think rationally and logically. There are many engineers who think that just by having a cool new feature in their product, a lot of people will find it, use it, and enjoy it. Just like they would have done it themselves. They rarely think about discoverability, documentation, ease of use/simplicity etc. And I am NOT picking on engineers here! I can make that statement about the whole of Microsoft and most of the software industry. Traditionally Microsoft has built products that are very feature rich but arent necessarily discoverable or easy to use. Just take a look at Tools/Options in Outlook or Word.
As a corollary, if you are changing jobs and want to find out if the team you are interviewing with is a good team to be in, just look at the interaction between dev, test, and PM. Good teams have great respect for each discipline.
I will continue with the Part 2 of this topic in my next post. I hope you found something interesting in this post. If you did please leave a comment - I would love to hear from you!
Digg This!
.”