Product vs Project vs Program Management
Too many teams struggle with the nuanced differences between Product Manager, Product Owner, Program Manager, and Project Manager. I’ve created this chart to capture the key differences between them.
Product Manager
Product Management began as a subset of Brand Marketing, in the Consumer Packaged goods space. The idea was to have one person fully own a single product end-to-end, and be responsible for all aspects of the product. This made the role inherently strategic, because getting product-market fit right, is what would make everything else work. This is also the context from which the “CEO of the Product” mindset formed because this role would truly have end-to-end responsibilities and accountability for their product. Principally though, the purpose of the Product Manager is to drive a business outcome through Product-Market fit – and everything else is a means to that end.
Product Owner
The role of the Product Manager was fairly clear until it entered the digital ecosystem in the 1990s. The reason Product Management rose to prominence in tech during this era, was the rise of Agile/ Scrum methodology which calls for every Scrum team to have a “Product Owner”. Scrum, defines the Product Owner as having similar responsibilities of a traditional Product Manager but with a more tactical and inward-facing focus. It was a role defined as supporting and serving the Scrum team, rather than the other way around as was typically the case with tranditional CPG Product Managers who worked with agencies and contractors to develop their products.
Adding to this difference, Scrum became commonplace for most development teams, regardless of whether they were working on a product development or even something more operational by nature. As a result of this Agile transformation, it is not uncommon to see traditional Business Analysts in an IT context, playing the role of Product Owner, sometimes even with an updated title of Product Manager. In truth however, many of these roles have nothing to do wih the original concept of a Product Manager. Morover, what is the Product in that case?
Project Management
The Project Manager is probably the best known of all of these roles because it has been around for a long time and transcends industry and processes. Project Managers focus on coordinated delivery and is singularly focused on aligning all parties to complete a delivery, to a given projected date. They listen for issues, help to unblock, and report back to stakeholders when issues arise. In the Software world, the Project Manager is mostly utilized where there are very large projects and a lot of cross-team dependencies that must be coordinated. Project Management is mostly practiced with large-scale IT deliverables that are known up-front and executed using Waterfall process. By contract, in the Agile approach, full stack teams generally are set up to be as autonomous as possible and minimize the cross-team dependencies and that’s generally where you’ll find Program Managers.
Program Management
Program Management shares an emphasis on delivery with Project Management but is looking at it more holistically in terms of creating an efficient delivery pipeline for multiple projects, rather than delivering a single project. To that end, a Program Manager is similar to a Product Manager because they’re taking longer-term ownership of something – the difference is what they’re taking ownership of and how they measure success. For Product, it is Product-Market fit and measured by some KPI related to revenue, whereas for Program it is efficient delivery as measured by efficiency and predictable output. You might find Program Managers overseeing an internal operational service or when they’re working with Scrum teams, they might own “the program of Scrum”, acting as ScrumMaster, and ensuring the teams are applying best practices and keeping the trains running
The Ideal Approach
For small Products it is simple – the Product Manager owns market strategy for the Product as well as the Product Owner role for feeding the team with requirements on what to build.
For larger scale products, it is very likely you need more than one person on the Product team to support all of the work that must be done. This probably means you have one Product Manager at the Director level (Director of Product) who is leading strategy and there might be multiple “feature teams” (Scrum teams focused on a thematic group of features) which are supported by corresponding Product Owners, who do the analysis, write the requirements and support their teams, in the development of features.
In an Agile context, there must also be someone who plays ScrumMaster for the team, to ensure the delivery pipeline is working efficiently and releases are planned – this could be anyone on the team such as a technical lead but ideally this would be a dedicated Program Manager for the Product who could work to coordinate all disciplines such as UX, content, data science – not just engineering. No matter what though, the Product team should NOT be playing the ScrumMaster role since this involves a lot of coordination work that necessarily means the urgency of day-to-day coordination (ScrumMaster) is placed ahead of the important longer-term strategy work that really impacts the success of the product – this should be avoided whenever possible.
In a Waterfall process, you’re more likely to have functional teams rather than autonomous feature teams that means there are more cross-team dependencies to be coordinated – this is typically where you’ll see Project Managers playing an analogous role to Program Managers in the Agile context. The key difference is that with Agile, the feature teams are set up to own a longer-term pipeline for feature development whereas in a Waterfall context, teams are usually setup more functionally (Web team, backend team, UX team etc). This means the work is managed at the project level rather than the program level, and thus you have Project Managers in that context.
Conclusion
At the end of the day, the prerogative of Product is to understand the market, and solve common problems at scale to achieve product-market fit. Process and roles should facilitate this, not distract from it. So start with this ideal in mind, and the correct process and supporting roles (Product Owner, Program, and Project) should follow from there.