Decentralize decision-making.
—SAFe Lean-Agile Principle #9
Product Management has content authority for the Program Backlog. These managers 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. These managers 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 chapter 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.
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 professionals in short, integrated learning cycles, Product and Solution Management bring the voice of the customer to the developers and the voice of the developers to the customer.
Following Principle #9, Decentralize decision-making, SAFe offers a chain of content authority that spans three levels:
Team – Product Owners make fast, local content decisions on behalf of the Agile Team.
Program – Product Management is accountable for content decisions for the Agile Release Trains (ARTs).
Large Solution – Solution Management has content authority for Solution Trains.
Product Management and Solution Management prioritize work using the Weighted Shortest Job First (WSJF) formula, schedule Features and Capabilities for Release using the Roadmap, validate customer response, and provide fast feedback.
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 created up-front, with an expectation that all the requirements could be established before the start of Solution development. This method had limited success, however, and its shortcomings were 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 on an ongoing basis and to define a vision, roadmap, and set of features and capabilities that address those needs.
Responsibility |
Traditional |
Agile |
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, and 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. Requirements often found in 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
As described in the Solution Intent chapter, some of the requirements of the solution are likely to be well understood and fixed from the beginning, while others are variable and can be recognized only 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 outlined in Table 1.
This 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, these managers 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 will 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. These managers are responsible for making sure that there are enough features ready in the backlog at all times. For example, they specify feature acceptance criteria that can be used to establish that a feature meets its Definition of Done (DoD). 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. These managers 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, these managers 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 chapter.
Participate in demos and Inspect and Adapt (I&A) events – The Product Management role is an active participant in biweekly System Demos, including the final system demo at the end of the PI. These managers 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 – Although 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.
The preceding section highlighted 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. Ultimately, the ability to build an effective solution depends on the quality of the collaboration between the two roles. This collaboration involves participating 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 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 the managers’ own 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 release readiness of their elements of the solution.
Solution Management plays a similar role to Product Management, but works 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. These managers have a similar vision, roadmap, solution Kanban, and solution demo activities as well.
The Solution Management, Solution Train Engineer, and Solution Architect/Engineering roles form 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. These managers 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. These managers 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.