5 Ways Product Advisory Can Support SAFe Business Owners & Product Managers

Sometimes, a framework does not provide all of the answers needed to apply concepts in the real world. This is to be expected as a framework is a framework! At the SAFe Summit in Berlin last month, Scaled Agile Chief Methologist Andrew Sales defined a framework as “a basic structure underlying a system or concept… intended to serve as a guide of something that expands the structure into something useful.”

The Scaled Agile Framework uses a combination of Business Owners, Product Management and System Architects to shape and prioritise the ART backlog. Often, we can apply SAFe “out of the box” so to speak and it all goes swimmingly well.  However, it is not always that simple, which is hardly surprising given organisational contexts can vary widely. 

While SAFe’s requirements hierarchy and associated content authority roles make life simpler for the teams on the Agile Release Train, this model doesn’t always cater for ARTs with especially broad stakeholder groups. This can result in important voices being missed when scope and prioritisation decisions are being made. Our solution for this is a Product Advisory Group, also known as a Product Council or a Product Management Group. 

Why Would I Want a Product Advisory Group For My ART?

There are four main scenarios in which we have applied this approach.

Enterprise Executives Who Want to be SAFe Business Owners

When identifying Business Owners, we start by identifying the executives who have a fiduciary responsibility for the outcomes being delivered by the Agile Release Train (ART). Often, these folks were program sponsors (or equivalent) in your pre-SAFe world. 

Usually, the challenge is to get the right level of seniority in the organisation to champion the ART(s) and navigate the politics. However, sometimes, the opposite happens—the C-Suite volunteers to be the ART’s Business Owners and follow through by performing the role!  While this is exciting, it can create a problem whereby the people who would normally be the Business Owners have no role in defining scope or priorities. In this scenario, creating a Product Advisory function that advises the Business Owners provides a way for all the right voices to contribute. 

Key Product Management Stakeholders Without a Formal SAFe Role

SAFe Product Managers often have a range of stakeholders who are effectively their peers. These folks likely represent specific customer segments or business functions that use the product(s) being delivered by the ART. SAFe doesn’t provide any specific guidance as to how Product Management should approach creating an inclusive environment for a wide and varied stakeholder group. Some Product Managers have a gift for stakeholder management and barely bat an eyelid. Others will find the formation of a Product Advisory function an effective construct to ensure these critical stakeholders get a voice. We think of this as an example of moving authority for decisions closer to the information. 

Epic Owners Who Are Not Business Owners or Product Managers

When an Epic Owner, as a content authority, is not a Business Owner, Product/Solution Manager or System/Solution Architect, they can find themselves without a voice when “their” epic is being prioritised and progressed by the Agile Release Train.  Ideally, Product Management will recognise this important stakeholder and invite them to participate, but this is not always the case. Including these epic owners as part of a Product Advisory Group formalises their role on the ART and ensures their voice is heard. 

Managers Who Are Responsible For the Technical Health of the Systems on the ART

In some enterprises, there are technology leaders who don’t fall into any of the above categories but are responsible for the operational performance of the systems being enhanced and maintained by the ART. Unless they own an epic (or feature), there is no simple SAFe answer as to how these people fit with the ART. However, given the role of the Product Advisory Group in shaping and prioritising the ART backlog, the managers are a logical inclusion.

What Does Product Advisory Do?

Contribute to Feature Definition Workshops

The ART’s Product Manager(s) and System Architect(s) won't always know everything about every potential feature.  Product Advisory can play a valuable role when identifying features from epics by being active contributors to impact mapping and/or feature-storming workshops. Their broad business knowledge will assist with identifying the people and roles that should be represented in feature definition sessions. 

When it comes to Feature Definition (aka Feature Disco), Product Management may identify that the benefits of a specific feature would be better represented by another ART stakeholder from Product Advisory. This often results in the Product Managers empowering a better-informed Product Advisor to own feature definition and acceptance.  We tend to refer to this individual as the Feature Owner for that particular feature. 

