Project Manager vs Product Manager vs Product Owner vs Scrum Master

Why are there so many comparisons among those roles?

I believe sometimes is because of a misunderstanding of the roles, roles' objectives, and roles' functions.

Let's start with two short definitions:

• Project: any undertaking, carried out individually or collaboratively and possibly involving research or design, that is carefully planned (usually by a project team) to achieve a particular aim. A "set of interrelated tasks to be executed over a fixed period and within certain cost and other limitations" (source).
• Product (in project management): a deliverable or set of deliverables that contribute to a business solution (source).

I don't want to try and put here a lot of tables with the functions and characteristics of each role, and later say if they are different or not. I believe it is more interesting to find how they can collaborate in a project and how the project might be done.

The four roles pie

The Project Manager will plan all the tasks and should ensure that everyone involved is well informed of what is happening with the plan's execution (everyone, means: the team, the stakeholders, the customer), while the Product Manager will oversee this work (is a stakeholder), will ensure that the project is being executed according to the business strategy and will be accountable for the coordination of the project work with the work of other teams like the marketing team for instance (when it apply) or a third-party provider that is configuring the Web site.

How the Project Manager and the team do the project, is determined by the methodology that was decided to be used. If the methodology happens to be Agile, the Project Manager (and the Product Manager) can get help from roles like the Product Owner and the Scrum Master. But the manager should keep in mind that any methodology he or she uses, have to consider the critical path, the risks, and the fact that everyone should be informed of the status (of any task: requirement analysis & development, the project itself, etc.).

Because the roles Product Manager and Product Owner are so tightly related to the "customer and business strategy", it looks like they should be on the customer side.

But you need someone to have an idea of the big picture, with the skills and accountability to deal with the team and the stakeholders (and to delegate those functions in others), with the skills to communicate the status and identify the risks (together with the people involved in the project), and it is not necessary to manage through the "do what I say" style. 

It is interesting to me what Jeff Sutherland (co-creator of the Scrum framework) tell us here - the bold is mine -:

"When I created the Product Owner role, I gave it more responsibility for product strategy and revenue generation than a Product Manager ... more responsibility for directly working with engineering 50% of the time ... The goal was to eliminate the common Product Manager failing of throwing requirements over the wall ... It was also to replicate the Chief Engineer role at Toyota which requires much more responsibility than a Product Manager. So much, that I split the role by giving the Scrum Master responsibility for the team ... The basis for these comments is the Pragmatic Marketing framework ..."

It was 1993, and probably in Easel Corporation, the role of Product Manager was only to provide the requirements but not to manage the engineering team. He mentioned one known framework used at that time, very useful to do projects, but probably more related to product marketing (at that time). Anyway, it is obvious to me that there was a lack of communication between them. And as he said "... only to have the customer receive something that they didn’t want ...". Doesn't this sound like a Waterfall common point? 

Before we jump to conclusions like "... you see!, that's why Agile and Scrum are the right approaches  ...", we have to stop and think about the communication problem that we can infer from that quote. Don't you agree? That it looks like there was no agreement between the people that "do" and the one(s) that "request". To me, the confirmation came later with the Agile manifesto (co-written by Sutherland too in 2001), they talk about individuals and customer interaction and collaboration as something that you should value more.

The C₃ Project Areas

In several projects, I see that it doesn't matter if the team do the project following a methodology or only using a framework like Scrum (without methodology), the outcome many times is that the objective wasn't achieved or worst, that there was a lot of effort ($$$) done without "good" results.

I believe any project execution should consider three main areas of work. And if you, as a Project Manager, are clear in what to do in each area, the perception and the outcome can be different.

All the areas have the same importance and should be driven carefully during the project life cycle. All of them are interrelated and each one has an impact on the others.

Communication Plan

Every good communication plan should consider two things: the recurrence of "communication" and the type of it. Communication is something like a meeting, an email, and a report document.

You should agree with everyone on the communication plan. But especially you should agree and be sure of the commitment of everyone.

Communication is a plan because these are activities that should be part of the project plan. 

Here are some "communications" that should be part of a plan, use all or some as part of your methodology.

