This short memo is to clarify the proper usage of these roles in the context of software development projects: Product Owner, Product Manager / Manager, and (Software/Product) Architect.
The term Product Owner is mainly used in Scrum context. In Scrum methodology, it is clearly defined. In fact, there are only two roles that Scrum defines explicitly and that is Scrum Master and Product Owner. While the former is a manager-facilitator of the process, the later represents the client (user) voice. Product Owner’s activities includes:
- Intensive communication with stakeholders; which might include: clients (up to C-level), internal and external users, or third party business users
- Key influence on the product vision, again from the client and end-user perspective
- Management of the product backlog, following the regular Scrum methodology
- Management of priorities over the project lifecycle
- Active, influential participaton in the team progress: sprint planning, review, and retrospective meetings
In essence, the product owner represents the stakeholders and acts as the primary liaison between those and the product team.
Note. This makes sense within Scrum, where Product Owner fits the process puzzle. Using the term Product Owner outside Scrum, in my view, is unclear unless defined explicitly. The term Product Manager might be a better choice. In DevOps however, the term Product Owner is used in similar sense to Scrum.
Scrum is popular Software Engineering methodology, but not the only one. In non-Scrum context, the term Product Manager is often used to describe a role that oversees the process of product creation. It typically encompases some more responsibility than Scrum Product Owner. Product Manager might be asked to
- define the product, starting from user requirements or software requirements
- define the product architecture (themself, or using help of architects)
- create strategy and product roadmap
- kickstart and coordinate the development
- oversee the user feedback communication and drive maintenance actions, such as post-mortem improvements
Product Management is a broad field, it obviously predates Scrum and hence is more loosely defined since it is not encompassed in any particular technology.
Project Manager / Manager
One thing Product Managers typically don’t do is the daily project management. This is Project Management role. Project manager would:
- manage the Software Engineering process where the product is created including its all stages (and this can be both in traditional plan-driven methodologies, or agile value-driven such as XP, Scrum, Lean, Kanban, DevOps. For instance, if Scrum is selected, the Project Manager might act as Scrum Master)
- take responsibility for the product delivery and other project deadlines
In reality, especially in smaller projects or smaller consultancies, Project Manager might be asked to also overtake Product Manager’s tasks, so we’d have two roles in one. Some people consider this a breach in methodology. I do not share this view. In smaller projects it is not practical to have too many roles, and this can have various negative effects.
If one person shares a number of management roles, such as Product Manager and Project Manager and Team Manager, Team Lead roles, it is more practical to refer to him or her simply as a Manager.
A Software Architect (or simply an Architect), you guessed it, defines how the product works internally, in other words draws the product architecture. His/her role is also to facilitate, oversee and approve the architecture evolution. In larger projects, this work will be divided into distinct areas such as Data Architecture, Security Architecture, Business / Solution / Enterprise Architecture and more, with perhaps several specialists (Data Architect, Solution Architect etc) working hand in hand. More on this has been explained in a nice DZone post here.
Importantly, Architect is a technical role rather than project role. Hence it is not uncommon that a Product Manager is also an Architect, and again, there is nothing to frown upon if this happens.
Notably, in Scrum there is no defined place for an Architect. This is because Scrum does not operate on technical level. The Scrum team is, in principle, self-organized and multi-disciplinary. In other words, anyone in the Scrum team, including the Product Owner and Scrum Master, migth also be the Architect, or this role might even be shared.
In other methodologies, the role of an architect might be defined more explicitly. For instance, typical DevOps roles tend to be more technically aligned than it is the case with Scrum.
If you operate within a certain Software Engineering practice such as Scrum, Extreme, or Lean, some project roles might be predefined and work the same across companies. If however the development methodology isn’t clear, it is often a good practice to agree on the role description upfront, for the clarity of expectations, as the same roles across companies might mean quite different things.