Product Manager or Product Owner?

One common slippage we have experienced in many of our projects is underestimating the importance of the role accountable for the product’s success over time while bridging the market and business needs with the technical solutions. This role may be referred to as a Product Manager or a Product Owner in different organizations or frameworks. However, we have seen that the scope and expectations of these roles are ambiguous as various interpretations exist, leading to inefficiencies impacting product and business success. Sorting these ambiguities out will improve your product management practises and create better foundations for your organization to leverage product-led and agile principles successfully.

As adopting agile development practises and product-led organizations become increasingly common, the focus on the structures, ceremonies and roles that support the new operating models often act as guidance or rulebook to hold on to. Typical drivers for going agile and product-led are achieving higher speed of development, more frequent releases of value delivery and tangible improvements, reducing risk and enabling faster feedback loops with users. This trend is a response to the constantly increasing speed of change in customer demand. To stay relevant, companies need to offer products delivering real customer value faster. One of the most critical roles in both agile practises and product management is the Product Manager or Product Owner. 

Many have tried explaining the differences and ambiguities around the roles of the Product Manager and Product Owner. For example, if you are European, you tend to refer to the Product Owner role more than if you are American. The Product Manager role is also used in some frameworks and organizations as a more formal manager of staff or function, having less to do with product management. Regardless of the differences, the roles of Product Manager and Product Owner origin from the same family tree. 

The Product Manager role is traced back to the 1930s when the position was created as part of the marketing department. The role was supposed to incorporate the customer perspective into the development and production of the product. The Product Manager role mainly grew via two entrepreneurs adopting the position into their organization. You might recognize their names – Bill Hewlett and David Packard. They were standing behind the big IT-hardware company Hewlett-Packard.

The Product Owner, however, came as late as 1995 as a part of the largely adopted agile framework called Scrum. The creators of The Scrum Guide, Jeff Sutherland and Ken Schwaber, supported the overarching responsibility of a Product Manager but believed the Product Manager role tended to lean too much towards the commercialization perspective rather than the engineering or development side. Therefore, they introduced the Product Owner – a position with a technical focus and overarching responsibility for the product’s success.

In many organizations Ascend has worked with, we have experienced situations where both these roles exist in parallel. That was never the idea by any of the creators. Their point was to establish one role in bridging the gap between the development and commercialization of a product. Instead, by introducing both a Product Manager and a Product Owner, the roles tend to focus on separate sides and make the gap even more extensive. Our experiences show that in such setups, the Product Manager becomes too distant from the development team, and the Product Owner becomes too distant from the users and the market. This creates uncertainty around who is really overall responsible for the value delivered by the product in the end.

From a historical perspective, the roles are very much alike since they originally were intended to contribute with much of the same value. It is not the decision between a Product Manager or a Product Owner that will help you set the overarching responsibilities right – clarifying the responsibilities will.  

Although product responsibility, ranging from market insights to solution development by default, is often too overwhelming for one person to manage, the answer is not to divide it into one role focusing on commercialization and one on development. Instead, what we have experienced as a more successful way, is to narrow the focus and scope of product responsibility down to the product’s value and viability, as described by Marty Cagan. There is a difference between the statements “doing the right product” and “doing the product right”, where “the product responsible” is accountable for the first statement. The second statement consists of two parts: feasibility and usability. Feasibility is ensuring the product is working and is available to the users, and usability assures the users can interact with the product. We recommend appointing a lead engineer to be responsible for the feasibility and a product designer for the usability. Together with “the product responsible”, these form a trio (of engineering, design, and product management) that work closely together, taking the overarching responsibility for the whole product’s success over time. In the end, building a great product is a team effort! 

If you encounter misalignment and unclarity around the role of Product Manager and Product Owner, or where the responsibility of product success is split into commercialization and development, keep in mind that these are signs of a potential malfunctioning product-led or agile organization. If you find yourself discussing choosing between the role of a Product Manager or a Product Owner, do not spend too much time choosing one. Instead, focus on giving the role the right conditions by doing clear splits between the responsibilities for value, viability, feasibility, and usability. We recommend looking to and understanding your organizational needs and prerequisites rather than too rigorously following a particular framework. 

With this said, this insight only touched upon the role’s primary purpose as having the overarching responsibility for a product delivering value and being viable. However, there are many more relevant details to sort out to make this role successful, depending on the organization’s context, product type and other factors.

Get in contact with Ascend if you want to learn and discuss more!