Some potential Product Advisors will be initially identified through feature definition workshops.  When this happens, make sure Product Management takes the action to confirm if this person should join the Product Advisory Group and, if so, invite them to the relevant upcoming ART events.

Prioritise the ART Backlog (aka feature WSJF)

While SAFe suggests that Product Management and System Architects prioritise features for the ART, we believe the best prioritisation involves the ART’s stakeholders. Whenever we have an ART with a Product Advisory group, we have them join Product Management and the System Architect(s) for ART backlog prioritisation. We find this provides Product and Architecture with a more holistic view of organisational priorities and results in great alignment across stakeholders.

In most cases, the Product Advisors have a deeper understanding of the feature benefit hypothesis than the Business Owners; therefore, they are empowered to prioritise the ART backlog. Occasionally, the Business Owners will still want to be included in feature WSJF. This only works when the total number of people involved is less than ten.

Engage in PI Planning

Product Advisors can get involved in PI Planning in a multitude of ways.

• Context Briefings - Some Product Advisors provide briefings to the ART with respect to the customer segments or business units they represent. Where a Product Advisor is also an Epic or Feature Owner they may also provide the context briefing for these items at PI Planning. 
• Team Breakouts - If a Product Advisor “owns” a feature or has been identified as a stakeholder for a given feature during feature definition, the Agile Teams on the ART will likely want this Product Advisor to participate as a content authority or subject matter expert during the team breakouts. 
• Draft Plan Review - As ART stakeholders, we expect Product Advisors to be present for the Draft Plan Review, listen intently and ask questions where the messaging from the teams is unclear. (The same logic applies to Final Plan Review).
• Management Review & Problem Solving -  While this is traditionally the domain of the Business Owners, Product Management, System Architects and Release Train Engineers - if you have a Product Advisory group, you have them for a reason. In most cases, Product Advisory will attend this evening session and will be well placed to help the group resolve some of the challenges raised by the ART.
• Planning Adjustments - We like the leaders who made decisions and took actions in the Management Review & Problem Solving session to own those outcomes and communicate them to the ART.  Product Advisors can fall into this category, in which case we would expect them to be present and participate as needed.
• Business Value Rating of PI Objectives -  This is usually the domain of the Business Owners and frankly it goes much better when you have a smaller group of people trying to agree on the Business Value of PI Objectives. We usually let the Business Owners decide if they need the Product Advisors to join these sessions as a sounding board. In most cases, they don’t.
• ROAMing ART Risks - As with the Management Review & Problem Solving session, it is likely that Product Advisors will be able to assist with owning, mitigating or resolving risks. 
• Accepting the Plan - Most ARTs leave this to the Business Owners, but we have seen Business Owners invite the Product Advisors to participate in accepting the plan, often by asking for a “fist of five”.
• PI Planning Retrospective - Everyone who attends PI Planning should provide feedback on the event. The Product Advisory group is no exception.

Provide Feedback at the System Demo Every Iteration

The System Demo is the opportunity to see how the teams are progressing with their PI Objectives. Product Advisors must attend and provide feedback. In our experience, Product Advisors love System Demos because they can see all the great outcomes the ART is enabling. 

Actively Participate in Inspect and Adapt 

Inspect and Adapt is the Product Advisory group’s opportunity to see the outcomes of the PI, celebrate the ART’s success and contribute to the relentless improvement of the ART. 

How Do Product Advisors Work with Product Managers

Product Advisors are an extension of the Product Management function in SAFe. They interact with Product Managers regularly as part of the ARTs cadenced-based events. Some Product Managers have a fortnightly sync with their Product Advisors following the System Demo. This provides time and space to digest the ART progress and discuss priorities for future PIs. The Product Advisory Sync can also be used to support the rolling prioritisation of Features.

When is a Product Advisory Group Applicable

One of our principles when launching an ART is that everyone has a home on day one. A Product Advisory Group is one way to ease the transition to the new way of working. Sometimes, it can feel a little odd, but it does work.  As a virtual team, a Product Advisory group can broaden the ART’s reach into and across the organisation, help the organisation align on priorities and strengthen the connection between the ART and all its stakeholders.