Disciplined Agile

Product Management

Product Management

The Product Management process blade includes the acts of identifying and evolving your organization’s business vision; of identifying and prioritizing potential products/solutions to support that vision; of identifying, prioritizing, and allocating features to products under development; of managing functional dependencies between products; and of marketing those products to their potential customers. Disciplined agile product management is product management performed in a collaborative and evolutionary manner that reflects the context of your organization.

This article addresses several topics:

Why Product Management

You need an effective approach to product management because you want:

  1. To build the right product(s). You will always have many more ideas for products than you can possibly fund. Your product management team will need to prioritize the ideas for potential products so that they can focus on the ones that will provide the most value to your organization.
  2. To stop building the wrong product(s). Product managers will monitor the work of development teams, ongoing experiments, and even existing solutions running in production to determine their effectiveness. Products that aren’t effective must either be evolved or cancelled to enable you to focus on high-value products.
  3. The right product features at the right time. When there are many delivery teams working in parallel there will be functional dependencies between the solutions/products being worked on. These functional dependencies need to be taken into account when the work is being prioritized so that the right functionality is available when it is needed.
  4. To ensure that people use the product. Part of product management is marketing to potential end users/customers. If people don’t know that functionality is available to them then they are unlikely to use/buy it.

 

The Disciplined Agile Product Management Mindset

Building on the ideas captured by the Disciplined Agile Principles and the Disciplined Agile Manifesto, there are several agile/lean philosophies that are critical to success in Product Management. These philosophies are:

  1. Be customer driven. The needs of customers, and more importantly the potential desires of customers that they are not even be aware of, should drive your Product Management decisions. The implication is that Product Managers must work closely with existing customers, and furthermore must invest time to identify and understand potential customers so as to grow the market for their product.
  2. Address the full value stream. An important part of being customer driven is to understand that it is the full customer experience with your organization, not just the “products,” that must be addressed. You need to understand the full value stream(s) that your product(s) are part of from beginning to end from the customer’s point of view — Product Management is about solutions and not just software.
  3. Take an experimental approach. People often don’t know what they want, will struggle to describe what they want, often won’t tell you want they want, and will change their minds anyway. The point is that you need to go beyond asking people for their requirements if you want to identify what to offer your customers. Modern thinking is to take an experimental approach via creation of minimal viable products (MVPs) to get something in front of potential customers to determine what they actually want — you do this through observing the features of your MVP that they use, how they use them, and the features that they don’t use. This strategy was popularized by Eric Ries via his Lean Startup work and is captured in DAD’s Exploratory lifecycle.
  4. Release incrementally and often. Releasing smaller increments more often enables you to reduce the feedback cycle with your customers, which in turn enables you to learn quickly and thus react to customer needs faster.
  5. Embrace change. Customer needs and desires change, often rapidly. New competitors enter the market with different or improved offerings. New technologies and platforms are introduced and then evolved. To be trite, the only constant is change. Successful product managers not only accept this but they embrace it. The implication is to adopt flexible, light-weight strategies.
  6. Plan strategically and react tactically. Products should be planned strategically in the long term yet implemented tactically in the short term. The common agile strategy is to take a what is known as a rolling wave planning approach where detailed planning occurs for what should be delivered in near team incremental releases but for future releases the planning is high-level and less detailed the further in the future something is.

 

The Role of Product Manager

The role of Product Manager is strategic in nature. They should be focused on the long-term vision for the product, on observing trends in the marketplace, on identify new potential outcomes or themes to be supported by the product, and on ensuring the product meets the needs of the value stream(s) the product is involved with. Effective Product Managers tend to be very customer focused, although recognize that this needs to be tempered by the constraints and capabilities of your organization.

As you can see in the following diagram, the role of Product Manager is different, yet overlapping, with that of a Product Owner (PO). Where Product Managers are strategic Product Owners tend to be more tactical in practice. POs work closely with delivery teams to ensure they build the right functionality in a timely manner. POs will transform the high-level vision of the Product Manager into detailed requirements. To do this they work closely with a range of stakeholders for the product, including non-customer stakeholders such as finance, security, operations, support, audit, and others.

