The Mythical Product Owner

By Andre Kaminski
September 17, 2009

Product Managers must quickly adapt to the Agile methodology, or face becoming sidelined. It is critical to understand the relationship between traditional and new roles within a delivery organization, particularly between the Product Manager and the Product Owner.



Barbara Nelson said in The Politics of Agile, “When product managers weren’t looking, the developers went agile.” Indeed, many Product Managers were taken by surprise at the speed of Agile’s adoption. And with the introduction of a new Product Owner role and its perceived overlap with the traditional Product Manager function, Product Managers have expressed some anxiety about the future of their role.

Agile was borne from frustrated development teams who were constantly blamed for non-delivery and missed business goals. Nothing in life is black and white, and objectively speaking, problems could be found on both sides. Nevertheless, Agile was a response from tactical teams that wanted to control the rules of the game and redefine the criteria for success.

Since the Agile process was created by tactical teams, it concentrates on development practices. At times, Agile may seem inattentive to the environment in which projects are delivered, and to hold idealistic views of reality. However, Agile has many merits, and for organizations to be fully successful, the changes of Agile need to happen not only on the tactical level of delivery, but across the whole organization. It is not enough to have a fully functional and efficient development team that delivers, if it does not translate into success of the company. As product managers, we bear the responsibility for bridging the two worlds – technical and business, and need to influence both. Ultimately, we are responsible for the success of the product and, thus, the company. We cannot point fingers anymore and say, “It was the developers who did not deliver,” or, “It was the business unit that did not have a coherent strategy.” Although there may be some truth to these statements, the art of product management is to influence strategies and plans even if we do not have direct authority over them.

Change must happen on two levels across the organization:

  • Technical – Roles and responsibilities must be understood, accepted, and adopted.

  • Cultural – Attitudes, expectations, political ambitions, and how we collaborate must change.

Obviously, Agile should not be introduced with a ‘big-bang’ approach. Instead, by demonstrating that the new process works on a tactical level, and building confidence within the organization, we can show the way forward for the rest.

In this article I concentrate on the role of the Product Owner. This role is critical to the success of any initiative, and yet it is not widely understood. For tactical teams, the Product Owner represents the business, yet there is no clear definition of who that person should be. Articles or books by technical Agile authors almost always present the Product Owner as a jack of all trades—whatever information a team needs, the Product Owner delivers. Posts on the website of Scrum Alliance (the professional organization of Scrum practitioners) call for more training of Product Owners so they understand what it means to be ‘good’ Product Owners. Clearly they are not getting what they need from this role.

Since Scrum describes what this role should do, but does not say who specifically from the traditional world should play this role, Product Managers are put in an ambiguous position. According to Scrum, the Product Owner can be anybody – the Business Manager, an internal or external client, or the Product Manager—as long as this person is part of the team and can devote enough time to the role. The simplistic assumption is that the Product Owner contributes to the success of the company by performing whatever business-side functions are possible. This assumption may be true as long as this person sees the big picture, understands the market or client problems, sees the market opportunities and trends, and is able to quantify them. In other words, the expectation is that the Product Owner is, at least partly, also the Product Manager, regardless of title.

So there is overlap between what teams expect from the Product Owner and the traditional role of Product Manager, but is this the same person?

The Problem

The founders of Scrum did not explicitly call the ‘Product Owner’ the ‘Product Manager.’ If they had, the role of ‘Product Owner’ would have no ambiguity. I think one of the reasons for this oversight is that, as Product Managers, we failed to communicate the value that we bring to organizations. Only one side of product management has been seen by delivery teams – as the enforcers of deadlines and the police force of the business. In addition, the metrics currently used by business units to measure progress reinforce the perception by development that Product Managers are part of the problem rather than the solution. Agile is trying to break this ‘us vs. them’ dichotomy by integrating the business unit with development.

Over the last 50 years, the software industry has undergone a full evolution of roles. Initially, a developer was an architect, analyst, project manager, coder and tester. Over time, software became more complex, technologies changed, markets grew, and development teams became larger. As a result, specializations in roles developed. Product Managers became specialists in understanding markets, Project Managers in delivery of projects, Business Analysts in solidifying requirements, and so on. Roles became even more fragmented when specific skills were recognized, as for example defined by Pragmatic Marketing - Product Managers could then be Product Strategy Champions, Technical Product Managers, or Marketing Product Managers. Similar splits happened with other roles; for example, now we have either Business or Technical Project Managers.
Some of these roles have endured and are clearly defined. But new methodologies, such as Scrum, have called the boundaries and definitions of other roles into question. For sure, Scrum has raised issues in mapping traditional Product and Project Manager responsibilities into Product Owner and Scrum Master functions.

Let’s have a brief look at the expectations of two roles – Product Owner and Scrum Master.

The Product Owner is responsible for:

  • Representing the voice of the customer.
  • Understanding and delivering on ROI.
  • Managing business stakeholders.
  • Maintaining constant communication with the team.
  • Making rapid tactical development decisions if they impact functionality or usability.
  • Participating in technical release planning.
  • Writing user stories and scenarios.
  • Maintaining product backlog.
  • Helping the team to estimate development time for each scenario.
  • Participating in Sprint review meetings and providing feedback to the team.
  • Monitoring progress and making constant adjustments based on larger strategic objectives.
Page 1 / 2

About the Authors

  • Andre Kaminski is Executive Manager and Consultant at Redpoint Management Services – specializing in restoring projects and products that are missing their targets. Andre has over 25 years of experience in IT/IS, working with both large and small companies, and with multinational, geographically dispersed teams. Andre Kaminski is Executive Manager and Consultant at Redpoint Management Services – specializing in restoring projects and products that are missing their targets. Andre has over 25 years of experience in IT/IS, working with both large and small companies, and with multinational, geographically dispersed teams. Andre holds titles of Pragmatic Marketing Certified Product Manager, PMI Project Management Professional and Scrum Alliance Scrum Master. Email Andre at

Categories:  Agile Working with Development

Post a Comment


Allowed HTML: <b>, <i>, <u>