The last decades have brought tremendous change in the digital and business environment. Project management itself has also faced several changes as the digital transformation is reshaping more industries than ever. At the same time, its importance could have never been so clear before.
Projects are no longer considered delivery mechanisms, but they have strategic importance in different organizations. No wonder that project managers and other professionals specialized in project management processes are in high demand. However, with the rise of modern and Agile methodologies, the roles in project management teams vary, which leads to common misconceptions.
In this article, we’ll describe critical roles (which can be assigned to one or more people) that are necessary to make sure a project will succeed and explain the commonly confused differences between them. Are you wondering what the difference is between a Product Manager and a Product Owner is or what a Scrum Master is? Then read on...
But first of all, let’s make sure that the difference between traditional and Agile project management methodologies is clear by having a look at their most common examples.
Traditional and modern project management in contrast
Traditional project management: Waterfall
According to the Project Management Institute (PMI), project management is defined as “the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements.” With the traditional method, often referred to as the "waterfall" and now considered very rigid compared to the more modern variants, these project activities follow a clear sequence. The process can be imagined like the step-like fall of a cascade, hence the name waterfall. One phase follows the other, depends on the completion of its predecessor phase and can only be started once the predecessor has been completed.
If we take software development as an example, the concept could look just as shown in the following picture:
We describe the requirements, then go on to design, then implement the requirements, then start testing to detect bugs and finally the last phase follows, the maintenance. So jumping from testing back to the requirements catalog is not intended in this case. We see that the model brings structure, but little flexibility.
Modern project management: Agile
That’s why Agile development methodology has emerged. Instead of following a rigid process, Agile focuses on staying flexible in order to deliver the best possible version. To do so, it breaks the whole project into smaller processes.
One of the most popular implementations of Agile methodology is Scrum, which aims to deliver business value as fast as possible. Within the Scrum process there are several sprints, at the end of which there is always a functional end product. This approach allows experimentation and the integration of changing requirements at the end of each sprint.
You can learn more about popular project management methods here.
As stated above, each project management methodology comprises of various roles which often get confused. For teams to be able to work seamlessly, it’s essential to understand the differences between roles and don’t use them interchangeably while communicating with other shareholders.
Let’s take a look at them precisely and compare with each other.
Project Management roles that people often get confused with
Product Manager vs. Project Manager
Two roles that people often confuse are that of project manager and product manager. Projects very often revolve around the creation of a certain product and therefore it is easy to suspect that a product manager is simply a project manager for this type of project. In fact, however, the two roles differ significantly in their objectives.
A Project Manager role can be a part of most methodologies. A person who occupies this position is responsible for one or various projects and oversees it from beginning to end. It comprises dividing strategic plans and visions into task-oriented initiatives that are possible to achieve, measure, and deliver.
When this is done, the Project Manager has to coordinate the work of a diverse team to complete a project timely (and obviously without exceeding budgets), being also responsible for resources and quality. The Project Manager is internally focused and process-oriented.
Conversely, the Product Manager, whose focus is clearly on the strategic development of the market-relevant factors for the product, with the greatest possible benefit and value. Product managers create the vision of a product, communicate it and are responsible for its success. In this context, the marketing mix (the 4 P's: product, price, distribution, promotion) becomes particularly relevant for a product manager.
The product manager is, so to speak, the representative of the future user and must be able to think his way into the latter's mind. They should be able to answer questions such as "What are we developing?", "What problem does the product being developed solve?", "What advantages does it offer and what value does it have?", "How does the product reach the customer?" and "How is the product communicated and promoted?” The Product Manager is therefore externally focused and market-oriented.
In short: Different Goals for Project Manager and Productmanager
So, there are many differences between Project Manager vs. Product Manager. The Product Manager has to plan and create a strategy that will lead to building and delivering a product. They are responsible for the entire lifecycle of the product and its development and must therefore keep an eye on the market and be able to react strategically. The Project Manager has to oversee the execution of those development plans The project manager must monitor the execution of development plans, which requires leadership and organisational skills. A Product Manager is involved with a project that concerns the product they are developing, they define the project’s scope but don’t control or coordinate the project(s).
Product Manager vs. Project Manager in reality
In theory, the roles are clearly differentiated and formulated as separate "full-time positions". In reality they are often not so clearly defined. In some cases, the product manager is even assigned the role of a project manager on top and vice versa. Especially in large companies and within large projects, however, both project management roles are frequently encountered. The differentiation of project-internal and market-relevant issues by different areas of responsibility ensures that the project manager remains independent of external influencing factors. The two people responsible then work closely together in the product development process, which - in a very vague project sequence - could look like shown in the following graphic:
Product Manager vs. Product Owner
The role of Product Manager was discussed in the previous section, so let’s just summarize that product managers focus on the long-term strategy, the company’s objectives, market research, create a product’s vision, and present it to Stakeholders. They are strategic. But what is the difference to a Product Owner? Same role, different name? Not quite.
Whereas Product Managers work in different methodologies, the role of the Product Owner is part of the Scrum Methodology next to the Scrum Master and the Development Team.
The Project Management Institute (PMI) defines Scrum as: an Agile method of iterative and incremental product delivery that uses frequent feedback and collaborative decision making.
To put it simply, teams adapting the Scrum methodology work iteratively in regular cycles called sprints that end with a usable intermediate product - the increment. Thanks to the experience and knowledge from previous sprints, every next sprint is predictable and decisions, are based on what is known. Scrum enables experimental developments and thus creates more freedom for the team and more possibilities for the project.
Product Owner works as a liaison between Stakeholders and the development team to make sure developers understand what features are needed to create a product that meets customers’ expectations and a Product Manager’s vision. They are a user advocate, attend team coordination meetings, organize demos, are involved in testing efforts, create user stories and manage the backlog (e.g., prioritize work).
The main difference between Product Manager vs. Product Owner is that PM oversees the whole vision and development process of a product, and the Product Owner works closely with a development team that has to execute this vision correctly. Instead of a purely strategic orientation, he specializes in the tactical implementation of product requirements. Product Owners are considered as members of the working group that carries out the project in accordance to the Scrum Methodology, while Product Managers work outside of this team.
Comparing project management roles: Product Owner vs. Scrum Master
We already know, that a Product Owner is a fixed role within a Scrum Team other than a Product Manager. Those who have not yet dealt with the Scrum roles in detail will probably come up with the following question:
If the Product Owner is responsible for the product, defines the requirements and communicates with stakeholders. Which function does the Scrum Master fulfil then?
Now, let's discuss the difference between a Product Owner and a Scrum Master. After all, both roles are integral members of the Scrum Team. The official Scrum guidelines assign the following tasks to these two roles:
|Defining, managing and prioritizing the product backlog
||Ensuring transparency about the objectives and the scope of the product development process
|Optimizing the work of the development team
||Providing techniques for the formulation and management of the backlog and a basic understanding of it in the entire Scrum team
|Ensuring the transparency of the product backlog for the entire Scrum team
||Communicating the agile methodology
|Ensuring that the product backlog is understandable for the development team (for example, with appropriately formulated user stories)
||Support the implementation of Scrum events on demand or on request
As mentioned above, a Product Owner is responsible for increasing the value of the product. They, among others, manage the product’s backlog, prioritize needs, anticipate clients’ needs and act as a primary liaison. Product Owner is a part of the Agile Development Team, which connects them with the Scrum Master role.
A Scrum Master’s role includes assisting the Product Owner and the Agile Team in creating a successful target and working as a bridge between these two vital elements of the Scrum Methodology. Scrum Masters are responsible for establishing the Agile principles by using the right processes and need to ensure the team lives these principles, all in step with the Agile manifesto and its 12 principles. One of their topline goals should include increasing team productivity, motivating team members fighting for changes that will ensure quality and timeliness.
One task that the Scrum Master usually does is to hold the Sprint Retrospective - one of five Scrum Events in which the process flow of the last Sprint is examined and suggestions for improvement are made and where there is room for improvement for the following Sprint.
Stakeholder vs. User
There is also a risk of confusion for the next two PM rolls. Often the terms stakeholder and user are used synonymously which by no means is always wrong. However, sometimes it is.
A user (end user) is defined as a group of people, who use the finished end products. They are neither part of the team, nor (unless the product is specifically for internal use) part of the organization that developed the product. However, the intention of the product is designed for their needs.
Especially users/customers are often equated with the term stakeholder. In a way, this is correct, because users are one of the groups of people who generally fall under the collective term stakeholder. However, they are not the only group.
A Stakeholder is such a broad term that it could mean myriad things. It may apply to various individuals, depending on a project, that’s why it may cause a lot of confusion. Anyone who gets engaged in a project and has an interest in or an influence on the product, but is NOT a part of the exact team that works to create a certain product or service (this is important!), may become a Stakeholder. Users, for example, are not directly involved in the project. However, they will use the final product after the project is completed, which means that they represent a concrete influencing factor.
Who exactly can be a Stakeholder in project management? Just to name a few of them:
- decision-makers in a company
- project sponsors
- a legal department within a company
- business partners
Stakeholders play a vital role in the success of the team that carries out the project. They help discover, develop, launch, promote, support and improve the product by providing continual feedback and reviewing the outcomes of any project.
Stakeholder vs. User - main differences
The difference between Stakeholder vs. User boils down to the fact that Stakeholders not necessarily use the product, but have a direct influence on the development process, assess it, and evaluate the outcomes, benefits, costs, etc. Users, on the other hand, are those who will interact with assets produced by the project to deliver benefits. Users may have an indirect influence on the project (via consultations with potential end-users), and their interest may decide on the success or failure of the product.
Usually, if a product is not aimed to be used internally in an organization, a user is simply a customer who will pay for a particular product or service you developed.
It’s important to note that Users can be considered a part of a group of Stakeholders.
Do you know all project management roles?
Understanding the differences between various project management roles is crucial to properly apply them to ensure the success of each project. As the definitions vary across organizations, leaders should ensure that all team members are on the same page.
Some roles may overlap and seem that they include similar responsibilities and functionalities, though their names shouldn’t be used interchangeably. This will help organizations omit confusion and make sure all parties involved in the project understand their duties and liabilities.