Product Management vs. Project Management
Earlier I’ve written about how important it is to clearly distinguish the roles of product management and product marketing (see Product Management vs. Product Marketing). But many companies suffer from a related problem, which is when the roles of product management and project management are combined.
I’ve also written earlier about how the nature of product management and project management are different and typically attract different types of people to each (see Strategy vs. Execution).
But I haven’t written yet about why this situation exists, and I think this sheds light on several related problems.
The reason so many Internet companies still define product management as including project management is because many of our practices came from the shipped software world. In the shipped software world, like what Microsoft became famous for, it is common to have product managers cover the project management role (in fact, Microsoft still does this under the job title “Program Manager”). But this is one of those areas that doesn’t migrate well to web services.
To explain, first a little bit of Internet history. When Internet services came about, around 1996 or so, at first we struggled with whether to continue to call ourselves “Product Managers” because things like a Travel site are more of a service than a traditional product, but we quickly got over that (although sometimes we called the role “producers” to emphasize the media and content nature of the services, but that wave too passed fairly quickly).
However we initially tried to continue having the product manager cover the project manager role. Early internet companies like Netscape and Yahoo did this. But we all ran into a problem with this. In the shipped software world, the product was generally shipped as a self-contained unit. So the “product” generally was in the same granularity and frequency as the “project” so it’s not so hard for the product manager to double as the project manager. But in the web services world, with many releases underway in parallel, this model breaks down.
Not to complicate matters too much, but most internet service companies found that they needed to make frequent smaller releases to a larger common code base. And since the duration of a typical project is longer than the release interval (usually ranging from weekly to monthly), this quickly turns into parallel development and the software train model of releases. Most internet companies that are beyond the startup phase use this train model.
The train model is really a topic in itself, but suffice it to say here that a train requires active and strong project management, which is not tied to specific projects. A train typically contains features from many product managers. A train has significant release management, engineering, site operations, customer service and product management coordination requirements.
Some internet companies refer to the project manager of a release train as the train’s “conductor.”
If you use the train model, and you have project managers dedicated to the release trains, you generally don’t need product managers to cover project management too.
So as the release process at companies like Yahoo, Netscape/AOL, and others became more sophisticated, the project management responsibilities were untangled from the product management role, and all of these companies developed very strong dedicated project management competencies. Many newer Internet companies like eBay and Google could not release the quantity and quality of software they do without their very strong project management team spanning product management, engineering and site operations (see eBay’s Secret Weapon )
For Internet services companies, it really is important that the roles be separate. You’ll thrash in release management if you don’t, and releases will consistently be delayed and take longer than they should.
If you are still doing shipped software, I still think it’s useful to separate the roles, but this is more due to the nature of discovery-oriented product management versus execution-oriented project management.
