...while everyone holds their own broad notion of the Vision and of possible good outcomes, the community seeks a leader around whom they can rally their passion and enthusiasm.

✥      ✥      ✥

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.

Scrum Team members need a single, well-formed, sequenced list of Product Backlog Items to help focus on delivering value. Without this list, the team may generate features that the market will never or rarely use (though the team still bears the effort to maintain them). They may 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; a committee cannot achieve this timeliness. Committees are also likely to encapsulate compromise and to come to somewhat incoherent conclusions.

Too many organizations put several people or groups in charge of charting product rollout, with staff members from multiple departments all bringing their perspective to the product rollout planning process. This is a good idea to the extent that multiple perspectives broaden insight into how to most effectively deliver the product to the consumer. However, these committees too often represent internal corporate functions, disconnected from market concerns where the real value lies. Further, these groups often lack authority to make decisions and need “sponsorship,” with yet another group being the arbiter of the important decisions for the product. The decisions are further away from both the work on the product and the people doing the work, which can be de-motivating for the developers when they are not part of this process (or even when they are). Discussions often degrade into political considerations and competitions to retain control or to increase benefits for a given constituency, rather than benefit those at the end of the Value Streams. These negotiations slow the process, delay product delivery, reduce quality and erode the coherence of the backlog.

Some organizations put rollout planning in the hands of a committee of bosses or managers. Sometimes they can’t even agree to what the product is. It’s almost impossible to make this work without a single focal point. You need someone to explicitly lead product development.

One common approach is to hire a project manager to oversee the team’s day-to-day work. The project manager does the work that management may feel is too important to ignore but not important enough to distract from their own pressing agendas. Though this is very common—almost ubiquitous—the approach in fact slows product delivery and may reduce quality and profitability. First, the organization is building a product rather than carrying out a project. When project development completes, the product is still in the field and questions of maintenance and added feature development find only awkward answers. Organizationally separating product creation from ongoing development (“maintenance”) creates many problems. Secondly, the company rarely gives the project manager responsibility for value such as ROI or net present value (see Value and ROI), so his or her 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, and short-term decisions tend not to have positive long-term consequences.

You can maximize revenue by continuously engaging your users as beta sites to refine the product (where the deliverables are the beta deliveries), but customers are much more comfortable if a person on the vendor side instead 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 take responsibility for the vision of the product, and for the value that emanates from the delivery of that vision.

✥      ✥      ✥

Product Owners own their products: they have the final say over product content and delivery ordering. The Product Owner role is not just to “manage” the product; it’s that, too, but more so, the product is their baby, their passion. True Product Owners are driven by Product Pride.

The Product Owner becomes the single point of contact for issues related to product content, delivery, and scheduling. The Product Owner has final control over the rollout of the product that he or she owns, and is accountable for the resulting ROI. While this role takes up a staff position, and therefore a cost, a good Product Owner can dramatically grow a product revenue stream and increase delivered value.

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; and potentially many others. Stakeholders often 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; see Development Partnership. Customers can realize paths to market, but the enterprise should be mindful that customers are an added handoff that can introduce delay and waste. These often are impediments for the Product Owner to remove. In Scrum, the Product Owner represents the interests of all stakeholders, including customers (see Surrogate Customer). The Product Owner manages all business relationships external to the team, which eliminates handoffs 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 those with a wish to redirect or re-prioritize the team‘s work to the Product Owner. 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 Scrum Team needs one Product Owner to develop one Product Backlog for its Development Teams. If multiple teams are developing a single product together, there should be a single Product Backlog that drives these teams’ work.

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. [1]

If the creation of the Product Backlog takes too much time or more 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.

Great Product Owners have a sound user experience (UX) skill set or at least can tap into such expertise on the Product Owner Team. Gentle persuasion, care, and attentiveness on the part of team members with UX skills can lead a Product Owner to pick up many of these skills over time.

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

It is often difficult to fill the Product Owner position. The business passion and knowledge may exist in a business expert (sometimes the CEO) who does not have enough time to fully manage the Product Backlog, especially in small or young development organizations. Any Development Team member may take on any Product Owner work in consultation with the existing Product Owner, or can temporarily fill the Product Owner role in his or her absence. The Development Team and ScrumMaster should ensure that such a situation does not persist indefinitely.

[1] Marissa Mayer. “Inside Google’s New-Product Process.ˮ BusinessWeek.com, http://www.businessweek.com/technology/content/jun2006/tc20060629_411177.htm, 30 June 2006 (accessed 23 June 2010).

Picture credits: Henry Ford Hitting Soybean Plastic Trunk with an Axe, The Collections of The Henry Ford. Gift of Ford Motor Company, 02 November 1940, image-id: P.188.28273, https://www.thehenryford.org/collections-and-research/digital-collections/artifact/220805#slide=gs-223214. (used with permission)