The ART of Selecting SAFe Product Owners

A few weeks ago, I was teaching an executive Leading SAFe class, and our Business Owners were clearly very new to Agile, SAFe and Scrum. As I started the lesson on Team and Technical Agility, I noticed them leaning in to try and better understand the role of the SAFe Product Owner.  We had begun ART design prior to the class, and the subject of identifying Product Owners had already been tabled. After I rattled off my view and answered the many questions that followed, my co-teach said to me, “That would make an excellent blog”. Today, I am testing that theory. :)

 

The Product Owner is the empowered voice of the customer for the Agile Team. Ideally, they come from the part of the organisation that uses the solution/product or the part of the organisation that defines solutions/products for external customers. They need to be subject matter experts in your business and the solution/product in development. Given that a Product Owner needs to know your business, sourcing suitable Product Owners externally is challenging. (Unless, of course, you steal from the competition!)

SAFe Product Owners are the content authority for the Agile Team. Which means they are the source of the work and the authority on what is required and what is acceptable. They perform this role by collaborating with organisational stakeholders and the Agile Teams to co-create the stories that fill the team backlog.  On a day-to-day basis, the Product Owner is a member of the agile team. They answer questions about the work from the agile team and provide feedback on the work that has been delivered. Part of their role is to confirm that the team has met the acceptance criteria for the work.

 

It is critical that the Product Owner is empowered. Agile does not work without empowered Product Owners. Specifically, the SAFe Product Owner must be empowered to accept user stories for the team and provide guidance on the scope of the features in partnership with Product Management. As illustrated above, the Product Owner significantly influences the team's backlog and priorities. If the Product Owner is not empowered and their decisions are constantly overruled, then the team’s outputs will be wasted. This is both costly to the organisation and demoralising to the team.

 

When it comes to empowering Product Owners, SAFe Principle #9 provides excellent guidance on the pre-conditions to enable decentralised decision-making. As per David Marquet’s Turn the Ship Around, in order to “give control”, the people you are empowering must have the technical competence to make the right decisions and clarity on the organisation’s purpose. This requires alignment with the ART’s Business Owners, Product Managers and other stakeholders.

 

One of the ways the SAFe Product Owner maintains alignment between themselves, the team and their stakeholders is by ensuring all parties are actively involved in Iteration Reviews and System Demos. Some stakeholders will need some “encouragement” to protect these events in their busy calendars. A good Product Owner will be comfortable playing the role of  “Jiminy Cricket” and reminding truant Business Owners that their participation in System Demos is a critical guardrail.

 

Full-time Product Owners are ideal, especially for new teams and new Product Owners. They will need time to both learn the role and do the role. Over time, a full-time Product Owner might begin to lose business context; a typical pattern for addressing this is to rotate Product Owners back into business roles after about 12 months. Another approach one client uses is to have Product Owners spend approximately 20% of time participating in “the business”, attending regular meetings, offsites, etc.

 

When it comes to asking for a full-time Product Owner for every agile team, I always say be careful what you ask for. If the delivery organisation insists on full-time Product Owners, there are two ways to deliver this outcome without actually meeting the needs of the agile team: 1) Find someone on your team that you can live without and offer them to the delivery organisation or 2) hire an external contractor to fill the role. In both cases, the agile team has a Product Owner in name only. This is not going to go well. 

An alternative approach is to request less time from the right people in order to avoid getting lots of time from the wrong people! Part-time Product Owners tend to be either part-time in the role or part-time across two teams.

 

If the Product Owner is part-time and has another responsibility in the business that keeps them connected to the business, this might be a good option.  To make this work, the Product Owner has to prioritise the needs of the agile team first. They need to participate in all Team and ART events and be accessible to the team to resolve questions that arise during development to provide feedback quickly. If you are going to use this approach, you should assume the Product Owner role will consume at least 50% of the person's time.

If the Product Owner is to be split across two teams on an Agile Release Train, it places significant additional coordination effort on the Scrum Masters. They will need to roster the Product Owner's time during PI Planning and PI Execution so that both teams are equally supported. This approach will only work in an environment where the Product Managers are committed to investing in feature refinement prior to PI Planning that is inclusive of the Agile Teams. (We call this Disco). This approach makes the most sense when a Product Owner is supporting teams that commonly share features, e.g. a stream-aligned team and a related platform or complicated subsystem team. 

 

The other scenario where a shared PO model can work is when the teams are in different time zones, as there is less contention with the morning team events like Team Syncs and Iteration Planning.  It is also important to note that shared Product Owners are a disaster when either the Product Owner or the Team is new to the organisation or solution.

 

No! Please, do not do this! The Product Owner and the Scrum Master have different remits that should not be intertwined. As we covered in our previous post, the Scrum Master focuses on coaching, facilitating planning, and delivering. They are not usually subject matter experts on your solution. Their expertise lies in Agile, Scrum and SAFe. Therefore, they are unlikely to make good Product Owners. Conversely, if I have Product Owners who are subject matter experts, I want them to work with Agile Teams to ensure we are delivering valuable solutions to our customers. This is a much better investment of their time.

 

Technically, a Product Owner could come from technology. (In fact, up until SAFe 4.6, they did!) This is one of the situations in which you need to consider the context. Some teams have very technical backlogs that are not business or customer-facing. In this case, a technology Product Owner might be the most competent choice. For example, we have a client that builds cyber-physical systems in a highly regulated environment, and they use System Engineers as Product Owners for some of their teams. Another example is a technology business analyst who is considered a subject matter expert and completely and wholly trusted by Product Management.

 

While some SAFe Product Owners do come from Technology, tread carefully here. Often, one of the challenges we are trying to address with SAFe is the “lack of trust” between “business” and “technology”. Product Owners from technology will only work if the Business Owners and Product Management are 100% on board with delegating their authority to the Product Owner. It will also be essential to ensure that these Product owners have sufficient clarity on the organisation's purpose to fulfil the role.

 

As a rule, Team Leaders or Managers do not make good Product Owners. This has a tendency to create imbalance in the Agile Team, and Scrum Masters often end up being undermined, especially when the Product Owner is more senior than the Scrum Master. It can be difficult for a new agile team to become self-organising and self-managing when their priorities and acceptance of work as completed both still come from their line manager. As with any rule, there are exceptions; generally, when the team is more technical, the team’s manager is a specialist in that technology, and they behave as a servant leader.

 

Product Owners are a critical ingredient to successful, high-performing agile teams. Agile is all about balance, and the Product Owner’s role is to ensure the team is focused on delivering the right value to the right customers at the right time. It is quite simply an investment in getting good outcomes from your agile teams.