Decentralize decision-making

—SAFe Lean-Agile Principle #9

 

Product and Solution Management

Product Management has content authority for the Program Backlog. They are responsible for identifying Customer needs, prioritizing Features, guiding the work through the Program Kanban and developing the program Vision and Roadmap.

Solution Management has content authority for the Solution Backlog. They work with customers to understand their needs, prioritize Capabilities, create the Solution vision and roadmap, define requirements, and guide work through the Solution Kanban.

This article describes the roles that Product Managers and Solution Managers play in SAFe. While the roles are similar in most respects, they manage different levels of concern.

Details

Lean enterprises focus on delivering the right solutions to customers with the highest quality in the shortest sustainable lead time. This requires people with explicit content authority to take responsibility for continuously defining, prioritizing, and validating requirements. Working closely with development, in short, integrated learning cycles, Product and Solution Management bring the voice of the customer to the developers and the voice of development to the customer.

Following Principle #9, Decentralize decision-making, SAFe offers a chain of content authority that spans three levels:

  1. TeamProduct Owners make fast, local content decisions on behalf of the Agile Team.
  2. Program – Product Management is accountable for content decisions for the Agile Release Trains (ARTs)
  3. Large Solution – Solution Management has content authority for Solution Trains

Product Management and Solution Management prioritize work using Weighted Shortest Job First (WSJF), schedule Features and Capabilities for Release using the Roadmap, validate customer response, and provide fast feedback.

A Lean-Agile Approach to Content Management

What SAFe describes as content has traditionally been represented by a Marketing Requirements Document (MRD), Product Requirements Document (PRD), and System Requirements Specifications (SRS).

In traditional development, these artifacts were typically done upfront, with an expectation that all the requirements could be established before the start of Solution development. However, this method had limited success and was a significant driver of Lean and Agile practices.

We now understand that assumptions about requirements, design, and architecture all need to be validated through actual solution development, testing, and experimentation. Further, Agile teams must be open to emerging knowledge that can be quickly fed back into the solution [1]. In SAFe, Continuous Exploration is the process used to explore the market, and user needs continually, and to define a vision, roadmap, and set of features and capabilities that address those needs.

As described in Solution Intent, some of the requirements of the solution are likely to be well understood and fixed from the beginning, while others are variable and can only be recognized during the product development process. Managing this new approach is the primary responsibility of Product and Solution Management. In the Lean Enterprise, these duties must be fulfilled in a far more Agile manner, as is illustrated in Table 1.

 Responsibility Traditional Agile
Understand customer need Upfront and discontinuous Constant interaction with the customer, including Gemba walks, end-user interviews and surveys, brainstorming, trade studies, market research
Document requirements Fully elaborated in documents handed off High-level vision, constant product and solution backlog refinement and informal face-to-face communication with teams
Schedule Created in hard-committed Roadmaps and Milestones at the beginning Continuous near-term ‘roadmapping’
Prioritize requirements Not at all or perhaps one-time only, often in requirements document form Reprioritized at every  PI boundary via WSJF, constant scope triage
Validate requirements Not applicable, quality assurance (QA) responsibility Primary role involved with Iteration and PI demos, acceptance criteria and fitness for purpose understood
Manage delivery schedule Typically one time, fixed well in advance Released frequently, whenever there is enough value
Manage change Change avoided—weekly change control meetings Change embraced, adjusted at PI and iteration boundaries

Table 1. Changes in Product and Solution Management behavior in a Lean-Agile enterprise

Responsibilities of Product Management

