Agile - page 7

How many of you have heard a Product Owner being described as a single-wring-able-neck, or read that the Product Owner is solely responsible for the “Return On Investment” of a product or project? Are you aware that the Product Owner is responsible to work with stakeholders to define the product or project, and they are also required to be available to the team to answer questions, give feedback, and accept the deliverables produced by the team? If you are doing Scrum, you’ve likely heard all of this.

As defined by ScrumAlliance.org, the role of Product Owner is responsible for the business value of the project. To take this a step further, Roman Pichlar inked a solid blog called Being an Effective Product Owner. In this blog, he better explains the expectations and or responsibilities of an effective Product Owner including close collaboration with team to guide and direct the team, active management of the backlog (ranking, grooming, etc.), proactively manages stakeholders [expectations], has a thorough understanding of customer needs, and has some knowledge as to how good software is developed. These responsibilities closely resemble the four aspects that Robert Galen outlines in his book, Scrum Product Ownership — Balancing Value from the Inside Out. These four aspects include part Product Manager, part Project Manager, part Leader, and part Business Analyst.

As pointed out by many in the Product Management space, the role of Product Owner is fairly broad and, although many folks like Roman and Robert have done a good job helping to better define the Product Owner, the role itself is often viewed as ambiguous. Let’s face it, in order to be a good Product Owner you are asked to know your customer, have an in-depth knowledge of how the product or project should satisfy the needs of the product, you must represent the product to both internal and external stakeholders, price and support the product/project to ensure profitability, define requirements, answer questions to the team, be a part of elaboration and planning discussions, facilitate discussions between customers and developers, work with industry analysts, plan and schedule, define what is the most important thing, … ok this is getting ridiculous. This is a lot to ask of any one person.

In years past, when organizations made the transition to Agile (specifically Scrum), the Product Owner role typically defaulted to the Product Manager or the Director responsible for a specific service area (e.g. Customer Service Director). This often meant that in addition to your current job, we are going to ask you to make yourself more available to the development team that is building your product or project. In some cases, this worked out fine — but in most, you’ll see that either the stakeholders are not happy or the development team is not happy. This is simply because there is not enough time in the day, not to mention the expectations and requirements are so broad.

Today, it is common place to see the Product Manager or Director be paired up with a Product Owner. The Product Owner role is given to a Business Analyst or Project Manager that has strong subject matter expertise. In some cases, you’ll see titles stay the same and in others, team members actually given the title of Product Owner. These two (maybe more) team members pair up to become the Product Ownership Team. The Product Manager works the external stakeholder needs while the tactical Product Owner works the internal stakeholder needs — specifically working closely with the delivery team. Arlen Bankston of Lithespeed talks about the roles of Strategic Product Owner and Tactical Product Owner in this blog.

The Product Ownership Team approach helps reduce the time burdens and constraints, while still fulfilling the need of having a role focus on business value. The advantages of this approach are:

• More brainpower up front to help understand customer needs and align to solutions,
• Time afforded to thoroughly understand the marketplace,
• Capacity to satisfy the “on-demand” need to work with the team, and
• The ability to avoid unnecessary waste due to bottlenecks that result from a poorly maintained backlog.

The possible pitfalls to look out for with this approach are:

• When the tactical Product Owner is not empowered to make decisions — you will likely end up conversations being conducted through heavy documentation and sign-off processes,
• A proxy-type relationship that can keep the delivery team from making a connection with the end-customer,
• The lack of clear vision since the tactical Product Owner my be too far down in the weeds and not able to clearly articulate the big picture, and
• Without the Product Manager (or Strategic Product Owner) interacting frequently with the team members — trust and a positive rapport does not develop between the business and the delivery team. This can lead to poor morale and underperforming teams and products.

What approach does your organization employ? Do you have a single Product Owner? Or, is Product Ownership comprised of a Team? If it is a team, are there multiple players or just two?