...the Product Owner wants to improve the effectiveness of the Value Stream.

A single Product Owner is accountable for all value such as return on investment and should handle market analysis, product discovery, stakeholder management, customer feedback, and most other market-facing work, while also enabling the team to build the right thing.

✥       ✥       ✥ 

The Product Owner has more to do than a single person can handle well (see, for example, [1]).

The Product Owner may ask the Development Team for help, but that would only shift the burden to the developers. It would also take away capacity from actual development. There is no incentive for the Product Owner to improve and learn how to become a better Product Owner.

Not getting the Product Backlog Items Ready (see Definition of Ready) may result in the Development Team building the wrong things. It will also increase communication with the Product Owner, which slows the Development Team down.

Development Teams that do not have enough Product Backlog Items waste capacity. If the team doesn’t receive enough Enabling Specifications for the market window targeted by the upcoming Sprint, it invites the Development Team to work on lower value Product Backlog Items or start working on Product Backlog Items that are not Ready. By adding delay, it might decrease the overall value that the team might otherwise produce.

Having enough time to reflect on Product Backlog Items helps to understand their relative value, identify dependencies, and gives possibility to capitalize on market opportunities.

One way to help a Product Owner to perform many tasks is by hiring a team of specialists. However, this leads to problems of handoff and communication. This can result in reduced understanding of customer problems and inadequate solutions.

The developers can help by clarifying details with other stakeholders as long as it does not contradict the Product Owner’s direction. It is important to maintain the single point of accountability for success and failure: the Product Owner should not be a committee.

Therefore:

Create a Product Owner Team, led by the Chief Product Owner, whose members together carry out product ownership.

A Product Owner Team gathers several people responsible for guiding the teams in creating the Product Backlog. When creating a Product Owner Team, it is important that there be a Chief Product Owner (CPO) who has final authority over the ordering of the Product Backlog. The CPO plus the other people that support the CPO is what we call the Product Owner Team. Some may call the Product Owner Team members the 'Product Owners'—but these people do not own anything. The CPO is the single Product Owner and the “single wringable neck” accountable for the success of the product.

The CPO clearly communicates the strategy and the Product Backlog Items. The CPO works with the Product Owner Team members to select and order backlog items for the teams. The Product Owner Team members can help the CPO work with the Development Teams to break the backlog into small Product Backlog Items for execution.

Experience suggests that the Product Owner Team should be a Collocated Team. Splitting the Product Owner function across organizational boundaries (particularly across corporate boundaries) may make things worse than just having a single Product Owner on one side or the other.

✥       ✥       ✥ 

The Product Owner Team carries out the product ownership for large products.

The Product Owner Team realizes the Vision by ordering the Product Backlog Items through a single Product Backlog.

Most Product Owner Team members come from a business background. However, product ownership means more than owning just the Value Streams. The Product Owner Team also produces Enabling Specifications for the Development Team (often in collaboration with the Development Team as they work together toward a Refined Product Backlog), which sometimes requires research into user-experience issues as well as low-level technologies and development approaches that are key to the product strategy. The Product Owner Team may explore these areas through Set-Based Designs to support an Enabling Specification for the Development Team.

Like the Product Owner, the entire Product Owner Team should be energized by an attitude of Product Pride.

[1] Angela Martin, Robert Biddle, and James Noble. “The XP Customer Role in Practice: Three Studies.” In Proceedings of the Agile Development Conference (ADC’04). Washington, D.C.: IEEE Computer Society, 2004, pp. 42-54.

Picture credits: Image Provided by PresenterMedia.com.