
The Difference between Product Owner and Product Manager
Recently I was asked what the difference is between the functions “product owner” and “product manager”. Apart from the fact that several disciplines claim the position “product manager”, there seems to be an overlap with the role of “product owner”. Let’s see where these terms and disciplines come from.
Application of product management
Assortment or services
In this application, product management involves the management of a product (in the form of a physical product or service) throughout its entire life cycle. The exact interpretation varies based on the organizational structure. One big similarity is that product management always plays an interdisciplinary role. It builds bridges between product development, procurement, marketing, sales and logistics.
Software
Software product management (also called “digital product management”) involves the discipline of building, implementing and managing software or digital products. Products are defined based on organizational elements and revenue streams. Read more in the article “Product definition within SCRUM agile“. SCRUM teams take ownership of a specific product and optimize it incrementally. Product management also fulfils an interdisciplinary role within an organisation: it builds bridges between technical and business departments.
Background in software development
Product Manager
Product management can be traced back to 1931. Hewlett Packard was one of the first technology companies to implement this task and organize itself based on products in the 40s. Big tech companies have had product managers from the beginning. So this discipline is not new, but evolved rapidly as more companies transformed into digitally oriented organizations.
Product Owner
SCRUM appeared just before the “Agile Manifesto” was written in 2001. It introduced the concept of a product owner. This was a person who was a “spokesperson” for the client and told the developers what the requirements were for what needed to be built. In the beginning, the product owner represented the customer; an internal person in the company who was part of the team and prioritized the backlog. This is also the way I started myself.
SCRUM definition
If you look at the role of the Product Owner in most SCRUM literature, these are the three main responsibilities:
- Define the product backlog and create applicable user stories for development teams. Who actually writes the user stories differs per organization;
- Form and prioritize the tickets in the backlog;
- Accept user stories to make sure they meet your predetermined criteria;
The exact interpretation changes per programme and organisation. However, you can see that the above points form the basis during most courses to certify product owners. SCRUM provides a lot of information about the processes and rituals of what you have to do as a product owner, but also leaves many questions unanswered. For example, how do we know we’re building the right thing?
The circle is complete
This is exactly where product management comes in. A good product manager learns how to prioritize work against clear result-oriented goals. How to discover and validate the real customer and business value. Which processes are needed to limit the risk of insufficient value increase. Without this background in product management, a person can perform the role of product owner, but he or she can never succeed in building the right thing.
Role vs. function
If you take away your SCRUM team, if you take SCRUM away as a process within your organization, then in my opinion you are still a product manager. Product management and SCRUM work well together, but product management is not dependent on SCRUM. It can and should exist with any framework or process.
Product owner is a role you play in a Scrum team. Product manager is the job.
As a product manager, your role and responsibilities change depending on the context in which it is carried out and the phase in which your product is located. Without a SCRUM team or with a smaller team, you could pay more attention to exploratory or strategic work. With a SCRUM team, you may be more focused on operationally improving products. As a manager of product managers, you are generally more focused on the strategy, market and connection with your company vision, and you coach the teams to perform even better and to operate side by side.
Professionals who are fully focused on the role of product owner usually forget to focus on the actual problem definition and are therefore unable to come up with effective solutions. They forget who the user is and thus lose the connection with the actual end goal. I know of examples of product owners who spend 40 hours a week performing typical product owner tasks, so that there is no talk of product management. If no other product managers have been appointed, you can ask yourself: are the user stories that are written actually valuable? What problem are they actually solving? How do we know if this is actually the solution?
Best of both worlds
Are you working as a product owner in a SCRUM organization but do you not feel like you are taking on the role of product manager? To prevent you from ending up in the so-called “Build Trap” (excessively concentrating on quantity instead of quality), it is therefore important that you look for balance. With a well-thought-out strategic plan and effective prioritization around some clear goals, I am convinced that one person can perform the role of product owner and product manager and thus talk to customers, understand their problems and thus take the lead in forming effective solutions.
This idea is endorsed by both Scrum.org and Scrum Inc. The latter also says that a product owner should spend half of their time talking to customers and the other half working with the team. I agree with this direction, but I think it is too short-sighted. In practice, the distribution must be adapted to the situation. When starting up new initiatives, you are usually more focused on your users, the moment your plan is converted into stories and they are adopted by the team, you automatically have to spend more time on the transfer and correct interpretation.