Long ago, before there were any program managers (PMs), there were just developers, testers, and marketing people. The developers would build software they thought was interesting, and the marketing people would dive-bomb them every little while with the latest hot issue from a customer or magazine reviewer that had to get added or fixed. The developers found this frustrating, because it seemed like they were getting randomized a lot. The marketers found this annoying since the devs seemed pretty unresponsive and did not seem understand the customer or business issues.
The first PM at Microsoft was an Excel developer who decided to “take one for the team” and act as a buffer between the marketers and developers. He defined his role as a person who would go and figure out what these marketing people were really talking about and understand the customer needs or business problems so he could interpret those into actions the dev team had to take using his technical knowledge of what was possible and what was hard. I believe this was 1987, but I could be off by a year.
Program management proved to be such a useful role that it spread to other teams like Word and PowerPoint. This “jack of all trades” or “renaissance man” (to use the hoighty toighty term) acted as a hub of communication, and made the marketers job easier, since they had someone to talk to who could take the time to really understand the outside world, and the devs could talk to someone who spoke their language and was not ridiculous (not often at least).
Today there are many flavors of PMs. In some parts of the company, they define the APIs and write the technical documentation. In other parts, they are in charge of getting web sites updated every day, week or whatever interval. In Office, there are “design” PMs who mainly work on designing the products, “process” PMs who mainly work on driving processes that make sure we get things done, localization PMs who are sort of like process PMs but also sort of like developers in that they sometimes produce code and make bits that ship in the product, although usually by running tools that generate localized (translated) code, not by writing code.
I’m not sure where this saying came from originally, but one way to describe PMs is that they not only “pick up and run with the ball, they go find the ball”. That really defines the difference between “knowing what to do and doing it”, and “not knowing what to do, but using your own wits to decide what to do, then doing it”. That means as a PM you are constantly strategizing and rethinking what is going on to find out if there is something you are missing, or the team is missing. You’re also constantly deciding what is important to do, and whether action needs to be taken. The number of such decisions is staggering. I might make 50 a day, sometimes more than 100 or even 200. Most of the time there is not nearly enough hard data to say for certain what to do, and in any case almost all these decisions could never have hard data anyway – you need to apply concentration and clear thinking.
Some years ago I realized that as a PM, my definition of vacation was not just going somewhere to have fun (work is quite fun most of the time). Vacation means getting to an environment where no decisions have to be made. I used to drive my friends nuts, since I would go visit them, and they’d say “what do you want to do?”, or “where do you want to go?”, and I would simply say “you decide”.