What’s the Difference Between a PM, a ProdM, an SM and a PO?

There are a lot of project management buzzwords in that question! They’re all job titles in projects, but some are used in the waterfall methodology and some are used in the agile scrum methodology. You’ll find many job descriptions reference one of these four titles (or acronyms) and it’s best to know what they are, and when they’re a good fit for the work to be done.

In traditional start-to-finish project management (or waterfall methodology), you will find a project manager (PM) and a product manager (ProdM). The ProdM is responsible for determining the roadmap for a product, and how it will evolve, from a customer point of view. The project manager is the manager that guides the team to achieve that vision. In agile scrum development, a style of work most found in software development, the scrum master (SM) and the product owner (PO) are two roles (along with developers) in a scrum team. The scrum team develops a product, with the PO looking to maximize value to the product (and to the customer) and the SM looking to help the team achieve it.

Let’s look at each title in turn.

Waterfall Methodology

First, we have the roles for the waterfall methodology. For those just starting in project management, waterfall is the process of learning all you can about a project, planning it, executing to that plan, testing the created product against that plan, and then closing the project. Another way to describe waterfall methodology is to think of it as a start-to-finish approach. You will progress to the end of the plan, and have a working product at the end.

Both project managers and product managers work in the waterfall world. You won’t find scrum masters and product owners here.

The Project Manager (or PM)

This is the individual tasked with organizing the work required to complete the project. In the different phases of the project (initiating, planning, executing, testing and closing), it is the project manager that works to get the right people to work on the tasks at hand, and to coordinate the work so that the right work is done in time for the next piece. The job title is spot on – a project manager manages the project. It’s as simple as that! The project manager is held accountable to ensure that work is being done to complete the project. Essentially, it’s a communications job at its core.

Traditionally, the members of the project team work with the project manager, and not for the project manager. The project manager manages the work, and not the people. The PM doesn’t need to write the year-end reviews for the project team members, or have a boss-employee relationship. Instead, the PM has to report to management on how the project is going, and if any help is needed. Timely communication is the key to good project management, so a good communicator is the first thing to look for in a PM.

The Product Manager (or ProdM)

Unlike the project manager, who is looking at the work from a process point of view, the product manager is the person who looks at a project from the product’s point of view. The product manager represents the user community, and must know enough about the use of the product that’s going to be worked on to voice what’s working, what’s not, and what’s needed to improve the product.

The product manager is responsible for project scope (or what’s to be done), and the project’s business analyst usually works with the project manager to define the product’s requirements and how to test once the product is built. The product manager is the person who says what is to be done, and what the product needs to look, act, smell, taste and work like at the end of the project.

Product managers tend to also be good communicators, but their audience is mostly focused on the end user community. Product owners need to understand the needs and translate that into a roadmap of improvements necessary to get the product to where it needs to be.

Agile (Scrum) Methodology

Second, we have the roles for the agile scrum methodology. In fact, there are several methodologies under the agile bucket, and scrum is just one, but it’s a very popular one, especially in the software development world. What marks it as different, for those just learning about this stuff, is that the agile methodology involves iterative development, or cycles of development. After each sprint (a defined period of time, like every two weeks for example), the project is stopped, tested and presented to the customers (or a representative set of customers). Adjustments can be made to what’s needed next, and we’re off into another sprint.

It’s this iterative approach that makes agile scrum so powerful. The customer representatives have a shot at the end of each sprint to adjust where the product is going. It’s much quicker to avoid mistakes with the product and ensure that what’s finally made is actually what the customers truly want.

Scrum Master (or SM)

In this framework, the roles are broken out differently. Here, the scrum master is responsible for paying attention to the rules of getting the work done. In scrum, daily stand-up meetings are run by the scrum master (and those meetings are called scrums, from the rugby terminology of everyone jamming together!) The process of planning each sprint and how the work is completed is up to the scrum master to lead and organize.

But in essence, the scrum master is a coach to the rest of the scrum team (and that includes the product owner). It’s more of an advisory role, and not an authoritarian one. It’s a different mindset. It’s often described as a servant leader. The SM is there to help solve problems and to facilitate meetings and scrum ceremonies, not direct where they should go.

The Product Owner (or PO)

This role is quite close to the Product Manager from the waterfall methodology. The product owner is responsible for paying attention to the product, and how to make it better with the project. To do this, the product owner must break down what’s needed into use cases (a statement of what’s needed from a point of view, like from a user’s point of view, or an administrator’s point of view). These use cases are then prioritized before each sprint, and only those use cases at the top of the list will be worked on for the next sprint.

Here’s where the strength of agile or scrum comes in. At the end of each sprint, the product owner evaluates the product built so far, along with representatives from the user community. The PO and the development team then go back and loos over the remaining use cases. The product owner may want to add some features, take away some out of the backlog, or even modify and reprioritize them. The next sprint will include those use cases that can get done, and the cycle continues (hence the iterative approach).

A Related But Different Approach

Each methodology has the two roles: one that looks to the process and one that looks to the product. It’s how both the right work is being done and being done correctly and within the organization’s standards. The process breaks down without both positions being filled by strong individuals, so it’s best to get good at your role to ensure that your team has the best chance of success!