The following section describes the primary responsibilities of the Product Manager in the context of a single Agile Release Train (ART).  The responsibilities of Solution Management are described later.

  • Understand customer needs and validate solutions – Product Management is the internal voice of the customer for the ART and works with customers (as well as Product Owners) to constantly understand and communicate their needs and participate in the validation of the proposed solutions.
  • Understand and support portfolio work – Every ART lives in the context of a portfolio, so Product Management has a responsibility to understand the budget for the upcoming fiscal period, understand how Strategic Themes influence the strategic direction, and work with Epic Owners to develop the Lean business case for Epics that affect their ART.
  • Develop and communicate the program vision and roadmap – Product Management continuously develops and communicates the vision to the development teams and defines the features of the system. In collaboration with System and Solution Architect/Engineering, they also define and maintain the Nonfunctional Requirements (NFRs) to help ensure that the solution meets relevant standards and other system quality requirements. They are responsible for the roadmap, which illustrates, at a high level, how features are intended to be implemented over time.
  • Manage and prioritize the flow of work – Product Management manages the flow of work through the program Kanban and into the program backlog. Product Management is responsible for making sure that there are enough features ready in the backlog at all times. For example, they have feature acceptance criteria that can be used to establish that it meets its Definition of Done (DoD). And since judicious selection and sequencing of features is the key economic driver for each ART, the backlog is reprioritized with WSJF before each Program Increment (PI) Planning session.
  • Participate in PI planning – During each PI planning session, Product Management presents the vision, which highlights the proposed features of the solution, along with any relevant upcoming Milestones. They also typically participate as Business Owners for the train, with the responsibility of approving PI Objectives and establishing business value.
  • Define releases and program increments – Owning the ‘what’ means that Product Management is largely responsible for release definition as well, including new features, architecture, and allocations for technical debt. This is accomplished through a series of Program Increments and releases, whose definition and business objectives are also determined by Product Management. Product Management works with release management, where applicable, to decide when enough value has been accrued to warrant a release to the customer.
  • Work with System Architect/Engineering to understand Enabler work. While Product Management is not expected to drive technological decisions, they are expected to understand the scope of the upcoming enabler work and to work with System and Solution Architect/Engineering to assist with decision-making and sequencing of the technological infrastructures that will host the new business functionality. This is typically done by establishing a capacity allocation, as described in the Program and Solution Backlogs article.
  • Participate in demos and Inspect and Adapt (I&A) – Product Management is an active participant in biweekly System Demos, including the aggregate one at the end of the PI. They are also involved in the assessment of Metrics, including evaluation of business value achieved versus plan, and are active participants in the inspect and adapt workshop.
  • Build an effective Product Manager/Product Owner team – Though the Product Owner and Product Management roles may report to different organizations, forming an effective extended Product Management/Product Owner team is the key to efficient and effective development. Such a team also contributes materially to the job satisfaction that comes with being part of a high-performing team, one that routinely delivers on its quality and vision commitments.

Product Management’s Participation in Large Value Streams

The above section highlights the role of Product Management in the context of the ART. For teams building large solutions that require multiple ARTs, Product Management has additional responsibilities:

  • Collaborate with Solution Management – At the Large Solution Level, Solution Management plays a similar role, but with a focus on the capabilities of the larger solution. But building an effective solution is no more effective than the collaboration between the two roles. This involves participation in solution backlog refinement and prioritization, as well as splitting capabilities into features, and NFRs, as the case may be.
  • Participate in Pre- and Post-PI Planning – Product Management also participates in the Pre-PI planning meeting, working with the Solution Train stakeholders to define the inputs, milestones, and high-level objectives for the upcoming PI planning session. In the Post-PI planning session, Product Management helps summarize findings into an agreed-to set of solution PI objectives.
  • Participate in the Solution Demo – Product Management participates in the solution demo, often demonstrating the capabilities that their ART has contributed and reviewing the contributions of the other ARTs, always with a systems view and always with an eye toward fitness of purpose.
  • Collaborate with Release Management – In larger-scale systems, Release Management also plays a significant role. Product Management works with the key stakeholders on progress, budget, release strategy, and releasability of their elements of the solution.

Responsibilities of Solution Management

Solution Management plays a similar role to Product Management, but at the large solution level and has content authority over capabilities instead of features. Responsibilities include working with portfolio stakeholders, customers, ARTs and Solution Trains to understand needs and build and prioritize the solution backlog. They have a similar vision, roadmap, solution Kanban, and solution demo activities as well.

Solution Management, Solution Train Engineer, and Solution Architect/Engineering—are part of a trio that shares much of the responsibility for the success of a Solution Train. Solution Management is responsible for the solution intent, which captures and documents fixed and variable solution level behaviors. They also work with Release Management where applicable.

Solution Management has a crucial role in pre- and post-PI planning, as well as large solution level I&A workshops. They also work with Suppliers, making sure the requirements for supplier-delivered capabilities are understood and assisting with the conceptual integration of these concerns.


Learn More

[1] Ries, Eric. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown Business, 2011.

[2] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

Last update: 11 November 2017