Exploring the Controversy Around SAFe's Approach to Product Ownership

Product Ownership Is a Crucial Element in Improving Outcomes

SAFe and Scrum both consider product ownership crucial to maximizing outcomes in environments of complexity and uncertainty. Teams are ideally organized around products/value streams so they can apply customer-centricity. Product people and their teams are ideally accountable for outcomes and are empowered to figure out, inspect, and adapt requirements/scope as needed.

SAFe Has Multiple Product Ownership/Management Layers

As organizations tackle bigger products, they have some alternatives for how to tackle product ownership/management. Scrum advises having one product owner for each product, even if multiple teams develop the product. This is at the core of scaling frameworks such as Nexus and LeSS. SAFe takes a path that is more aligned with the classic structure of product management organizations, which is to have multiple layers of product ownership/management.

Product owners own the product at the Agile Team level. Product managers own product at the teams of Agile teams level (Agile Release Trains). Solution managers own products for huge teams of teams working on even larger products/solutions.

Why Did SAFe Make This Choice?

SAFe takes the perspective of learning from experience in the trenches and what patterns organizations are using and applying lean/Agile principles as needed to help organizations evolve. And many organizations have been struggling to scale product ownership when we're talking about multiple teams. Product management experts such as Melissa Perri also talk about multiple product management roles (see some thoughts about how this relates to SAFe below). Interestingly enough, Scrum@Scale also has product owners at every level. And LeSS/Nexus also introduce multiple product owners when you scale beyond a handful of teams.

The advantage of this approach is that it aligns with the product manager/owner journey. Working closely with one or two teams, owning product choices for a couple of product features or a certain slice of the product, can be a great jumping point for junior product managers/owners (What Melissa Perri refers to as associate product managers in Escaping the Build Trap).

As the product manager/owner gains experience, they can take on a whole product themselves. It takes time for a product owner/manager to gain the experience to act as the visionary entrepreneur for their product. They might start feeling more comfortable writing stories and executing experiments and, over time, learn to influence, design product experiments, and make tougher prioritization decisions with multiple demanding stakeholders. In other words, product managers/owners naturally evolve from focusing on tactics to strategy over time.

What Are Some Downsides To Splitting Product Responsibilities Between the Product Owner and Product Manager?

An anti-pattern we often see is that the PM/PO split allows an organization to staff the PO role with “story writers” and “project managers” — people who aren’t empowered as product owners, and that reinforce the project mindset of requirement order-taking and managing scope-budget-timeline. This lack of empowerment leads to delays and an environment where the team is focused on outputs rather than outcomes.

Empowering product owners and their teams is a common challenge in SAFe AND Scrum. What I’ve seen work well is carving out an appropriate product scope within which the product owner and team are empowered to figure out what to build to achieve the desired outcomes and optimize the value of that product or that aspect of a bigger product.

Doing this requires figuring out the product architecture and moving towards an empowering leadership style.

As in many other areas, SAFe takes the evolutionary approach. If you’re a purist or a revolutionary, you’ll probably struggle with it. Real-world practitioners are more likely to relate to the evolutionary approach. It’s important to ensure that the PO/PM separation is not seen as an excuse to continue doing everything the same.

Product Managers and Product Owners: A Collaborative Relationship

Leaders implementing the PO/PM split should ensure healthy collaboration, involvement, and partnership across the product ownership/management team.

Product managers should internalize the SAFe principles of unleashing the intrinsic motivation of knowledge workers, in this case, product owners. Product managers have a role as lean/Agile leaders to nurture the competence, awareness, and alignment in the product team that would enable them to decentralize control and let product owners OWN a certain slice of the product.

Product managers and product owners should discuss what decisions make sense to centralize and which should be decentralized. The goal of product managers should be to grow product owners over time so they can make more and more decisions — and minimize the decisions that need to be made centrally. This is key to scaling without slowing down decision-making while maintaining and ideally improving outcomes aligned with strategic goals.

Increased Risk of Misunderstandings Around Product Ownership With Product Roles Filled by Non-Product People

One very specific risk of the SAFe choice to split the PM and PO roles is that it creates the need for many more people in a product role than the number of people in the product organization. This vacuum pulls people like business analysts, project managers, and development managers into the product owner role. Some people can become great product owners but come with very little product (management) experience. Business analysts, for example, are used to consider what the customers say as requirements. They are used to the “waiter” mindset. They struggle to say no or to think strategically about what should be in the future or what should be in the product. Development managers are used to being subject matter experts, guiding their people at the solution level, and managing the work. Project managers are used to focusing on managing scope/budget/timeline rather than value and outcomes.

Use the Professional Scrum Product Ownership Stances to Improve your SAFe Product Ownership

One technique I found very useful is to review the Professional Scrum Product Ownership Stances with SAFe product owners and product managers. We try to identify which misunderstood stances we’re exhibiting and what structures are reinforcing these misunderstood stances/behaviors. For example — what’s causing us to be “story writers”? We explore the preferred product owner stances and discuss what’s holding us back from being in these stances. Why is it so hard to be an “experimenter,” for example?

An emerging realization from these conversations is that SAFe structurally creates a setup where team-level product owners play “story writers” and “subject matter experts” more often. It’s non-trivial to switch to an environment where they are a “customer representative” and a “collaborator” with the space to “experiment” with their team towards the right outcome rather than take requirements as a given. It’s hard to get SAFe product managers to be the “visionary,” “experimenter”, and “influencer”. The issue here isn’t unique to SAFe. Product owners struggle to exhibit these behaviors in most Scrum environments as well. What I find useful is to align on a “North Star” vision of what we WANT product ownership to look like at scale and take small steps in that direction continuously, rather than settle for “project management” or “business analysis” called a new name.

SAFe Product Management: Providing Vision and Cohesion in a Pharma IT Environment

Let’s close with an example of how this can play out in practice. I'm working with the IT organization of a pharmaceutical company. As they were thinking about how to help their Enterprise Applications group become more agile, one of the key questions was how do we create product teams that are empowered to directly support the business — by minimizing dependencies and creating real ownership of each of the enterprise applications as a platform that other IT functions can more easily build off of and leverage. Several Enterprise Applications have multiple teams working on different aspects of them. We created stream-aligned teams, each owning and managing that aspect as a product. The product owners and their teams are empowered to consider needs and wants coming in from other IT functions and the business and shape the future of their product. Most of these product ownership decisions happen at the team level. Product managers focus on alignment and cohesion across the platform. We are still working on establishing the right mechanisms to balance vision/alignment with local initiatives at the team level.

So, Now What?

SAFe’s approach to product ownership is a frequent target of criticism in the hard-core Agile community. Some of it is pure business/commercial posturing (aka FUD), and some of it is fair and constructive.

My aim in this article was to help practitioners explore the rationale, the potential, and the risks behind SAFe’s approach to product ownership, as well as some patterns and models, such as the Professional Scrum Product Ownership stances, that can be used to inspect and adapt/grow the effectiveness of your product ownership approach.

As an individual product owner or product manager, you can use these models/patterns to drive your learning journey and help you structure your organization's conversation around creating the environment that empowers you to be a real product owner or product manager.

As leaders of product organizations in a SAFe environment, I hope this can help you establish a vision of how you want your product organization to look like and guide you on the way there.