Agile & Scrum Training Courses | Collaborative Leadership Team

View Original

The Most Difficult Role in Scrum: The Product Owner


One of the most common observations, Angela Johnson, Certified Scrum Professional and Agile Coach in Minneapolis, MN receives when coaching or training clients on Scrum is, “Wow! The Product Owner Role is really hard!”  While this reaction is typical, there are a number of simple things a Product Owner can do to make their job easier.  The purpose of this blog is to outline a few of these items.

Obtain and Communicate Product Vision: The Product Owner is responsible for working with the stakeholders of the product as well as those sponsoring the product development effort to craft and communicate the product vision.  While the Scrum Framework does not specify how the Product Owner completes this task, it is vital they do so.  A Product Vision answers the question, “Why are we undertaking this effort?”  Moreover, a well-crafted and communicated vision becomes a decision-making tool for both the Product Owner and the Development Team.  As requests for new product features are made by stakeholders, a Product Owner can compare them to the Product Vision and, depending on their alignment (or lack thereof) with the Vision, order them appropriately within the Product Backlog.

Know Thy User:  While new Product Owners can become fixated on spending time with the Development Team, maintaining the Product Backlog, etc. they need to remain connected to the users and other stakeholders they represent in the development process.   While working with the Development Team is crucial to the creation of a successful product, becoming disconnected from the users of a product can lead to features that won’t be used.  Schedule time to observe users in their native environments – whether that be a warehouse, the cab of a truck, an operating suite or an office setting – seeing and interacting with users will allow a Product Owner to truly represent the users and their needs to the Development Team.

Ensure you are Empowered:  The Product Owner is a leadership role and, as such, needs to be empowered to make decisions both the Development Team and stakeholders respect and follow.  While “Empowerment” is a term thrown around with great frequency, many struggle to define it.  It means two things – 1.) Not Having to Ask for Permission and 2.) Never having to say you’re sorry.  Having a conversation at the start of the development process regarding “empowerment” and its meaning within the context of the process will help make future conversations regarding features, their order within the Product Backlog, etc. easier.

Trust the Team: The responsibility a Product Owner has for the success of the product can be overwhelming.  One of the best ways for a Product Owner to avoid feeling overwhelmed is to trust the Development Team.  I am not advocating “blind” trust – the Product Owner should question the value of the Team’s suggestions when appropriate.  However, most of the Development Teams I encounter are skilled craftspeople who want to build a product that not only meets the stated needs of users today, but delights them both today and in the future.  Moreover, these Teams possess knowledge about the domain the product they are building will operate in and, as such, can provide advice and counsel to the Product Owner as he or she makes decisions.

Focus on the “What”: A key aspect of this trust is ensuring the Development Team is allowed to focus on how the product will be built, while the Product Owner remains focused on what will be built.  This challenge is a leftover from traditional ways of working where the Development Team would simply do exactly what the requirements document stated, no more, no less.   This behavior, in turn, caused business people to specify not only what they wanted built (e.g. I need to submit an order so that it can be processed), but also how it should be built (e.g. the order submission button should be blue).  A strong Product Owner will not succumb to this behavior and, instead, will focus on the “what” knowing the Team will surprise and delight them with how the product is being built.

Want to learn more?

Click here to view our upcoming classes and register for our next CSM or CSPO course.