Product and Solution Magement

Decentralize decision-making

—SAFe Lean-Agile Principle #9

Product and Solution Management Abstract

Lean-Agile Enterprises focus on delivering the right Solutions to Customers with the highest quality and shortest lead times. In a dynamic environment, this requires people with clear content authority to take responsibility for continuously defining, prioritizing, and validating requirements. These people work closely with development in short, integrated learning cycles, bringing the voice of the customer to the developers and the voice of development to the customer.

In accordance with Decentralized Decision-Making, SAFe prescribes a content authority chain that extends through three levels. Solution Management is responsible for guiding the solutions that constitute the Value Stream. Product Management is responsible for Program Vision and Backlog. Finally, Product Owners make fast, local content decisions on behalf of the Agile Team.

This article describes the important roles that Product Managers and Solutions Managers play in SAFe. While the roles are similar in most respects, they operate at different levels of the solution and manage different concerns.


Solution Management and Product Management are the main content authorities in SAFe, guiding the Value Stream and Program Levels respectively, where they have primary responsibility for Value Stream and Program Backlogs. They create the Vision; they work with Customers to understand their needs, define requirements, and guide work through the Value Stream and Program Kanbans. They prioritize work using WSJF, schedule it for Release via the Roadmap, validate the customer response, and provide fast feedback.

A Lean-Agile Approach to Content Management

What SAFe describes as content has traditionally been represented by marketing requirements documents, product requirements documents, and system and software specifications. In waterfall development, these specifications were typically done up front, with an expectation that all the requirements could be established in advance of Solution development. However, it didn’t work out all that well that way, and the move to a Lean-Agile paradigm is driven in large part by that result. We now understand that assumptions about system requirements, design, and architecture all need to be validated through actual development, testing, and experimentation [1], and that teams must be open to emerging knowledge that can be quickly fed back into the solution.

As we see 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 understood during the development process. Managing this dynamic new paradigm is the primary responsibility of Product and Solution Management. In the Lean Enterprise, these responsibilities must be fulfilled in a far more Agile manner, as is illustrated in Table 1.

 Responsibility Traditional Agile
Understand customer need Up-front and discontinuous Constant interaction; Customer is part of the value stream
Document requirements Fully elaborated in documents; handed off High-level vision; constant product and solution backlog refinement and informal face-to-face communication with Agile 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; QA responsibility Primary role, involved with Iteration and PI System Demos; acceptance criteria included; 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. For larger (multiple-ART) value streams, additional responsibilities are necessary. Those are described in later sections.

  • 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 validation of the proposed solutions.
  • Understand and support portfolio work. Every Agile Release Train lives in the context of a portfolio, so Product Management has a responsibility to understand the Budget parameters for the upcoming fiscal period, understand how Strategic Themes influence the strategic direction, and work with Epic Owners to develop the 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 though the program Kanban and into the program backlog. Product Management is responsible for making sure that there are enough ready features in the backlog at all times. To be ready, they develop feature acceptance criteria that can be used to establish that the feature meets its Definition of Done. And since judicious selection and sequencing of features is the key economic driver for each ART, the backlog is reprioritized with WSJF prior to each 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 though 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 key technological infrastructures that will host the new business functionality. This can often best be accomplished by establishing a capacity allocation, as described in Program Backlog.
  • Participate in demos and Inspect and Adapt. 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 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 the PM in the context of the ART. For teams building value stream solutions that require multiple ARTs, Product Management has additional responsibilities:

  • Collaborate with Solution Management. At the value stream level, Solution Management plays a similar role, but with a focus on the solution. But building an effective solution is no more effective than the collaboration between the two roles. This collaboration involves participation in value stream 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 value stream 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 synthesize findings into an agreed-to set of value stream 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 much the same role that Product Management plays, but at the value stream level. There, Solution Management is part of the critical troika—Solution Management, Value Stream Engineer, and Solution Architect/Engineering—that shares much of the responsibility for solution success. 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.

Responsibilities include working with portfolio stakeholders, Customers, and ARTs to understand needs and build and prioritize the solution backlog. They have similar vision, roadmap, value stream Kanban, and solution demo activities as well.

Solution Management plays a crucial role in pre- and post-PI planning, as well as value stream inspect and adapt 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, chapter 14.

Last update: 20 April 2016