What’s a SAFe Senior Product Owner?

What’s a SAFe Senior Product Owner?

It’s never a good sign when your department head says you have to report to a senior product owner. Within Agile the role does not exist and it effectively removes your authority to develop and manage the vision of the product.

From that point on you’ll be delivering weekly status reports so the senior product owner can meet with your business owner and agree to new deliverables and timeframes without you in the room.

At this point, you have effectively given up Scrum and have started towards a SAFe (Scaled Agile Framework) and a more inflexible Product Management structure, which seems to be the bastard child of Prince2 & PMBOK given the middle name of Agile to disguise its true heritage.

In an earlier article (“Is your company Agile? “), I indicated that larger, older organisations have a tendency to gravitate to what they know and recognise. SAFe for me feels and looks like a framework developed by established PMO and IT departments to bring products, successfully developed using Scrum, back under their control.


If you are someone who enjoys the freedom to create products it may be the time to move on because this is where company politics and power grabs start. It becomes less about the product and more about personal career development and power.

The old senior manager elite will introduce SAFe to try and stop “fail-fast” learning and incremental updates in favour of right first time. They will highlight to business owners and senior stakeholders the need for better upfront definitions; to reduce the costs of rework and engineering on each feature, and SAFe will be sold as a way to guarantee feature delivery dates. The core elements of Scrum and Agile will be discredited, and there will be a migrate back to the old waterfall processes that distance business owners from development teams.

Agile is a collection of thoughts and beliefs on how to develop better products and services; Scrum is a framework based on those Agile principles, and SAFe️ is described as a scaling framework to implement Scrum at an enterprise level.

Maarten Dalmijn article Product Owners lose their job when SAFe is introduced inspired me to write this follow-up. He outlines how startups begin with good intentions and follow the true path, but could introduce bad habits over time as they become maturer. I get a sense he has had a very bad experience with the introduction of SAFe.

Scrum: The Product Owner is responsible for building a product of the highest possible value.
SAFe: Moves the responsibility for delivering value to a Product Management Team.
Scrum: The Product Owner is the only person who is responsible for managing the Product Backlog.
SAFe: The Product Backlog is replaced with a Program Backlog, which then gets broken down in Team Backlogs. Product Owners have limited say over the Program Backlog. but are responsible for the Team Backlogs. The development team has no authority to amend the backlogs.

Larger, established companies and brands are attempting to introduce SAFe as a way forward in their businesses, but I believe it will only introduce a Scrumfall system that will curtail many of the agile principles that encourage communication and empowerment throughout a scrum team.

Like Maarten, I’d agree we should stick to the agile principles if you want to create successful products that add value for customers: One product, one product backlog, and one product owner.

SAFe breaks the core rules of Agile development and there it’s questionable whether it should be allowed to include “Agile” within its name. Using some elements from Scrum, Lean, Kanban and continuous development does not necessarily make it agile. I’ll look to research it in more depth in a future article to see if I can find more positives, but if I was a product owner on a SAFe program of work I’d be worried about the amount of documentation I’d be generating and the value I’d be delivering to the customer.

Agile Manifesto


Iterative Development

Here are the key principles of iterative development

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity–the art of maximizing the amount of work not done–is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

In the future I’ll look to do a fuller crique of SAFe.