Get certified - Transform your world of work today


Being an Effective Product Owner

23 April 2007

Roman Pichler
Pichler Consulting Limited

When I met Paul, a first-time product owner on a new project, the first thing he asked me was, “What do I really have to do and how much time will it require?” Even though Paul had attended a Scrum introduction a few weeks back, he wanted to double check his responsibilities. He was worried about the time commitment he had to make and the support he would get from his boss.

Helping product owners like Paul getting started is rather the norm for me. In most organizations that I have worked with, product owners are strapped for time, are often not aware of their responsibilities, and are unsure how they should best transition into their new role. Sadly, I have also met many product owners on Scrum projects who resembled more a business sponsor briefly stopping by at the sprint planning and review meeting or an on-site customer interacting more frequently with the team but leaving it to the ScrumMaster to guide the team.

So what is the product owner in Scrum supposed to do? The product owner is required to closely collaborate with the team on an ongoing basis and to guide and direct the team (e.g., by actively managing the product backlog, answering questions when they arise, providing feedback, and signing off work results.) In simple terms, the product owner sits in the driver’s seat, deciding what should be done and when the software should be shipped. The team decides how much work they can take on in a sprint and how the work is carried out. I have experienced that having a strong, empowered, and present product owner is a key success factor for Scrum projects – just like a strong, empowered team is. Most projects I have come across that had product owners who were not properly available or empowered suffered, and the projects never reached their maximum velocity.

I have found three things particularly helpful for product owners: a thorough understanding of the customer needs, an active stakeholder management, and a basic knowledge of how software is developed and deployed.

Thoroughly understanding the customer needs and how the product will satisfy those needs allows the product owner to describe, prioritizes, and communicate the requirements that really matter and answer all related questions. The product owner should express what value-added is from a customer perspectives and focus the development efforts toward providing that value.

Proactive stakeholder management is particularly important in larger organizations, where the stakeholders include not only customers but also internal functions, such as production support, service or sales, as well. Taking into account and prioritizing the various interests early on and involving stakeholders regularly, for instance in form of user story writing workshops and sprint reviews, is crucial to ensuring that the software can successfully work in its target environment.

Knowing (at least roughly) how good software is developed makes it easier for the product owner to closely communicate with the team. This kind of knowledge helps product owners to better understand how the team works and how important quality and the related agile technical practices are to sustain a high velocity across releases.

This broad skill set implies that ideally, the product owner would be a hybrid: someone who is able to look outward, understanding the end customer needs, and someone who looks inward, managing the value stream that transforms the customer needs into software ready to be used by the customer. Toyota’s Chief Engineer role very much resembles such a hybrid product owner: The Chief Engineer gathers end user requirements, manages the development project, and even makes high-level design decisions. Additionally, the Chief Engineer is a high profile role and has executive support. Does this sound too good to be true? Not so: Toyota has successfully employed the role since the 1950s.

So what did I tell new product owner Paul? Well, I took him through the key activities a product owner has to perform on a Scrum project, from hosting estimation workshops and prepping for the sprint planning meeting to giving feedback to the team and accepting or rejecting work results in the sprint review meeting. I recommended that he free up most of his schedule and defer most of his other commitments to have enough time available. We scheduled the first user story writing workshop with the team and stakeholders, and we set up the first effort estimation workshop. I also volunteered to talk to his manager about Scrum and to explain why it is so important for a product owner to spend enough time with the team every day and to be able to make decisions on the spot.

Being an effective product owner is not easy – nor is being a good ScrumMaster. To get started, be aware of the core responsibilities the product owner has and make sure that the product owner firmly sits in the driver’s seat – all the time.

Read on:

James M. Morgan, Jeffrey K. Liker. The Toyota Product Development System: Integrating People, Process And Technology. Productivity Press. 2006

Ken Schwaber. Agile Project Management with Scrum. Microsoft Press. 2004

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4.4 (8 ratings)


Anonymous, 4/23/2007 1:55:28 PM
I think you provide some great insight in this article. I've seen many Product Owners acting more as far-removed project managers. Good stuff.
David Doughty, CSM, 6/1/2007 2:17:23 PM
Very easy quick read for new Product Owners to improve their skills. Thanks, I've sent it to my Product Owners and their bosses to read.
Rune Mai, CSM, 11/19/2007 1:33:04 PM
Good article. One comment though: To me it seems like you are ending up describing the product owners role as something of a cross-breed of scrum master and product owner, which I do not find valuable. "The Chief Engineer gathers end user requirements, manages the development project, and even makes high-level design decisions. Additionally, the Chief Engineer is a high profile role and has executive support. Does this sound too good to be true? Not so: Toyota has successfully employed the role since the 1950s" <-- he is a chief engineer, product owners are normally not. I think it is very important to distinquish between business and engineering, and that is also why the product owner role was created in the first place as I see it. Product owners do direct development effort, but do participate in development execution and planning. This is very important to me (and many others). I am a scrum master on a team where we include our product owner in our daily scrums, but many people actually find this disturbing, because once the team has started working on what is most important to the product owner, he should only be involved to the degree where he answers questions related to his backlog items. Why do i find this important? In order to be truly effiecient you need the team to selforganize and thus have engineering planning and strategies emerge through that organization, and this is something very fragile and not very documented in scrum practises (you have to look elsewhere for this..). It is difficult to nuture this selfemergent behaviour if the team is not completely on their own... (in my opinion at least).

Product owners do requirement administration, release planning (selected backlog for sprints) and HAS to have a deep understanding of the ever changing needs of the customers, if they start doing something else, they do too much and loose focus...
Jim Lile, CSM, 12/2/2009 1:24:23 PM
thanks good stuff as I'm about to interview for another Product Owner role, thanks!
Roman Pichler, CST,CSP,CSM,CSPO, 12/8/2009 4:59:11 AM
Hi Rune,

Thanks for your feedback. As you rightly point out, the product owner has some responsibilities that differ from the team's. But the product owner is part of the Scrum team, and developing a successful product is a team effort in Scrum. You can find out more in my new book "Agile Product Management with Scrum," where I describe the product owner role in much more detail. I agree with your comment on the chief engineer example. In hindsight, I would have done without it.

Armond Mehrabian, CSM, 9/18/2012 3:53:07 PM
I'm a little confused by your response to Paul. You said, "I recommended that he free up most of his schedule and defer most of his other commitments to have enough time available." I don't mean to sound rude (honestly) but this sounds too much like telling someone that can't afford a car they want to "get some money so you can afford the car you want." Paul's time is a limited resource and his responsibilities are fixed. The situation gets further exasperated with more Scrum teams added the mix.

What are your thoughts on bifurcating the roles of a Product Manager (customer facing, stake holder management) from the Product Owner (team facing, user story grooming). The Product Manager is more strategic and comes up with the customer facing features and the Product Owner is fully focused on meeting the team's needs for creating all the user stories for the feature and continuously grooms the stories in collaboration with the team. This way it's possible to have a Product Owner dedicated to each team while the Product Manager is focused on the larger feature and the stake holders. This advice, by the way, is given by Dean Leffingwell - author of "Agile Software Requirements" and the Scaled Agile Framework.

Roman Pichler, CST,CSP,CSM,CSPO, 9/19/2012 3:01:26 AM
Hi Armond, I view the product owner as the agile product manager. You can find out more about my thoughts on the product owner role and agile product ownership here:
Casey Gordon, CSM, 11/10/2012 6:25:38 AM
Great article, added clarity to a discussion that I was having with one of my product owners. Thanks for sharing.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up