It’s a rather sad fact of life that many companies, hiring managers, and even supervisory managers commonly conflate the jobs of Product Management and Project Management.  I literally cannot count the number of times I’ve corrected people at a variety of companies, telling them that I’m a “Product Manager” and not a “Project Manager.”  In fact, it’s almost become somewhat of a joke to me.

But, in reality, it’s deadly serious.  And it impacts our daily jobs by altering the expectations of us as Product Managers.

First, let’s separate out the two — traditionally, Project Managers are tasked with managing three things:

• Time — Is the project they are managing meeting expectations with respect to the time allotted for delivery?
• Scope — Is the project they are managing able to be delivered with the promised or expected features and capabilities?
• Resources — Is the project they are managing sufficiently staffed with the appropriate resources to achieve the goals laid out?

There’s a lot more that Project Managers do (and that I have the utmost respect for), such as change management, risk assessment and mitigation planning, and so very many other very specific tasks and deliverables that they are experts at.  But, when you boil it down to the essentials, Project Managers typically deal with development teams and stakeholders in terms of Time, Scope, and Resources.

Now, for Product Managers, we are tasked with managing:

• Strategy — Given the market and the customers, are we executing the right strategic plans to extend our market reach and increase our adoption?
• Roadmap — What are the key thematic goals that we are going to be focusing on over the next 6/9/12 months?
• Requirements — Specifically, what are the things that we need to do, how are they defined, and who are they targeting?

As you can see, the expectations of a “true” Product Manager revolve around the “what” should be done, and the expectations of a “true” Project Manager revolve around the current state of execution — whether or not the “how” balances with the “what” into a plan that’s workable and achievable.

Project Managers, by necessity, are worried about the trees and not the forest.  They’re worried about sprint plans, Gantt charts, red/yellow/green reporting, and most importantly, leveraging every available resource to achieve the goal that they have taken responsibility for.  Project Managers are in the thick of things, watching for milestones, noting the challenges and changes that could affect the outcome, and raising up the red flags when something poses a legitimate risk to the plan.

Product Managers, on the other hand, are focused on the forest more than the trees.  They’re worried about whether or not the product is going in the right direction, whether or not the product is solving valuable and useful problems for its intended customers.  They’re focused on making sure that the development teams have the necessary level of detail to execute on those strategic goals, and confirming a story is complete when the development team says that it’s done.

These two roles are largely exclusive of one another, but absolutely complementary.  And perhaps therein lies the majority of the confusion about where the line should exist between these two roles.  Simply put, the Product Manager doesn’t always have something important to report on — if the trains are running on time, and the strategy is being worked effectively, the Product Manager is in blue sky mode, coming up with future ideas and plans that may take months before they’re really ready to discuss.  On the other hand, the Project Manager almost always has something interesting and important to report — even if that’s an “all green” status report, it’s always there, always available, and can be presented in minutes if the tools are all there to deliver it properly.

And that can confuse people — I’ve been accused at times that I’m not “doing anything” when I’ve been in that “blue sky” mode, because I didn’t have anything immediate to show for it.  I had sketches, light wireframes, vague problem statements, but nothing that was concrete enough for there to be a “there” yet.  But my project manager always had something – always had some update or tidbit of information to share with the teams.  It’s a tough thing to balance and to explain to people, who are looking for concrete and not concept.

Which is, I think, why companies often try to combine these two roles into a single one — so that they can have something that’s concrete and clear, but also have someone engaged in the “blue sky” thinking that pushes the product forward.  Unfortunately, this doesn’t happen in reality – what they don’t understand is that the very time spent monitoring and documenting and reporting is the same time that would be spend conceptually.  You can’t get both at the same time, under the same umbrella, for free.  There are costs — hard costs in personnel and tools, soft costs in time, effort, and switching between contexts.  And all of this hurts a Product Manager who is expected to alternate as a Project Manager, or vice-versa.

Product Management is a growing, solidifying discipline in and of itself.  Project Management has a long and well-established, clear history.  But that doesn’t mean that we should conflate the two when it’s possible not to – when you need a Project Manager, you should have an expert, experienced resource doing that work; similarly, when you need a Product Manager, the same holds true.  We don’t expect Sales personnel to do Marketing; we don’t expect Support personnel to do Development; so why do we constantly assume that Product and Project Management can be done by one single person?