—SAFe Lean-Agile Principle #9
Product and Solution Management
In a similar manner, Solution Management has the content authority for the Solution Backlog. They work with Customers to understand their needs, create the Solution vision and roadmap, define requirements, and guide work through the Solution Kanban.
Lean-Agile enterprises focus on delivering the right solutions to customers with the highest quality in the shortest lead times. This requires people with clear content authority to take responsibility for continuously defining, prioritizing, and validating requirements. Working closely with development in short, integrated learning cycles, they bring the voice of the customer to the developers, and the voice of development to the customer.
In accordance with SAFe Principle #9 – Decentralize decision-making, SAFe prescribes a content authority chain that extends through three levels. Solution Management is responsible for guiding the solutions that constitute the solution. Product Management is responsible for program vision and backlog. And, finally, Product Owners make fast, local content decisions on behalf of the Agile team.
This article describes the important roles that Product Managers and Solution Managers play in SAFe. While the roles are similar in most respects, they operate at different levels of the solution and manage different concerns.
Product Management and Solution Management are the main content authority for the program and solution backlogs, respectively. They create the vision and work with customers to understand their needs, define requirements, and guide work through the solution and Program Kanbans. They 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, and system and software requirements specifications (SRS).
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 approach is driven in large part by that result.
We now understand that assumptions about requirements, design, and architecture all need to be validated through actual development, testing, and experimentation, and that teams must be open to emerging knowledge that can be quickly fed back into the solution . In SAFe, Continuous Exploration is the process used to continually explore market and user needs, and to define a vision, roadmap, and set of features and capabilities that address those needs.
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 new approach 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.
|Understand customer need||Up front and discontinuous||Constant interaction with the customer, who is part of the Value Stream. Other techniques include customer visits, Gemba walks, elicitation (ex., 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 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 Program Increment (PI) boundary via WSJF, constant scope triage|
|Validate requirements||Not applicable, quality assurance (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 (ART). For larger (multiple ART) Solution Trains, 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 ART 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 (DoD). 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 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 key technological infrastructures that will host the new business functionality. This can often best be accomplished 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 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 collaboration 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 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 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 much the same role that Product Management plays, but at the large solution level. There, Solution Management is part of a critical trio—Solution Management, Solution Train 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, ARTs and solution trains to understand needs and build and prioritize the solution backlog. They have similar vision, roadmap, solution Kanban, and solution demo activities as well.
Solution Management plays 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 Ries, Eric. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown Business, 2011.  Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
Last update: 20 October, 2017