Dissecting the Product Owner role


Like Coach and Scrum Master the Product Owner is a new term for a new role. While Coach and Scrum Master are completely new roles added by Agile methods the Product Owner is an extension of an existing role. Or rather, it is an extension to two existing roles.

The role of Product Owner was introduced by Scrum. Teams following XP prefer to talk about a Customer. What ever the role is called it is concerned with: deciding what should be in the next iteration, prioritising work, providing guidance on what is being built and ensuring value is created.

Consider Scrum as a theatre play. We see the actors on stage: the Scrum Master facilitating meetings, removing obstacles and so. The development team committing, reporting and generally getting on with creating the product. When on the stage the Product Owner role is well defined: populating the Sprint, managing the product backlog, prioritising and such. But Scrum has little to say about what the Product Owner does when they are offstage.


Product Owners spend most of their time offstage. It is here that they learn what is needed, they learn the stories behind the items in the backlogs and offstage is were they perform their evaluations and trade-offs so when they walk on stage they are prepared to manage the backlogs.

Scrum is right to stay silent on how the Product Owner does their work. If Scrum detailed this activity it would be a bigger, more prescriptive process; it would be more complicated to adopt and more time consuming to learn.

(Similarly Scrum is silent on how Developers do their work: it does not mandate Test Driven Development, Refactoring or any of the other common technical practices. However, most of developers have seen the XP play which puts all development activity centre stage.)

To understand the Product Owner role we need to look at their offstage work.


The Product Manager and the BA


The Product Owner role is seldom filled by an actual customer. The Product Owner rarely puts their own money on the line to pay for the end product. Instead they fill a proxy-customer role. Their job is to understand what is needed from the software and translate that into work that needs doing.

Typically offstage Product Owners are Product Managers or Business Analysts (BAs). Although these are very different roles both work as Product Owner when on the Scrum stage. Whether the organization employs Product Managers or BAs depends on the type of end customer and product the company sells.

In independent software vendor (ISV) the software is the product. Here the Product Owner role is taken by a Product Manager. They talk to customers about their needs, watch the competition, determine product strategy and final decide what is needed in the product. Ultimately the Product Manager wants to know what will help the software sell.

Inside corporate IT departments – and companies who provide IT services to corporates – the Product Owner is played by a Business Analyst. While Product Managers look outside the company to determine need the BA looks inside the company.

When the company does not sell technology in its own right then IT is used to support the activities and products of the company. So BAs look inside the company to discover what is needed to improve operations, save money, open new markets and change operations.

At one extreme the BA role is to capture and document requirements; at the other extreme the role is an internal consultant tasked with understanding a company and finding ways to improve through technology.

Understanding these difference is key to successfully filling the Product Owner role. The single label obscures these differences. Whether the role is called BA, Product Manager or Product Owner the end result is the same: they determine what software needs to do. In order to do this both roles demand analysis skills, however what they analyse and how they do the analysis can be quite different.

Yet the difference between these roles is narrowing as more businesses embrace the web the two roles need to learn from one another. Once upon a time a BA only looked at internal



About the author

Allan Kelly's picture Allan Kelly

Allan Kelly has held just about every job in the software world, from system admin to development manager by way of programmer and product manager.  Today he works helping teams adopt and deepen Agile practices, and writing far too much.  He specialises in working with software product companies and aligning products and processes with company strategy.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!