Here are three areas where you can better distinguish between these two roles.
It happens every week or so, even with close friends and family members: “You’re a project manager, right?” “Well, not exactly,” I’ll tell them before trying to articulate the difference between a product manager (what I do) and a project manager.
Beyond conversations with friends and family, what about business stakeholders that send one request to a project manager and a very similar request to a product manager with no real rhyme or reason? Take this even one step deeper into a scrum team dynamic where a software engineer asks for support around a particular roadblock from a project manager — when their teammate is already working with the product manager on the same issue.
There’s an obvious need for clarity between the two roles: What are some of the key differences that are simple for all interested parties to understand?
These are three areas where project managers and product managers play a distinct yet equally important role in the delivery of a product that meets business objectives:
- Establishing the vision.
- Driving velocity.
- Ensuring efficient communication.
But who is responsible for what and how do they work together to get it all done?
Establishing The Vision
Within any development organization, understanding the vision of a given product and project is paramount for both business stakeholders and internal teams. When I say vision, I don’t necessarily mean just rallying the team around a specific vision statement. More specifically, everyone involved in a product development venture should be asking themselves:
- Why are we building this product?
- How are we going to get it done?
While the answer to the first question doesn’t solely rely on the product manager, this ball is clearly in the product manager’s court. There are numerous methods used to help answer this question, but the answer should be driven solely by data. This data could come in many forms: customer interviews, analytics of previous products, market and competitive research, and so on. The key here is that the answer to the “why” is actually driven by data, not just a product manager’s hypothesis.
What’s a key artifact that a product manager produces in answering the “why” question? A clear value proposition: This includes the target customer, customer needs, product name, product category as well as the benefit of the product, its competition, and a differentiation explanation.
Similarly, the second question isn’t solely related to the project manager, but this is where they excel. And by “how,” I don’t mean developing the technical architecture and knowing the answer to every question. The “how” revolves around securing the right resources, ensuring time, scope, and budget align to meet stakeholder expectations, and producing a solid plan to get there.
What’s a key artifact that a project manager produces in answering the “how” question? A project plan that contains the required resources (personnel and capital), project scope, and a comprehensive timeline with key dates and deliverables.
Once the “why” and the “how” questions are answered, and a product moves into the build phase, product and project managers work together to drive team velocity. For project teams to become a high-performing, high-velocity machine, both project and product management have to deliver in a few core areas. But you guessed it, their responsibilities look slightly different.
While gathering requirements is a group effort, the brunt of this responsibility rests with the product manager. The methods and tools used to gather and document these requirements may vary, but this takes dedication and commitment from the product manager to do effectively. Development teams cannot achieve nor exceed expected velocity with missing, poorly written, or unprioritized requirements. Concise requirements, ordered to deliver value to the customer quickly, are therefore needed from product management to achieve velocity.
What’s a key artifact that a product manager produces to drive project velocity? A prioritized and refined product backlog; user stories with clear acceptance criteria that are ready to be worked on by the development team. The priority of each work item is not a simple formula, but a combination of factors that include value, effort, readiness, dependencies, timelines, and more.
Digital products are never completely self-sufficient. There are internal and external dependencies that must be identified, planned for, and delivered in order to build the given product. Whether it’s a third-party service that needs to be integrated or application programming interface (API) keys that are waiting on that person from DevOps that has way too much on their plate, the success of a product depends on numerous parties. Managing all dependencies and deliverables is one area where project management thrives. Nothing ever really goes completely according to plan either. When blockers for a development team arise (like waiting for DevOps), the project manager steps in and solves the problem to keep the team moving.
What’s a key artifact that a project manager produces to drive project velocity? A dependency chart listing all internal and external dependencies with detailed deliverables and deadlines.
Ensuring Efficient Communication
There’s an element of efficient communication needed from pretty much anyone in any organization, but what specifically is being communicated from the product and project manager?
The project manager is the central source for execution-focused updates to all stakeholders. How is the team tracking committed dates? What is the overall project status? Are there risks that need to be addressed? These are all questions that are answered by the project manager through regular updates.
What’s a key artifact that a project manager produces in order to efficiently communicate with business stakeholders? An executive status update: A regular update that provides a clear picture on the status of key deliverables, highlighting any major project risks.
But the project manager isn’t the only party responsible for providing key communication to stakeholders. Regular communication expected from a product manager is more strategy-focused. A product manager works with business stakeholders to establish key performance indicators (KPIs) and objectives and key results (OKRs) when strategizing and planning for the roadmap. They ask questions like: Once we’ve delivered a product into the market, how is it performing based on these metrics? The features that we’re delivering are expected to move the needle in the right direction on these KPIs and OKRs. Is the product actually delivering results? How are we tracking against KPIs? Have our assumptions about features been validated?
Everyone may have access to the analytics, but the product manager is responsible for making sense of the results, validating previous assumptions, and pivoting the roadmap accordingly. Stakeholders should expect to see clear updates on whether the product is delivering the results to the customer as expected, and how these results continue to refine and shift our roadmap.
What’s a key artifact that a product manager produces in order to efficiently communicate to business stakeholders? An ever-changing product roadmap. This isn’t just a static artifact, but it is driven by new insights as data becomes available. Themes and features on the roadmap are always adapting to meet the needs of the customer and deliver value to the business.
Clarity–With Space to Collaborate
While the duties of both product and project managers are distinctly different, the success of a product depends on these two crucial roles working together to evangelize a shared vision, drive velocity, and communicate efficiently.
Is the delineation above a set of hard and fast rules? Of course not. There will be overlap depending on the product, project, and organization. In your company a product manager may send an executive status update and a project manager may groom the product backlog. What’s important is that there is clarity in focus for both roles for the sake of your stakeholders, internal development teams, and maybe even friends and family members.