Project, Program and Product Managers – What’s the difference?

While many in the industry assume that the definitions for project, program and product managers are mutually exclusive and well understood, the reality is, these titles often become confused with one another.

Individuals will often use the abbreviation ‘PM’ to signify all three. And in truth, there is some overlap between the roles. You will often periodically find situations where a person is filling more than one role, spanning both product and project management (the man of many hats).

But on a fundamental level, what exactly IS the difference between those titles? What distinguishes them from one another and how do they often fill their own particular niches within an organization?

To answer this most effectively, it’s best to simply define them on an individual level and explain their particular role.

Project Manager

This is a professional that has the responsibility of planning, executing and closing any project. Typically, these individuals will reside in a variety of industries, such as construction, architecture, software and hardware development or telecommunications. (Along with many more) In general, this individual will be responsible for accomplishing the stated project objectives. Some key project management responsibilities include creating clear and attainable project objectives, drafting the project requirements, and managing the constraints, which are scope, time, and cost. In general, a project manager is usually only responsible for one project at any given time.

Program Manager

Like their counterpart, the project manager, program managers are also responsible for the planning, execution and closure of various company programs. The primary difference between the two is that a program is a group of inter-related projects and the program manager must deal with a larger set of complex dependencies. The Program Manager has oversight of the status of all projects in a program and can use this oversight to support project-level activity. In order to ensure that the overall program goals are met, the program manager will be providing the high level decision-making pertaining to all projects within the scope of the program. Generally speaking, a program manager is someone that had several years of tenure in managing individual projects before moving up and taking on the larger responsibility of more complex programs.

Product Manager

Based on standard definitions, a product manager investigates, selects, and develops products for an organization. They will often be responsible for performing tasks such as demographic analysis of users, competition analysis, feasibility studies and portfolio analysis as well as pricing and implementation strategies. For the most part, product managers will not be monitoring or controlling the projects themselves, but will often be contributing to their overall feature-set. Product Managers are almost always key stakeholders for specific projects and programs within an organization and will often assist in driving the primary requirements that make up the deliverables for a project.

In addition to the aforementioned roles, there are a few other key positions within an organization that also periodically overlap (or are confused) with project and program managers:

Product Marketing Manager

These individuals are usually responsible for what are considered the seven ‘P’s of marketing, those being: Product, Pricing, Place, Promotion, Packaging, Positioning & People. Product marketing, as opposed to product management, will generally deal with outbound marketing tasks. So while product management will deal with the fundamentals of the product development within an organization, product marketing deals with marketing the product to potential customers. In essence, these are the individuals that make sure that the branding and general advertisements relating to a product are handled adequately and target the correct demographics.

Business Analyst

These types of individuals are the ones that perform the analysis pertaining to the organization and design of businesses, government departments, and non-profit organizations. In addition, they also assess the business models and their integration with technology utilized by the firm. Generally speaking, business analysts handle the following four tiers: strategic planning, operating/business model analysis, process definition and design, and IT/Technical business analysis. Once again, similar to product managers, they will often be part of a project as stakeholders or advisors. Because business analysts often dictate internal process and have more fundamental knowledge of technical internals, they are an excellent resource that the project or program manager can utilize during the life-cycle of any given project.


Monitoring the Project – How are changes to scope handled?

Scope creep is one of the most common things that a project manager must contend with during the life-cycle of a project or program. Even in the best of circumstances, there will likely be conditions that warrant a change to an existing project mid-way through its life-cycle. And more often than not, this could occur several times during the project’s timeline. Concurrently, there will also be situations where a particular feature is revisited and deemed ‘out of scope’ based on new factors, such as a re-evaluation of user sentiment, problems in implementation or just simple deferment. Scope changes can and do occur.

With that being said, how should the project manager handle these types of situations? What sort of process should one have in place to be able to readily accommodate situations where a change in scope has been requested?

While it is often tempting for a project manager to take a rigid stance and decree that no new changes are permitted during a project’s timeline, this is not likely to be well received by stakeholders or management. As such, a project/program manager needs to instead take the stance of evaluating the change request and determining its feasibility and inherent risk.

If one refers to the PMBOK (Project Management Body of Knowledge), one of the process groups is ‘Monitoring and Controlling’. It is within that area that scope changes are likely to be catalogued and processed. Any stakeholder is permitted to request changes. These may be based on their own sentiment or driven by either an end user request or a business decision. Regardless of source, changes need to be addressed and it is important to have an action plan in place for these situations.

When performing the initial evaluation of the change request, some of the following questions should be asked by the project manager:

  • What exactly is the change and why is it being requested?
  • What impact does the change have on the overall project schedule and deliverables?
  • Is it possible to defer the change to a later iteration of the project?
  • What might be the downside risk of not implementing the change? Will it make the end project deliverables less marketable?

Whatever the change request, it MUST be documented, even if not implemented in the initial phase of the project. When addressing the change request, it is absolutely imperative that the project manager involves all stakeholders and addresses the change with the team members to ensure that all points of view regarding the change are effectively logged. There may be situations where the stakeholders agree to the change, but the team requests a deferment due to technical or resource issues. Concurrently, not all stakeholders may agree with the change request as is and may ask for it to either not be implemented or modified in some way to make it more palatable to all members.

Ultimately, whether the change is implemented or not will be something decided by the project manager with input from all stakeholders and team members. The type, complexity and feasibility of the change will be the mitigating factors in determining how or when the change will be implemented within the project’s life-cycle.