While there are article after article posted about the difference between the product manager role and the product marketing manager role, there is one more relevant comparison that ought to be made, how does a product manager differ from a project manager.
Why should we care about this? When I was was posting job req’s, I would have to sit with the HR person, and sort through the list of Radford Codes to find the description of duties, responsibilities, levels, and pay ranges for the role.
While I don’t know what subscription my org had, or the more formal details of the Radford rating system (apparently, they do a lot more than just job classifications, and salary benchmark surveys), I did struggle. The definitions that Radford had for ‘Product’ people, at least in what I had access too, well, sucked. There were some “close” role descriptions, but not quite. Then there were position titles that sounded similar, but weren’t. Hence the topic of this essay.
First, when I crafted the requirements, and description, with responsibilities, a HR person will want to match that up with the job category of “Project Manager”. Heck, if you squint at the Radford description, you can almost see it matching.
But, then you look at the pay scales, and you, the senior, seasoned Product executive have to bust out laughing. The very TOP of the scale, for the level IV position, is less than you started at TWENTY YEARS ago. Seriously, it is laughable. Invariably I had to chart my own path, and get some salary waiver or other concession to even begin to find qualified candidates.
Why Bring this up?
In many of my roles, I have had project management-like tasks. This has provided me a far better appreciation of the life of a strong project or program manager, and can draw some conclusions. Below, are some direct observations I have made over the years.
Attention to detail
The Product Manager pays attention to the details, often at a very minute level. However, she is insanely good at prioritizing, and determining what is important and what can be ignored, literally sizing up the impact and importance in a few seconds, and making an instant go/no-go decision.
The Project Manager typically doesn’t have that luxury. If the detail in question is important to the project, it gets handled, and the project manager figures out how get it scheduled, who to assign the task to, and tracks it on the master WBS. Essentially all the myriad details are to be done, no exception.
Scope of project or program
The Project Manager owns the entire scope of the project, and this is defined up front. In fact, the project has a well-defined charter, a definite conclusion, and a strongly defined “done” state. The project manager keeps that goal in focus, generates tracking metrics, and periodic reports on progress, and the risks the project is facing. When the project is complete, a final report, a post mortem review, and it is over. The team is disbanded, and the project manager moves on to the next assignment.
The Product Manager on the other hand, also owns the scope of the product development process. But that is not all. They are responsible for the market research, the gathering of requirements, the prioritization of features, and the overall success of the product. Combined with their paired Product Marketing Manager, they need to address the product-market fit, and to adjust the program accordingly. Most importantly, is that when the product is launched, their responsibilities are far from done. Arguably, at that point the real work begins, as the product is deployed, feedback, trouble tickets, bug fixes, and the next version definition begin. The product manager remains inextricably linked to the success of the product.
One of the most frustrating aspects of the product manager position, especially in larger organizations, is that rarely is there a dedicated team associated with the product. While development might be committed to a product, the rest of the resources it takes are often loosely attached to the product. That means that you might have to share a UX designer, or graphic artists, or marketing team members creating collateral, or operations team who are working on deployments, you get the picture. This means that an effective product manager must be good at herding cats, using their market authority to influence team members to commit to, and deliver their actions.
The Project Manager on the other hand, often has commitment from the senior leadership of the team members who are to work on the project, with firm expectations of contributions, and ultimately, the ability to remove and replace ineffective, or under-performing team members. As the goals are known, and progress can be minutely tracked, this leads to authority that even great Product Managers lack.
The Project, by definition is constrained. Time, budget, quality are the typically cited constraints of an effective project. You may have heard the adage:
Cheaper, Faster, Better, pick Two
While this seems simplistic, it is also quite true, if you want better, and faster, the cost will be high. Or if you want to complete it faster, and be cheaper, you will sacrifice quality. Project managers may treat this less simplistically, in the end their schedule and budgets fit within this box.
Alas, product managers do not have such a straight forward set of constraints. You are expected to meet a standard of quality (that is a balance of value, and performance that drives adoption in the market), have virtually no control of the budget, and often must live within the resources provided by the organization. Woe be to the Product Manager who complains about resources. As you can’t hire or fire people on the team, you often have to live with what you got.
Probably the biggest difference is how the inevitable distractions are handled. I am in awe about how effective a strong project manager can deflect, or shut down extraneous distractions that could derail or even slightly delay a project. They just say “NO”, and if someone tries to alter the project scope, they instantly bring up the charter, the schedule, or the budget, and suddenly the distraction disappears. Amazing. And if the distraction isn’t project related? Just ignore it.
Yet, in his two decades of product management, he hasn’t been ever able to just deflect with impunity. Even completely orthogonal distractions must be triaged, responded to, and depending on the juice of the person involved, just grudgingly picked up.
Seriously, as the hub of activity around the product and development team, it his her job to seriously handle any and all inputs. Add to that escalations of support, or other customer disasters, urgent sales calls, technical conferences, and on and on, the Product Manager is pulled in many directions.
The main downside is that the “to-do” list keeps growing, and priorities shift, leading to gasp some things not getting done. In Project Manager land, that is untenable. So they are justified in just shutting down the distractions.
Here I get to bash on Radford once again. It’s not really their fault, per se, but, the huge latitude in the definition of what Product Management is means that it defies definitive categorization (nb: do a Google search on “definition of product management” and go down the rathole of blog after blog, article after article, framework after framework trying to bring some order to the chaos of the rubric of Product Management).
This has lead to many HR managers using Kentucky Windage while squinting to lump Product Managers into the pay ranges of Project Managers. Hence, arguments that a mid-career to senior Product Manager should have a salary midpoint of $80K, even in fairly high cost of living areas.
Watching closely a really good project manager in action, I must admit that the standard tables of salaries for Project Managers is an insult to them. Good Project Managers are worth quite a bit more, especially as they gain a track record of successes under their belt.
For product managers, I have been successful at getting salary waivers. But this can be hazardous, as often that will mean that there is no defined path to raises or promotions, each step being a battle with HR – often leading good product managers to leave to get a commensurate salary bump.
The Definition of Done
One key difference between the two disciplines shines the most light on the delta, and that is the definition of what “Done” means.
In the Project realm, done is when the project is complete, the deliverables are handed off, and it goes into production (or whatever the final state is). At that point, apart from a post mortem, and a coda document that is a final artifact of the program, the project manager is relieved from responsibilities, and can move on to the next project.
Alas, for a Product Manager, release or launch, is in many ways only the beginning. You start planning the next release, tracking the market success, assist the sales channel in becoming effective at selling the product, work with support to keep an eye on defects, and start building a backlog for future development.
In short, a Product lives on, as an evolving entity. A Project, on the other hand, is done to spec. If there needs additional work, that instigates another project, with a plan, resources, budget, BOM, and a dedicated project manager (not necessarily the same one as originally engaged).
While much ink is spilled on the comparison and contrast of Product Management versus Product Marketing, I have found that nearly as much confusion between product and project management exists as well.
Both are critical roles, yet they have very different motivations, end results, and relationships within the organization. There is no superior, nor inferior role, just different. A good project manager does not a good product manager make, and vice versa.