It is clear to me that you need serious professional help.

– Author’s ex-wife

Product Management Abstract

The Product Management function is responsible for defining and prioritizing the program backlog—the single backlog that drives the program’s value delivery. It is important to note, however, that there is often an agile rollout adoption challenge with the apparently overlapping responsibilities of the Product Manager and an agile team’s Product Owner. In Scrum, the product owner has full product responsibility, which includes securing funding, managing to ROI objectives, release planning and more. But that is typically not the case in the enterprise, as these responsibilities more typically fall to a more market and business-facing product manager or business analyst, who may not be directly a member of the software development team. We’ll also need to map the titles to those who share these responsibilities in companies who do not think of themselves as delivering products to market. Executing this role is different in an agile environment as well, so we’ll highlight some of the key differences. Finally, we’ll specifically describe the key responsibilities of those who fulfill this role in the context of SAFe.

Details

Summary Role Description

The Product Manager serves as the “content authority” for the release train and is responsible for defining and prioritizing the Program Backlog, and working with Product Owners to optimize Feature delivery to the customers in balance with the enterprise’s technical and economic objectives.

Division of Responsibilities between Product Manager and Product Owner

As we described, we take a “dual role” approach to the agile product management/product owner function in the larger enterprise. The specific responsibilities of each are further described and delineated in the Product Owner Details.

Product Manager/Business Analyst?

The framework is intended to have broad applicability, and while the responsibilities we assign to a specific role/title are what make the framework effective, the title that others use may well be different. This is particularly important with respect to the product management role, as this role serves as the “chief content authority” for what gets built. We can’t afford any ambiguity about that. In addition, the titles for this role and the differing, specific responsibilities largely fall into two categories:

Product oriented companies, including independent software vendors (ISV), and embedded systems (ES) developers. In this case, the title of product manager is typical, but the role may also be filled by other titles such as solution manager, system engineer, or program manager. The Product Development and Management Association (PDMA) generally attributes the following responsibilities to this role: discovery, and customer and market research; development activities, commercialization; technology and intellectual property management; product strategy, planning and decision making; product management organization and team relationships, co-development and alliances, process execution; and metrics (both financial and other).

Information Systems (IS)/Information Technology (IT). In these companies (and in-house departments in the companies above), the most common title associated with these responsibilities is Business Analyst, in which case those fulfilling this role typically help the company meet its business objectives via:

• Developing, deploying and maintaining new software systems for internal use
• Installing, configuring and maintaining commercial off-the-shelf software
• Integrating internal developed solutions with acquired solutions and external partners

The International Institute of Business Analysts (IIBA) generally attributes the following responsibilities to this role: business analysis, planning and monitoring; needs discovery, requirements elicitation, management and communication; enterprise analysis; and solution assessment and validation.

What’s Different About This Role in Agile?

We note that the above definitions reflect a traditional view of the major responsibilities for the role, which is appropriate in the larger business context. However, we also note that current IIBA and PDMA guidance often assumes an implied waterfall paradigm, so while the functions may be largely the same, the way in which this role is fulfilled is quite different in agile, as the following table summarizes:

Product Manager Responsibilities

No matter the title, no matter the amount of change, the SAFe product manager has the following responsibilities.

1. Work with Portfolio Management to determine priority and business objectives. At the Portfolio Level, a kanban system is used to bring visibility to upcoming business epics. Discussions with portfolio management about the priorities, business or market impact or opportunity, and development impact for upcoming business epics is integral to the development of each business case. As such, the product manager is typically an active member of the extended Portfolio Management Team, where they participate in decision-making about the key economic drivers for future releases.
2. Work with system architects to understand architectural epics. In a similar fashion, while product management is not expected to drive technological decisions which those are better left to the more technical teammates and those responsible for actual implementation, they are expected to understand the scope of the upcoming architectural work, and to assist with decision-making and sequencing with respect to implementation of the key technological infrastructures that will host the new business epics.
3. Own and communicate the program vision. Product management is the “content authority” for the release train, and has the responsibility to define the what for each release train solution. Determining the what is the primary skill for the role. This typically includes market and user needs analysis, working with key internal and external stakeholders, and synthesizing the (sometimes competing) requirements into a single, common Vision for the program (See Chapter 12 of Agile Software requirements: Requirements Discovery Toolkit for tips and techniques). Once established, the product manager must continuously communication the Vision to the development teams. Since requirements documents typically take a lesser role in agile, this is most typically done via a series of rolling wave vision briefings, which highlights the proposed features of the solution, and which is delivered at each PSI planning session. However, the teams will appreciate any documentation highlighting significant use cases, user scenarios, relevant standards, nonfunctional requirements etc. that may be necessary to further their understanding prior to breaking the features into stories for implementation.
4. Manage the program backlog and PSI release content. Owning the what means that product management is uniquely responsible for the content of the program backlog, the backlog that contains the business and architectural features that will constitute the future instantiation of the solution. This may include classes of service for new features and architecture, and when necessary, may even include allocations for technical debt that has been incurred through legacy development. And since judicious selection and sequencing of features is the key economic driver for each program, this backlog will be groomed and reprioritized with WSJF prior to each PSI planning session. Product management also defines and maintains the nonfunctional requirements (backlog constraints), to help assure the solution meets relevant standards and other system quality requirements.
5. Participate in regular release planning, release management, and solution validation. We often describe the ART as a fractal above the agile teams. As such, the product manager is to the release train what the product owner is to the team, and that implies substantial ongoing interaction during the development of the solution. In addition to owning the vision, product management (or a senior representative) is likely to participate on the release management team, or other mechanism for scope triage. In addition, product management is involved with the aggregated sprint demos, and participates heavily in PSI level demonstrations, evaluation of business value achieved versus plan, and in the Inspect and Adapt workshop used to continually improve program performance.
6. Maintain the Product Roadmap. The roadmap is updated as needed, but is specifically refreshed at the end of each planning event, at the time when the program commits to the objectives for the next PSI. The roadmap contains a high level view of the marquis features, those key deliverables that need to be communicated to customers and other stakeholders. Each roadmap should demonstrate very high confidence plan for the next PSI, a solid plan of intent for the PSI after that, and thereafter, whatever futures can be predicted or forecast based on current program reliability, as well as any business pressures applied to attempt to predict an uncertain future.
7. Build an effective Product Manager/Product Owner Team. Lastly, the Framework is a system, and it only works if all the parts of it work. Though the product owner and product manager roles are separate and report to different internal organizations, forming an effective extended product manager/product owner team is the key to efficient and effective development, not to mention the inherent job satisfaction that comes with being part of a high performing team who routinely delivers on its quality and vision commitments. As the ultimate content authority in the enterprise, product management takes a lead role in implementing the organizational, management and communication practices necessary to achieve business results.

Learn More

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

Last Update 15 January, 2013

© 2010-2013 Leffingwell, LLC and Pearson Education, Inc. All rights reserved.