Product vs Project Management

Also known as: building the right thing versus building the thing right, or why being user-centered is essential to a successful product.

5 minute read

I’m hardly the first person to write about this (though this article is particularly relevant/pointed), but it’s been coming up a lot for me lately as I think about what I want to do next, work-wise.

One of the things that I’ve seen come up time and time again is the need for a Product Manager. It seems that most companies have a great sense of how to execute, and they’re great at the work that they do, but figuring out what they should be doing can be a struggle. This shows up for consulting firms in the form of rework and for product firms in the form of failed product launches. I will always cringe when I think about how much time and money is wasted creating things people don’t want.

So let’s talk about some of these differences.

Project Management

Project - a (often temporary) endeavor undertaken in order to complete a task, achieve a goal, or create a product or service. Casually, a project is just a thing a person or group does to accomplish something.

Project Manager - the individual responsible for coordinating resources, tasks, and schedule in order to ensure the project is successful. This often includes things like getting stakeholder buy in, securing a budget and/or time, assembling the right team of individuals, picking a methodology (whether agile, waterfall, or anything else), creating a backlog, planning tasks, etc.

Successful Project Managers are good at getting the right people involved and following up with them to make sure they have everything they need to fulfill their role.

Common Questions

Product Management

Product - a good, service, or tool built in order to solve a problem for a user (or, ideally, users). Casually, a product is something people use.

Product Manager - the individual responsible for figuring out what the thing is supposed to do and how it’s supposed to do that. This may include determining feasibility from a business/financial standpoint, conducting any market and/or user research required to gain insights into who the end user is and what their needs are, defining a set of features to satisfy user needs, creating low-fidelity prototypes in order to communicate feature sets and behaviors, etc.

Successful Product Managers are good at knowing what role their product serves and for whom, and ideally can align business goals with the needs of the end user.

Common Questions

Separate, but equal?

Now that we’ve defined some of the differences between the two PMs, we can better understand the role each fills, what their concerns are, and why they’re important to success.

Product Managers are going to be talking to a lot of different stakeholders early on in the lifecycle and making sure it makes sense to move forward with a project. Product Managers are going to be doing a lot of the discovery phase of a project, and then stay involved throughout the implementation to make sure what’s being built matches the idea (as well as, ideally, running users through interim usability studies to catch any issues that were hard to predict before having an artifact to interact with).

Project Managers are going to be more involved in the day-to-day of a buildout, having little interaction with the product before that step of the process (sure, it’s possible to have a PJM involved through the process in order to have background knowledge but also keep track of resources through the entire lifecycle, but in my experience that’s the abnormal case). Project Managers will be focusing on managing expectations of the stakeholders, interfacing with the Product Manager, and securing whatever resources are needed. The Project Manager is also going to be working with the implementation team, making sure they’re on task and working well interpersonally.

The classic analogy is the project manager as a midwife, whereas the product manager is the mother. Project will come in to deliver the baby, but all of the preparation before and all of the care afterwards is up to Product. I like to think of it more like an architect versus a foreman.

All of the planning, research, and vision is the architect’s responsibility, and once the building is done, they’re the ones who everyone will look to when the building is successful or not (obviously there’s some back and forth with engineering as well in terms of feasibility…another parallel in software). The foreman is responsible for making sure his team can execute and do what’s been planned out, but they’re often the unsung heroes of a successful project.

A brief plug

Did you find yourself reading this post and thinking “we’ve got the project part down, but shoot, having a product person would be great”? Part of the reason this has come up a lot for me is I’m looking into a product-manager-as-a-service model. You should contact me if you’d like to hear more.

All User Experience posts: