Product Owner

The Product Owner role in LeSS is conceptually the same as in one-team Scrum. However, at scale the focus changes slightly toward keeping an overview and ensuring the maximum return on investment (ROI) in the product.

Scaled Product Owner

It’s common in large-scale product development for different people to pull in different directions and for subgroups to focus on local sub-optimizations. Maintaining one Product Owner with one Product Backlog supports whole-product focus.

In traditional large-scale product groups, there’s a group (often product managers) that focuses outward and a group (usually developers) that focuses inward — and never the twain shall meet. In LeSS, the one Product Owner has lots of free time to focus outward on customers and their priorities while also being able to spend some time looking inwards to the teams. She acts as a connector, bringing teams and customers/users together so the teams become more customer focused.

In contrast with other scaled Scrum approaches, it’s possible in LeSS to effectively scale the Product Owner role with just one person because there are fewer roles and positions, and less complexity.

Prioritization over Clarification

There are two key information flows in Scrum related to the Product Owner: (1) prioritizing (ordering) items in the Product Backlog and (2) clarifying items in the Product Backlog. In the first flow (prioritization), information related to profit drivers, strategic customers, business risks, and other business concerns is sought and analyzed. In the second flow (clarification), information is sought to detail the behavior and qualities of items, the user experience, and other feature design concerns.

A LeSS Product Owner focuses on thinking hard about prioritization but collaborates with the teams on clarification. Further, she encourages and helps the teams enter into a direct conversation with true users and customers for clarification. She acts as a connector, not an intermediary.

Why emphasize direct interaction between teams and customers/users? Reasons include: (1) avoiding information loss from handoffs, (2) fostering co-creation of solutions to real customer problems, and (3) improving motivation and empathy for customers by having developers collaborate with them directly.

It’s worth noting that when the teams do most of the clarification work the Product Owner has more time and energy to focus on the big picture, continuously prioritizing and exploring new and strategic opportunities.

Find a Product Owner Given Your Type of Development

Step 1: Know Your Development Type

Finding the right Product Owner depends on knowing the type of development you are doing:

• Product development—For external customers or a market.
• Internal (product) development—For one or more users within the company. The development group is usually called IT or Systems Development.
• Project development—Usually for one external customer. The work is organized and contracted as a project of some kind although that does not necessarily mean a fixed scope/date/cost project contract. The development company is usually an outsourcer or systems-integrator. The customer, or client company, includes both the purchasing entity and the users, who are not always in the same department.

Step 2: Finding the right Product Owner

Product development—The company will have either (1) a business unit driving the product initiative (e.g., Retail Banking), or (2) a Product Management department driving the initiative. Traditional Product Management is responsible for customer and competitor analysis, product vision, coarse-grained feature selection and prioritization, product roadmap, and other non-technical activities. They don’t manage the work of a traditional development group.

Where to find a Product Owner for a group adopting LeSS? If there’s a Product Management department, then a Product Manager can be a good choice. Otherwise, look for a person from the business unit that’s driving the initiative. The important thing to keep in mind is that the Product Owner for product development should come from the business side.

Internal (product) development—A good Product Owner for internal product development in LeSS is (1) from within the group that will use the system, and (2) is closely involved in and deeply experienced in doing the real work that the system will support. They are very close to the real users.

Project development—The key point is that a Product Owner is from the company receiving the system and, as with internal development, is involved in and deeply experienced in the hands-on work, close to users.

A common variant for both internal and project development is when the system will be used by many departments. Then, a good choice is an experienced, hands-on individual from one of the major user departments who is interested in taking on the role and has political savvy.

The following figure shows the Product Owner in different organizations:

In all cases, a great Product Owner has a passion for the product.

When it is impossible to find the right Product Owner immediately, you can quickly start a LeSS adoption with a temporary Product Owner who understands what’s going on and can perform the mechanics of the role but is not from the business side. Let the teams complete several Sprints under the temporary Product Owner until the major kinks are worked out and — this is important — the development teams can deliver a truly ‘done’, shippable increment (or something close) every Sprint. Why? The product teams will be more likely to find and inspire the right longterm Product Owner if they can show a compelling new capability that offers very tangible business benefit. It’s terribly important that everyone understand that the temporary Product Owner is a placeholder. We often use the term “fake Product Owner” to indicate just how damaging this temporary Product Owner can be. Because the fake PO is not only not the best Product Owner but also she can cause damage trying to fill a role for which she is not qualified. She must be replaced as soon as possible to avoid the risk of creating a second-class product.

Step 3: Give Authority and Responsibility to a Real Product Owner

Product Owner is not a new name for a traditional project manager who delivers a scope and date contract of work. Rather, a Product Owner must have the independent authority to choose and change content, release dates, priorities, vision, etc. Of course she collaborates with stakeholders, but a real Product Owner has final decision-making authority.

Five Relationships

The Product Owner needs to understand and work to improve five key relationships that are affected by LeSS adoption:

• Product Owner<–>Teams
  The teams are there to help the Product Owner create the best possible product for the customer. They need to know what to build next and whether or not what they have already built has hit the mark. The Product Owner needs to know what the teams need and how she can help them.
• Product Owner<–>Customers
  The Product Owner and teams are trying to create the best possible product for the customer. The customer needs to know when they will have features they care about, and perhaps the reasoning behind the priorities. Involve them as much as possible by being transparent. The Product Owner needs to learn their real goals or problems with them (or envision something beyond their vision) and collect the information that will help him prioritize well.
• Teams<–>Customers
  The teams are trying to create the best possible product for the customer. They need to know the context for features and have detailed domain knowledge. Ideally, teams co-create solutions directly with customers by grasping the customers’ essential (rather than superficial) goals and problems. Teams need to confirm with customers that they fully understand the requirements they are clarifying together.
• Product Owner<–>Higher Management
  Higher management beyond the product group (portfolio managers, C-level executives, etc.) should view the Product Owner as having the final accountability and responsibility for product success. She is responsible for making the development status visible and realizing higher management’s (perhaps implicit) mandate to optimize desired impacts (e.g., ROI and market share). The Product Owner, with support from Scrum Masters, engages higher management’s help to improve the organizational design.
• Product Owner<->Scrum Masters
  The relationships above are directly related to “product ownership,” but this one is different. It relates to Product Owner knowledge and behavior. The Scrum Masters need to know the Product Owner’s concerns, questions, and obstacles so they can help. A good Scrum Master can be a friendly ear or a shoulder to cry on. Scrum Masters educate and feed back so Product Owners can adapt.

LeSS Meetings

When we introduce LeSS, a frequent question is, “How is one Product Owner going to manage all of those meetings with all of those teams?” Fortunately, the concern behind that question is based on a misunderstanding. The one Product Owner in LeSS only attends single meetings even though there are multiple teams. And the number of team members at those single meetings is manageable. If there are just two teams, everyone can effectively attend and participate. If there are many teams, only two representatives from each team may attend.

What LeSS meetings does the Product Owner attend and what is their average duration in a typical two-week Sprint?

• Sprint Planning One - 1 hour.
• Overall Product Backlog Refinement (PBR) - 4 hours
• Sprint Review - 2 hours.
• Overall Retrospective - 1.5 hours.

So the total time spent in LeSS events is, on average, about eight hours in a two-week Sprint.

The Product Owner does not attend the team-specific meetings: Sprint Planning Two, Daily Scrums, team PBRs, team Retrospectives.