Product Management vs. Project Management in the Enterprise

The 5 W’s

It’s actually pretty simple to illustrate the difference between product management vs project management. The key to doing so starts with the old descriptive writing touchstone that I learned during my high school journalism career: the 5 W’s (and 1 H). I was taught that all factual descriptive writing should answer six questions: who, what, when, where, why, and how.

You can easily understand the difference between product management vs project management by understanding which of those questions each job answers. Both product management and project management fulfill critical roles in effective product delivery. As a full-time developer, I find that I’m most effective when I have all these questions answered when I start working.

As we’ll discuss next, product and project management each address a different W (or H) from the questions listed above. Let’s start with product management.

Product Management: What and Why

In the list of 5 W’s, product management answers the questions of “what” and “why.” These are important questions! For each product you build, you need concrete answers to these questions.

What

The question that we’re asking here is “What are we building?” This is a fundamental question for your enterprise. Many enterprises have a product range that spans across dozens of different markets.

While that’s great for the business and investors, it’s not an effective way for a team to work.

When you task a team with building or supporting a product, they need a clear vision of what that product will actually do. This is especially true for software products because it’s easy for software products to lose their identity and try to do too much. To paraphrase Jamie Zawinski, every software product will continue to expand until it tries to read email.

In a big enterprise, that kind of “do everything” mentality winds up costing your company. It’s likely that you have many software teams, and each one is building software that’s designed to suit some part of the market. When those teams implement software that duplicates some functionality already provided by your business, you’re wasting time and effort.

This is where a good product manager shines. They help keep software teams focused on what they’re building and rein in the desire (by developers and executives) to grow the software outside the job it needs to do.

Why

The other major question that product managers answer is “Why are we building this?”

As a developer, I find why to be even more important than what. It’s rare for me to create a feature that is self-contained, with no possibility for expansion in the future. Instead, the work that I do is interconnected with my colleagues’ work. When I understand why we’re building something, it becomes much easier for me to understand how those connections should work.

Understanding why we’re building something also gives me information about which trade-offs I should make when implementing a feature. For instance, we build some features to be used by a variety of people. For those features, prioritizing simplicity and usability is most important. Other features are targeted at power users. For those features, speed is often a more important factor than usability.

It’s the job of the product manager to understand and convey the why of the product. They do that by conversing with executives and project stakeholders to understand how this product fits into the overall business need.

Project Management: How and When

Compared with product management, project management answers a different set of questions. A project manager’s job is to answer the questions of how and when.

How

Large software projects are complex organisms. They have many interdependent and interlocking pieces. Efficient software project managers understand those interdependent requirements and plan for them. They organize the project’s tasks so that by the time someone is ready to work on one piece, its dependencies have already finished. This way, you minimize developer down time and enable those developers to focus only on the problems they need to solve for each task.

Managing these kinds of interdependent requirements are the most valuable thing that project managers do for me, a software developer. In my experience, this kind of work is often missed by executives, who are much more focused on the second project management question: when?

When

This is the visible project management question: “When is that project going to be done?” For external stakeholders, they don’t care about how or why. They do care about what, but they mostly only care when the final product isn’t what they expected. But when is a question that’s at the top of mind for every single team leader who waits for a software project to be finished.

When it comes to software projects, this is also the most difficult question to answer. I’ve been in software a long time, and I’ve yet to meet someone who could reliably predict how long it would take to deliver some feature—not even a whole project, just a little part of that project. Something that seems simple at the outset turns out to be much more complicated. I’ve also worked on features where, at the start, we weren’t even sure we could deliver. Then, after a bit of research, we found that there was a library that did exactly what we needed to do. Something we thought might take two weeks instead took only a day or two.

Product Management vs Project Management in an Age of Continuous Delivery

In my experience, both product and project management have a critical role to play in traditional waterfall software planning systems. However, many enterprises are moving their deployment infrastructure toward a continuous delivery model, which adopts DevOps principles. For teams that practice continuous delivery, the question of when something is coming out can sometimes feel less important. Your team will deliver that thing as soon as it’s ready!

Additionally, many software teams transition toward agile software principles, which makes the collective software team responsible for the question of how. Other pieces of software, like Plutora’s Deployment Planning and Release Management tools, make it easier for software teams to answer the how and when questions for themselves.

For this reason, many teams are transitioning away from using dedicated project managers. Instead, they move much of that responsibility to the teams and focus their planning efforts on the product itself.

Know the Answers to All These Questions

As a developer, I’ve worked on teams that failed to answer some of these questions before. Sometimes, the question we failed to answer was how, but many times it was what or why. We always seemed to answer when, even when we didn’t have the answers to any of the other three questions!

The most successful projects I’ve participated in have answered all four questions effectively. When we didn’t have a good answer to one or more of these questions, the project wound up being stressful and frustrating. It rarely shipped in the time window that we wanted, and it was often missing features considered critical at the outset.

Successful software projects answer all four of these questions. In today’s software teams, the person or people responsible for asking each question might shift over time. Each question might, at times, be poorly defined. But the key is that, without those answers, the project is going to struggle to ship what you want.