Here are the main practices of the Product Manager:
- Keeping the enterprise Business-strategy area connected with its development area
- Developing working relationship with stakeholders and Business strategists
- Continuing the initial cooperation from developing a capability
- Giving status of important findings from the development effort
- Answering questions from the Product Ownerss about stakeholder value
- Passing questions to strategists (Business Owners/Sponsors) for which the Product Manager has no answers
- Representing the stakeholders to the implementers; assigns and works with the Product Owner
- Participating in value stream planning events (see meetings)
- Presenting the vision for capability to be delivered by the organization during planning and list the major known features
- Assessing the Business value of the team objectives
- Setting the vision
- Writing vision statements and charters for product and releases
- Presenting the vision for a capability to be delivered by the organization during planning and list the major known features
- Specifying the Business value to be developed
- Managing the value stream (e.g., Program) Backlog
- Owning scope, timeline, and priority
- Populating the backlog
- Putting capabilities into the Value Stream Backlog
- Decomposing capabilities into MBIs; putting them into the Value Stream Backlog
- Prioritizing
- Estimate the relative effort expected to be required to implement capabilities (first), then MBIs as they are decomposed from the capabilities
- Apply a prioritization technique to put the MBIs in order of importance to organizational goals
- Use Weighted-Shortest Job First (WSJF) technique, or alternative such as Analytic Hierarchy Process (AHP) or MODA (Multiple-Objective Decision Analysis)
- Estimate a “cut-off line” above which completion is currently believed possible with available resources (time, teams, etc.), and below completion is not expected
- Monitoring
- Stay aware of how the teams are doing at implementing the MBIs and their features. A burn-up chart is recommended, because it allows showing changes in the team’s capacity (the top, “target” line on the chart) during an iteration.
- Note: the team may have a percentage of its capacity allocated for tasks that don’t come from the team backlog; the PO is not responsible for these kinds of work. The PO should stay aware, though, of whether the team is spilling over that part of their capacity, and encroaching on the capacity they’ve allotted for work on the main value items. Examples include:
- Changes
- Internal projects (e.g., design refactoring; technical-debt retirement; porting to a platform update)
- Unplanned work (e.g., “shoulder-taps,” expedites)
- Participating in Product Demonstration and Review events to stay aware of the acceptability of the parts of the system under development, towards eventual delivery of the system as a whole
- Maintaining
- Update the Value Stream Backlog as the situation changes
- Adjust the “cut-off line” as needed
- Add new items or modify existing ones based on feedback from stakeholders and learning happening in the team (e.g., Feature-level NFRs discovered to be needed during the iteration development work), etc.
- Intervening
- If the “cut-off line” is considered to be too high, work to
- Reduce the scope of MBIs (“is there any way to deliver less and it still be seen as value?”)
- Redefine capabilities and MBIs for easier/faster implementation with cooperation of the Business Owners and Sponsors, and other high-level stakeholders
- Work with the Product Owner to help a team recover when its implementation is rejected at its Product Demonstration and Review event. (This is proactive by the Product Manager to help the entire system be acceptable by the Iteration Demonstration and Review.)
- Accept or reject backlog items at the Product Demonstration and Review
- Assessing product acceptability
- Defining acceptance criteria and evaluating product against them
- Assessing product acceptability
- Approving or rejecting product releases
- Managing the release
- Make decisions about when to create an official release. For a variety of reasons, it may not be desirable to release at the conclusion of every increment. The Product Manager makes these decisions in a manner consistent with the investment vision that has been established for the project.
- Helping the flow of Business value
- Resolve Business-related impediments
- Review information visibility charts
- Read the information visibility boards for signs of problems with the iteration for signs of failing agility
- Provide Lean-Agile thought leadership