• Kick-off meeting: the "first" meeting of the project, where everyone should be present. At least you should answer and/or agree on:
• What your plan is to achieve the goal?
• How you will do the project?
• When is expected the help of each one (especially the end-users)?
• Who is who in the project?
• What are the key dates (like the UAT phase)?
• What is your communication plan? (meetings, who will receive what email, etc.).
• What is the frequency of the main meetings with the project stakeholders?
• Project Status meeting: you should often meet (once per week?) to check the progress and status of the project. The Project Manager and the Product Manager should be present (I will call Product Manager to the customer representative who is accountable for the project). Sometimes is useful to have some stakeholders in the meeting. You should check and review: 
• The general status (the scope, costs, plan execution, etc.).
• The risks and the mitigation plan of each one.
• Tasks that depend on third-parties.
• And you should make decisions when something not planned arises (like a scope change, or a blocking task that does not depends on you). 
• Project Status report: create a report that can support the status meeting.
• Steering Committee meeting: invite (this meeting should not happen with the same frequency that the Project Status meeting, but the document that supports it, is basically the same) the stakeholders and the Product Manager to show the project status and get advice or make decisions on changes that you should do in your project.  
• End-User Test meeting: invite the users to understand what they will do during the test phase, what is expected from them, and explain what they will test. This can be once in the project (UAT phase) or in every iteration.
• Product Handover meeting: before the Go-Live, invite the maintenance team to explain in detail what the product is. Be sure that you have the documentation that supports your product.
• Project Closure meeting: before the Go-Live or immediately after, do an overview meeting of what was done and how you did what was promised. Lessons learned should be part of this.
• Team meeting: you should frequently meet the engineering or development team to understand "where they are", how you can help them, and to communicate what are the risks, decisions, and changes that the project and project plan are facing.
• Phase end meeting (or email): probably an email should be enough to communicate to everyone that a phase ended. If you are in a Waterfall model, an email makes sense; in an Agile model, when the phases are iterative and short, this is more like the Scrum Sprint Retrospective & Closure meeting.
• Meeting minutes: in my opinion, an email is a valid container to communicate what was discussed and decided in a meeting (in opposite to an attached document). If you can create a fancy and specific template for your projects' email official communications, the better. 

Those are the list from the top of my mind I can remember are good elements in the communication plan. There are probably more, and for sure there are documents that explain - better than me :-) - completely how to do each one or report on each one (like the Project Status report). Just remember that people are more engaged if they are well informed.

Critical Path

If you studied PERT and CPM techniques, you already know what is this. I believe it is an important area in any project methodology because you always have to consider how any scope change, delay, decision, or risk in your project impacts the critical path. If there is such a situation, your plan should change and it has to be communicated.

Also, knowing your critical path will help you to identify better the risks.

Cause and Effect

I believe a Project execution environment is a good example of causality, that is why I used it to name this area. By cause and effect, I want to refer to situations like for example:

• When you have the initial set of requirements (cause), you should do a plan with them (effect). If a new requirement arises later (cause), you re-plan your project, and probably rise a risk or a new scope change SOW (effect).
• When you have a delay or a blocking situation (cause), you should communicate the risk and impact on the project (effect).
• In the beginning, you have an end date commitment (cause), then you should plan your project in such a way that it "has to start not later than" because of the critical path (effect). If the customer cannot agree with you on that start date and wants to start later but end at the committed date (cause), you should start your project with already a risk that can be communicated in the kick-off (effect).

I hope you got the idea :-). My point is, as Project Manager, you should be prepared to identify and communicate the effect and impact that has any situation or decision taken in your project.

Wrap-up

I believe a good Product Manager can leverage the help of a Project Manager and a Product Owner, and a good Project Manager can leverage the help of a Scrum Master alike role.

But we should face the fact that most of the time, there isn't enough budget to have one person per role, and then someone has to have the skills to do two or more roles. In any case, there are key activities that should be executed, hence, ensure that those activities are part of your project and one person only is accountable and responsible for them.

Those key activities are specially related to people interactions and collaboration, and to the way you plan your work to finish on time and on budget.  

We should remember that, if anything goes wrong with the project, somebody, somewhere, will find that the "cause" was because the Project Manager and team didn't do this or that :-). 

"It is better to have a bad method than to have none". Charles de Gaulle