SAFe Product Owner vs Product Manager: Scaling Product Ownership with Scrum

What is SAFe’s perspective on the Product Owner role? How does it differ from the Scrum Guide? Why is Product Ownership split between the Product Owner and Product Manager in SAFe?

SAFe’s approach to Product Ownership draws quite a bit of criticism. As a Professional Scrum Trainer who’s also a SAFe Fellow/SPCT, here’s my perspective…

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 to outcomes and are empowered to figure out, inspect, and adapt requirements/scope as needed.

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 Product at the Agile Team level. Product Managers own Product at the teams of agile teams level (Agile Release Trains). Solution Managers own Product for huge teams of teams of teams working on even larger products/solutions.

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.

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.

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 have conversations about what decisions make sense to centralize and which should be decentralized. And 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 still maintaining and ideally improving outcomes in alignment with strategic goals.

One very specific risk of the SAFe choice to split the PM and PO role 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.

One technique I found very useful is reviewing the Professional Scrum Product Ownership Stances with SAFe Product Owners and 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.

Let’s close with an example of how this can play out in practice. I’m working with the IT organization of a Pharma 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 initiative at the team level.

SAFe’s approach to Product Ownership is frequently criticized 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.

Summary & Next Steps

• Empower Your POs: The biggest risk of the PM/PO split is creating “story writers” instead of owners. Focus on carving out empowered product scopes where teams can optimize for outcomes.
• Adopt a Growth Mindset: View the PM/PO relationship as a partnership. Product Managers should act as lean/agile leaders, nurturing the competence of POs to decentralized decision-making.
• Use the PO Stances: Regularly review the Professional Scrum Product Owner stances to identify where you might be falling into “Project Manager” or “Subject Matter Expert” traps.

If product ownership in your SAFe context feels fuzzy, start with a Product Operating Model Strategy session or explore how we can Fix Your Agility by moving beyond SAFe theater.

Dive deeper into this topic in this episode of Breaking the SAFe: Exploring SAFe Product Ownership.