Figure 1. Product Owners and Product Managers

Product Owners and Product Managers

 

Some people, particularly those focused on Scrum, will tell you that Product Owners should also be focused on strategic issues. This is certainly true in simple, non-scaled situations. And certainly it’s good for POs to understand the long-term strategy for the product that they are focused on. But, there is far more to Product Management than just software development. Furthermore, the day-to-day work with the delivery team, in addition to the day-to-day work required for look-ahead modelling and planning (what Scrum refers to as backlog refinement) with stakeholders, can be more than a full-time job for Product Owners in and of itself.

 

Process

The following process goal diagram overviews the potential activities associated with disciplined agile product management.

Figure 2. The Goal Diagram for Product Management


Product Management Goal Diagram 

The process factors that you need to consider for product management are:

  1. Evolve business vision. Product managers will work closely with stakeholders, and in the case of new products/solutions potential stakeholders, to understand their needs. The goal is to develop roadmaps for individual products, product lines, and for the business itself. These roadmaps describe the current vision for the near term, intermediate term (3-12 months), and long term (one year or more) with less detail the further out in time the roadmap goes. These roadmaps help the product managers to guide their prioritization decisions and provides input into the planning activities of other efforts (such as the Enterprise Architecture and Portfolio Management activities).
  2. Explore potential products. Product managers want to identify potential products that will provide significant value to your organization. They may do this via a variety of means, including the more traditional approaches of building a business case to more agile/lean strategies such running a small experiment.
  3. Prioritize potential products. There will be many potential products that your organization would like to invest in, but a limited budget to do so. The implication is that only the highest priority products will be developed, and therefore need to be prioritized appropriately.
  4. Evolve business roadmap. The business and/or product roadmap is developed and evolved by your product management activities. Traditional strategies tend to take either an annual or ad-hoc approach whereas more disciplined agile strategies take more of a rolling wave approach.
  5. Allocate features. Features — which could be captured as outcomes, epics, stories, feature statements, or other forms — will need to be allocated to delivery teams so that they may be implemented. These features will need to be prioritized by the product managers (who are often in the role of Product Owner on the delivery teams) so that the teams know the order in which to implement the functionality.
  6. Manage functional dependencies. Functional dependencies often exist between products, due to the usage of common platforms and the need for integrated solutions, and these functional dependencies need to be managed. The product managers will want to manage these dependencies so as to optimize when functionality is implemented and released into production. For more information on dependency management strategies, please seManaging Dependencies Between Agile TeamsManaging Dependencies Between Agile and Lean Teams, and Managing Dependencies Between Agile/Lean Teams and Traditional Teams.
  7. Market products. Product managers will market their products to their potential customer base to increase the usage of the products. The need for such marketing is clear in the case of commercial products and other types of solutions intended for public use. Marketing is also needed for solutions developed for internal usage to increase the chance that the potential user base knows about the existence of the (upcoming) release of the product.
  8. Govern products. Product managers will want to monitor how successful their products are (e.g. monitor actual ROI, market adoption rates, end user satisfaction) as well as how well the products are being evolved (e.g. are you continuing to invest in successful products). Product governance is one aspect of your overall governance efforts.

 

External Workflow with Other Teams

The following diagram overviews the major workflows that your disciplined agile product management activities are associated with. Note that feedback is implied in the diagram. For example, where you see the Business Roadmap and Priorities flow from Product Management to Portfolio Management there is an implied feedback loop from the portfolio managers to the product managers. Also note that the workflows do not necessarily imply that artifacts exist. For example, some of the work items provided to solution teams may be via discussions with their product owners.

Figure 3. The External Workflow of Disciplined Agile Product Management.

Product Management Workflow

