What about Product Managers?
I liked the discussion on Program Managers. Problem is, it doesn't quite tally with what I observe. Some background:
Several years ago, my employer bought into the whole MSF thing, and all of a sudden we had Program Managers, Product Managers and Development Managers. I can't recall if MSF had that many managers, perhaps the intelligensia at my company just decided to make things that way. Oh yes, I almost forgot, we also have Q/A managers.
Anyway, Product Managers would appear to be in Ultimate Control. The product doesn't ship until they say its ready.
Now, don't get me wrong, this is not necessarily a bad thing. Having someone who is separate from the development process judging whether or not my work is of shippable quality is enormously valuable.
However, much of the time, Program Management and Product Management differ significantly on what is important to ship, and when it can ship. The result is mixed signals from management. Worse yet, when Program Manager meets Product Manager in battle, invariably its the Product Manager who wins, and the feature in question must be added, or the bug must be fixed before release. But, of course, the schedule doesn't change, and the result is that now the poor developer (me) has less time to complete the task.
The root of the problem, in my opinion, is that the roles of Program Manager and Product Manager should not be separate. Before the shift to MSF, we had just a single manager, and that person decided on scope and schedule; that person also decided when something was shippable. When that role is divided, it seems to me that each sub-role will tend to focus on their individual responsibilities to the detriment of the other responsibilities.
I cannot believe that this is a good model for shipping quality product. Does this kind of situation arise in Microsoft? How on earth do they handle it?
Friday, February 27, 2004
The trouble here is MSF -- it is an attempt to export the trappings of Microsoft culture to other companies without actually exporting the culture itself. The giant problem, of course, is that Microsoft's system is designed for using very talented software people to develop mass market commercial shrinkwrapped software, and most of the companies that adopt is are using average software people to develop internal IT projects.
To this point speicifically, at Microsoft Product Managers handle marketing -- spec sheets, trade shows, pricing, advertising campaigns, positioning, etc. -- while the Program Managers handle development -- product design, schedule, spec, etc. These are two very different things and so MSF recommends two people. But if you don't have a marketing component because you're doing inhouse development, or if you already have a marketing department somewhere else and you misunderstood the MSF documents, you wind up with redundancy.
(Don't get me started about MSF, which is just an attempt by MCS, an organization I generally loathe, to create some kind of Big M Methodology, a concept I generally loathe, so they can compete against traditional consulting firms, whom I entirely loathe. It was also intended so that MCS's executives could have their own shrinkwrapped product so they could get ship-it awards, because the culture at Microsoft is so focused on shipping that the consulting business looked bad until they got their own "product.")
Fog Creek Software
Saturday, February 28, 2004
Fog Creek Home