... Scrum team members need a single, well formed, sequenced list of Product Backlog Items as this provides focus for delivering value. Without this list the team may generate features that will never or rarely be used (but need to be maintained), deliver features at the wrong time (suboptimizing revenue) or deliver nothing. The Scrum Team needs the backlog in a timely manner to support and maximize the team’s velocity; this timeliness cannot be achieved by a committee.

✥      ✥      ✥

One person needs to be responsible for the Product Backlog. This person needs deep domain knowledge, business insight, understanding of product technology, technical dependencies, and the authority to force rank the backlog to maximize business value.

Too many organizations try to put several people or groups in charge of charting product rollout. Staff members from multiple departments are brought together to bring their expertise to the endeavor. This is a good idea as having many perspectives can give greater insight into what is required to get the product to the consumer. These groups usually lack the individual authority to make decisions and require “sponsorship” with another group being the arbiter of the important decisions for the product. In this situation the decisions are further away from the work on the product and the people doing the work, which can be demotivating for the staff working the product when they are not part of this process. Of course decisions made via this approach will always take a significant amount of time to go through the process slowing product delivery.

Too many organizations try to put several bosses in charge of charting product rollout. Sometimes they can't even agree what the product is. While it takes up a staff position, and therefore a cost, a good product owner will increase a product revenue stream or product value delivered by at least 20% in the first year. Without someone to explicitly lead product development, it's almost impossible to make this work without a single focal point.

Hiring a project manager to oversee the day to day working of a team developing a new product is a common approach. This is usually done because other people within the organization are too busy with their normal job to be part of the product work full time. Though this is very common, almost ubiquitous, the approach creates significant dysfunctions for product delivery. First, it is a product being developed and not a project being carried out. When project development completes, the product is still in the field and questions of maintenance and additional feature development find only awkward answers. Organisationally separating product creation from ongoing development ("maintenance") creates many problems. Secondly, the project manager is rarely given responsibility for return on investment, so their incentive is to deliver as fast as possible within the financial constraints. Without this responsibility the project manager is more likely to make short-term decisions with long-term consequences.

You can maximize revenue by continuously using your users as beta sites (where the deliverables are the beta deliveries) but customers can be made much more comfortable if a person on the vendor side takes responsibility for up-front planning and thinking. Lean says that it is important to line up the decisions early on, so that the decisions are easy to make once the time comes to make them.

Therefore:

Get a Product Owner to order the Product Backlog and to take responsibility for the vision of the product, and for the value that emanates from the delivery of that vision.

✥      ✥      ✥

The Product Owner becomes the single point of contact for issues related to product content, delivery, and scheduling. The Product Owner now has final control over the rollout of the product that he or she owns, and will be held accountable for the resulting ROI.

The best Product Owner is as close to value delivery as possible. There are multiple stakeholders — the end user, the organization deriving revenue from end user use of the product, persons concerned with regulatory authorities, legal issues, or standards bodies, etc. Often stakeholders cannot be Product Owners because they have limited knowledge, a conflict of interest, or lack of authority to make decisions. One of the Product Owner's primary measures of success is value generation from the product — the business plan.

There is no Customer in Scrum. The Customer role is present in many real-world value streams. Scrum tends to reflect the Lean vision of partnership between the business and end user, rather than a relationship of animosity or of at-arms-length or over-the-wall communication. Customers can contribute paths to market, but the enterprise should be mindful that they are an additional handoff that can introduce delay and waste. These often are impediments to be removed. In Scrum the Product Owner manages all business relationships external to the team, eliminating the handoff between the business vision and the development effort.

The Scrum team needs to tune into the Product Owner and ignore other voices within the organization so that the team can stay focused. The Development Team should refer to the Product Owner in case others want to change the priority of work. The ScrumMaster should help in these cases to protect the Development Team from interruptions.

The Product Backlog documents the decisions around all the conversations of how to achieve the Product Owner's Vision. Ideally it reflects a consensus view (particularly with respect to the Development Team's perspective) but the Product Owner has the final word on its content and ordering. Each team needs one Product Owner to deliver the Scrum Team one backlog. If multiple teams are developing a single product together, there should be one Product Backlog for multiple teams to pull from.

We bring together a team of people who are really passionate about [a] subject.. If you write a 70-page document that says this is the product you're supposed to build, you actually push the creativity out with process. The engineer who says, you know what, there's a feature here that you forgot that I would really like to add. You don't want to push that creativity out of the product.

The consensus-driven approach where the team works together to build a vision around what they're building and still leaves enough room for each member of the team to participate creatively, is really inspiring and yields us some of the best outcomes we've had.

— Marissa Mayer, VP Google, in BusinessWeek.com, June 30, 2006

If the creation of the Product Backlog takes too much time or expertise that one person can provide, the Product Owner should form a Product Owner Team that works with him or her as Chief Product Owner, retaining the final say over the sequencing of the Product Backlog.

Anyone can offer anything as content for the Product Backlog. The contributor owns the item in as much that they must provide support for fully forming the Product Backlog Item. The Product Owner Team sequences that item in the global Product Backlog — again, with the Product Owner having final say over the sequencing.

The Product Owner is also responsible for the Product Roadmap and the Release Plan.

It is often difficult to find a Product Owner. The domain knowledge may reside in a business expert (sometimes the CEO) who does not have enough time to fully form the Product Backlog. The domain expert may become a Chief Product Owner or, in an extreme situation, you may need to find a Surrogate Product Owner.