The following table summarizes the workflows depicted in the diagram.

 

Process Blade

Workflow with Product Management

Continuous Improvement

The continuous improvement activities will provide potential improvement suggestions for improving enterprise architecture efforts. Similarly, the Product Management team may have insights to share with the rest of the organization.

Data Management

Product Management will provide product data to the data management activities, which in turn provides intelligence about the marketplace and your organization’s activities.

Disciplined Agile Delivery

Product management defines minimum business increments (MBIs) for delivery teams to work on, and provide product roadmaps to help guide prioritization decisions made by the team.

Disciplined DevOps

Product management provides product roadmaps to various DevOps activities, such as data management and IT operations, as input into their prioritization and planning decisions.

Enterprise Architecture

Enterprise architecture will provide the organization-level business and technology roadmaps to product management which is an input into evolving the vision for a product and identifying new potential features for products. Product management provides product roadmaps which is are as input into evolve the enterprise architecture.

Governance

The governance efforts will provide guidance to your product management activities.

Portfolio Management

Product Management provides product roadmaps to portfolio management, which are used as input into identifying potential business value. Portfolio management provides funding for valuable initiatives identified by product management.

Program Management

Product Management will provide product roadmaps and definitions of MBIs for a program team to work on.

The activities associated with these process blades are often very highly related. For example, in some organizations the activities associated with product management and portfolio management are fulfilled by a single group. In other organizations some product management activities are performed by the portfolio management team and some by the enterprise architecture team. Some organizations may be large enough that it makes sense to choose to have a separate group for product management. And of course the organizational structure will evolve over time as your various teams learn how to work with one another.

 

From MVP to MMR

Two of the key aspects of the DA mindset for Product Management are to take an experimental approach and to release a product incrementally. Experimentation is supported through the development of Minimum Viable Products (MVPs) and incremental releases of value by Minimum Business Increments (MBIs). These concepts, and more, are overviewed in Figure 4. 

Figure 4. The relationship between MVP, MBI, MMR, and MMF.

MVP Chart

Let’s define what these terms mean: 

  • Minimum Viable Product (MVP). An MVP is a version of a new product that is created with the least effort possible to be used for validated learning about customers.  MVPs are used to run experiments to explore a hypothesis about what your customers really want.  They are much closer to prototypes than they are to the “real” running version of your end product.  A development team typically deploys an MVP to a subset of your (potential) customers to test a new idea, to collect data about it, and thereby learn from it.  MVPs are created to help you to find the features that customers are actually interested in. 
  • Minimum business increment (MBI). An MBI is the smallest piece of functionality that can be realized by a customer (internal or external) that is consistent with the strategy of the business and makes sense to deliver when transaction costs are considered.  An MBI adds value for your customers and provides valuable feedback to the product team that the right functionality is being built and is being built in the right way.  An MBI provides functionality that can be delivered and which can also be validated as being useful and it enhances the ability of the organization to deliver value in the future. An MBI is a solution that contains all of the pieces that are required for value realization.  An MBI, when it is done right, is both an MMF and an MMR.
  • Minimum Marketable Feature (MMF). An MMF is the smallest piece of functionality that can be delivered that has value to both the organization delivering it and the people using it.  An MMF is a part of an MMR.
  • Minimum Marketable Release (MMR).  Successful products are deployed incrementally into the marketplace over time, each “major” deployment being referred to as a release.  An MMR is the release of a product that has the smallest possible feature set that addresses the current needs of your customers.  MMRs are used to reduce the time-to-market between releases by reducing the coherent feature set of each release to the smallest increment that offers new value to customers/end users. An MMR is one or more MBIs. 

In DA, we prefer to focus on the terms MVP and MBI because when you’ve streamlined your way of working (WoW) you discover than an MBI is an MMF that you release (so it’s also an MMR).  Concepts like MMF and MMR are steps along the path to MBIs. For a more detailed discussion, please read Defining MVP, MBI, MMF, and MMR