Many businesses today rely on project management to ensure that all the activities that are required to help the business function are able to do so efficiently. The importance of project management is ingrained into many businesses, and doesn’t need to be justified—or does it? For software development companies, product management also needs to be considered just as much, if not more. To determine whether both or one is needed, and to what extent, business leaders need to first recognize the similarities and differences between the roles of the project manager versus the product manager, and what each can bring to the business.
The key to understanding the differences starts with the descriptive writing mantra that everyone learned back in school: the 5 Ws (and 1 H), otherwise known as who, what, when, where, why and how. Though the who and where are generally self-explanatory, you can easily understand the difference between product management and project management by understanding which of the other four questions each job answers. Both positions fulfill critical roles in effective product delivery.
Product Management: Getting Concrete Answers
Product management answers the questions of “what” and “why.” These are important because, for every product you build, you need concrete answers to these questions.
What
The fundamental question that we’re asking here is, “What are we building?” Many enterprises have a product range that spans across dozens of different markets. Though this is great for the business and investors, it’s not an effective way for a team to work. When you ask a team to build or support 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 them to lose their identity if they attempt to do too much.
In a big enterprise, a “do everything” mentality can cost more over time. It’s likely that you have many software teams, and each one is building software that’s designed to suit a specific 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 is valuable. They help keep software teams focused on what they’re building and rein in the desire (by developers and executives alike) 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?” For developers, why is often more important than what. Work is almost always interconnected with the work of other teammates. When teams understand why they’re building something, it’s much easier to understand how those connections should work. It also gives developers information about which trade-offs they should make when implementing a feature, such as simplicity and usability versus speed.
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: The Thoughtful Side
Project management, on the other hand, answers a different set of questions. A project manager’s job is focused on the how and when.
How
Large software projects are complex, with 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. Developer downtime is minimized and it enables those developers to focus only on the problems they need to solve for each task.
Managing these kinds of interdependent requirements is the most valuable thing that project managers do for their software developers, though it can often be 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?” External stakeholders don’t care about how or why. They usually only care about what when the final product isn’t what they expected. But when is a question that’s top of mind for every single team leader who waits for a software project to be finished.
This is also the most difficult question to answer. It’s almost impossible to reliably predict how long it will take to deliver a feature—not even a whole project, just one part of it. Something that seems simple at the outset turns out to be much more complicated. Alternatively, sometimes something you think might take two weeks instead takes only a day or two.
The Balancing Act
In most traditional cases, both product and project management are crucial for software delivery pipelines to run smoothly. However, many enterprises are now 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. Additionally, many software teams transition toward agile software principles, which makes the collective software team responsible for the question of how. Third-party planning tools can also 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. However, the most successful projects answer all four questions effectively. When you don’t have a good answer to one or more of these questions, the project can end up stressful and frustrating.
The people answering these questions might change over time, as it has changed already. The crucial point is to just ensure that you do have people who are dedicated to solving these questions and relaying this information to their teams. This is the smartest way to ensure projects stay on track and deliver the product that is expected and needed.
