Almost all businesses today will rely on project management to ensure tasks are completed on time and all employees are meeting their targets. Ultimately, this is what makes a business successful. Its necessity is recognised across multiple industries and so many team leaders may believe there’s no need to justify its worth. But this isn’t always the case, particularly for software development. Another vital management role to be considered is product management – after all, the focus here tends to be on the product that is created. But for those more used to working with project management, and potentially questioning the value of both approaches, it’s important to understand the similarities and differences between the two, and what managers in these areas can each contribute.
The key to this starts with the descriptive writing mantra that everyone learned back in school: the 5 W’s (and 1 H), otherwise known as who, what, when, where, why, and how. Though the “who” and “where” are fairly self-explanatory, one way to understand the difference between product management and project management is by understanding which of the other four questions each job resolves. It’s useful to note: both positions fulfill critical roles in effective product delivery.
Product Management: The foundations of the job
The answers to “what” and “why” are typically found in product management. For every single product being delivered, these questions require solid, confident answers.
“What are we building?”
Many enterprises have a product range that spans 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 needs to do. This is especially true for software products because it’s easy for them to lose their identity if they attempt to cover too many functions.
In a large enterprise, a “do everything” mentality can cost more over time. Chances are there are many software teams, with each one building software that’s designed to suit a specific part of the market. When those teams spend time implementing software that duplicates some functionality already provided by your business, that’s time and effort being wasted.
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 expand the software outside the specific job it needs to do.
“Why are we building this?”
For developers, “why” tends to be more important than “what”. Work is almost always interconnected between different teams. When they understand why they’re building something, it’s much easier to understand how those connections should work. It also gives developers information about which compromises they should make when implementing a particular feature, such as simplicity and usability versus speed.
The product manager is responsible for understanding and conveying the “why” of the product. They do this by conversing with executives and project stakeholders to understand how the product fits into the overall business need.
Project Management: Getting the product over the line
In contrast, project management has a different focus. Here the biggest concerns are the “how” and “when”.
“How will we build this?”
Large software projects are typically complicated, with multiple interdependent and interlocking pieces. The most effective software project managers will understand these interdependent requirements and plan for them accordingly. They organise the individual actions so that by the time someone is ready to work on one piece, its dependencies have already finished. Thanks to this efficiency, developer downtime is minimised and those developers can focus only on the problems they need to solve for each task.
This management is arguably the most valuable thing that project managers do for their software developers, though it can often be missed by executives more focused on the second project management question: “when?”
“When will the project be finished?”
For external stakeholders, the “how” or “why” doesn’t matter, and they usually only care about the “what” when the final product isn’t what they expected. However, “when” is a question that’s always top of mind for every team leader waiting for a software project to be finished.
It’s also the trickiest question to answer. It’s almost impossible to reliably predict how long it will take to deliver a single feature, let alone a whole project. Something that initially seems simple can turn out to be much more complicated than anticipated. Alternatively, sometimes something you think might take a few weeks instead takes only a day or two.
Striking a balance between the two
In many traditional software organisations, both roles are equally as important for the efficient delivery of software releases. However, many enterprises are changing their deployment infrastructure towards a continuous delivery model with DevOps principles. Teams practicing continuous delivery may find that the question of when something is going to be completed can feel less important. Additionally, implementing agile software principles 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, dedicated project managers are becoming less common in some organisations. Instead, much of that responsibility is moved to the teams who then focus their planning efforts on the product itself. However, the most successful projects are those that answer all four questions. When an answer to one or more of these questions is unknown, the project can end up stressful and frustrating.
Different job roles come and go frequently enough in the technology sector, as advancements are made so regularly that staff roles have to change to keep up. The main point to take on board when it comes to product management vs project management is that there should be at least a few people in an organisation that are responsible for answering these four questions, and ensuring that their teams work to these guidelines. Doing so keeps the pipeline moving and keeps customers happy, which is the ultimate goal.