How to use Product Goals with SAFe

The purpose of this article is to provide a pragmatic approach to working with Product Goals for agile teams in a SAFe context where multiple teams potentially work with multiple products. 

One of my favorite changes to the Scrum Guide 2020 is the addition of Product Goals, as I’m convinced it will help bridge the world of Product Management even more with Scrum and Product Development.

When in a scaled agile setup such as one based on SAFe, there are at least two potential benefits of working with Product Goals; 1) increased focus from Product Management and Owners on taking a product-centric approach to the development work (instead of purely Feature or Epic-driven), and 2) bigger attention to the product-related business benefits, and the measurement of them, created by delivering a set of Features.

And why is this important? Well, because our products are vehicles to deliver value, as the SG2020 states. Epics, Features, Stories and PI Objectives are meer containers, while the products are what real people actually see and use.

Back to Product Goals. If you’re one agile team working on one product, it’s pretty straight-forward. In a scaled setting without the possibility (or willingness) to descale, however, it’ll require a bit more work to manage the extra complexity of multiple teams working on multiple products, but we can still reap the benefits of working with Product Goals. For the sake of simplicity, we keep Product Vision and Sprint Goals out of scope of this article.

My suggested approach:

  • Product Goals for all products delivered by an ART must be prioritized by Product Management and placed in the Program Backlog.
  • As per Scrum Guide 2020, each product must only have one Product Goal at a time.
  • A Product Goal is delivered when the set of Features needed to potentially reach the Product Goal are delivered.
  • A Product Goal is reached when the Benefit Hypotheses of all its Features are confirmed.
  • A Product Goal can be delivered throughout several PIs either by one or multiple teams working on the needed Features.
  • Teams commit to delivering a (part of a) Product Goal in a PI by articulating it as a PI Objective at PI Planning.

How do Product Goals, Features and PI Objectives relate?

To understand the relationship between Product Goals and Features, let’s use Roman Pichler’s Goal-Oriented Roadmap. It suggests that each product release has a goal (i.e., the Product Goal) consisting of three to five Features, and the outcome of the goal is measured by some metrics. Assuming that the definition of a Feature in the GO Roadmap aligns with that of SAFe, we can conclude that a Product Goal is delivered through the Features needed to potentially reach the Product Goal.

Simplied, the PI-wise delivery of a number of Features (or parts of different Features) can be articulated as PI Objectives, and when all Features in a Product Goal are delivered through a number of PIs, the Product Goal is reached, as illustrated below:

No alt text provided for this image

How to measure whether a product has reached its Product Goal?

As per SAFe’s definition, each Feature has a Benefit Hypothesis. Therefore, we should identify the Leading Indicators of these hypotheses being confirmed or not. When we have these for the Features of the Product Goal, we can use them collectively to assess if the Product Goal is reached. Thus, if the Benefit Hypothesis of each Product Goal Feature is confirmed, the Product Goal is probably also reached.

How does all this align with Epics?

In SAFe, Epics are high-level containers of development initiative, capturing larger investments in the portfolio, and potentially spanning across Value Streams, ARTs and products. Thus, we can view the Epics as enabling the “funding” of the delivery of multiple Product Goals, potentially across multiple products.

No alt text provided for this image

If you’re in the MVP phase of an Epic, one approach is to ensure that the minimum set of Features of the MVP also constitutes the Features needed to deliver a Product Goal. Thus, if the hypothesis of the MVP is tested and confirmed, the Product Goal is reached, and the Epic work can continue.

If the hypothesis of the Epic MVP doesn’t align with a single Product Goal, however, just do it like SAFe originally suggests.

What if multiple teams are working on delivering Features for the same Product Goal?

This can be the case if multiple teams share the delivery of Features, or deliver their seperate, own, full Features that feed into an overarching Product Goal. Here, instead of each team creating a PI Objective about delivering the same Product Goal, the delivery of the “shared” Product Goal can be represented as a Program PI Objective with team-specific PI Objectives about their share in the Product Goal (if the full Product Goal is to be delivered in this PI, that is).

No alt text provided for this image

How does it align with roadmapping in SAFe?

You can still continue working with SAFe’s suggested approach with Planning Horizons, Portfolio Roadmaps and Solution Roadmaps. However, instead of using the PI Roadmap template, try using the GO Roadmap because of its focus on goals combined with SAFe’s definition of Features. The only difference would be that, instead of a date, you’d put in the expected PI that you expect the final feature of the Product Goal to be delivered.

Final thoughts

Don’t overcomplicate it; even without Product Goals, there are already many artifacts to juggle in SAFe with Value Streams, Epics, Features, Enablers, Stories, PI Objectives and Sprint Goals. What Product Goals can help with is start focusing more on products. As the Scrum Guide 2020 defines it, a product is a vehicle for delivering value. And in a (maybe unncessessarily complex) setup based on SAFe, we really need to get our focus back on products.