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
- The product management mindset
- The role of Product Manager
- Team structure (TBD)
- The process
- External workflow with other IT teams
- Internal workflow (TBD)
- From MVP to MMR
Why Product Management
You need an effective approach to product management because you want:
- 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.
- 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.
- 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.
- 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:
- 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.
- 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 from beginning to end from the customer’s point of view – Product Management is about solutions and not just software.
- 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.
- 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.
- 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.
- 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.
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, as you see in this article 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.
The following process goal diagram overviews the potential activities associated with disciplined agile product management.
- 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).
- 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.
- 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.
- 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.
- 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.
- 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 see Managing Dependencies Between Agile Teams, Managing Dependencies Between Agile and Lean Teams, and Managing Dependencies Between Agile/Lean Teams and Traditional Teams.
- 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.
- 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 IT governance efforts.
External Workflow With Other IT 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.
The following table summarizes the workflows depicted in the diagram.
|Process Blade||Process Blade Overview||Workflow with Product Management|
|Solution Delivery||Addresses how to develop solutions in a disciplined agile or lean manner. This includes the lifecycles – basic/agile, advanced/lean, continuous delivery:agile, continuous delivery:lean, and exploratory – supported but DAD plus the program management blade (effectively a large team following one or more of the lifecycles).||Product management will provide a business roadmap and priorities that will guide prioritization decisions by the team. Product managers will also provide requirements to the team, working closely with your product owner to do so.|
|Continuous Improvement||Addresses how to support process and organizational structure improvement across teams in a lightweight, collaborative manner; how to support improvement experiments within teams; and how to govern process improvement with your IT department.||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||Addresses how to improve data quality, evolve data assets such as master data and test data, and govern data activities within your organization.||Product Management will provide business -oriented guidance to the data management activities.|
|Enteprise Architecture||Addresses strategies for supporting stakeholders; supporting delivery teams; evolving the enterprise architecture; capturing the enterprise architecture; and governing the enterprise architecture efforts.||Enterprise architecture will provide the technology roadmap to product management which is an input into evolving the vision for a product and identifying new potential features for products. Product management provides the business roadmap and stakeholder priorities to enterprise architecture which is used as input into evolve the enterprise architecture.|
|IT Governance||Addresses strategies for consolidating various governance views, defining metrics, taking measurements, monitoring and reporting on measurements, developing and capturing guidance, defining roles and responsibilities, sharing knowledge within your organization, managing IT risk, and coordinating the various governance efforts (including EA governance).||The IT governance efforts will provide guidance to the Product Management team.|
|Operations||Addresses how to run systems, evolve the IT infrastructure, manage change within the operational ecosystem, mitigate disasters, and govern IT operations.||Operational intelligence will be used by the Project Management team to provide insights into the effective of various marketing strategies.|
|Portfolio Management||Addresses how to identify potential business value that could be supported by IT endeavors, explore those potential endeavors to understand them in greater detail, prioritize those potential endeavours, initiate the endeavours, manage vendors, and govern the IT portfolio.||Product Management provides the business roadmap to portfolio management. The roadmap is used as input into identifying potential business value that could be supported by IT and into prioritization decisions.|
|Program Management||Addresses strategies for managing large product/project teams, allocating requirements between sub teams, managing dependencies between sub teams, coordinating the sub teams, and governing a program.||Product Management will provide a business roadmap and priorities that will guide prioritization decisions by the program. Product managers will also provide requirements to the program, working closely with your product owner team to do so.|
|Release Management||Addresses strategies for planning the IT release schedule, coordinating releases of solutions, managing the release infrastructure, supporting delivery teams, and governing the release management efforts.||Product Management will provide the business roadmap and priorities to the release management efforts so that their planning efforts reflect the direction of the overall organization.|
|Security||Addresses how to protect your organization from both information/virtual and physical threats. This includes procedures for security governance, identity and access management, vulnerability management, security policy management, incident response, and vulnerability management.||Product Management will provide the business roadmap and priorities to the Security team so that they can better understand the overall direction of the company, enabling Security to provide advice around potential threats regarding new or existing business strategies.|
|Support||Addresses how to adopt an IT support strategy, to escalate incidents, to effectively address the incidents, and govern the IT support effort.||Product Management will provide the business roadmap and priorities to the support team so that they can better understand the overall direction of the company.|
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.
This section is a work in progress.
For now, see The Product Owner Team which overviews how a product owner team works within a program. A product management team works in a very similar manner, albeit with a larger scope.
From MVP to MMR
Two of the key aspects of the Disciplined Agile mindset for Product Management are to take an experimental approach and to release a product incrementally. Experimentation is supported through the development of Minimal Viable Products (MVPs) and incremental releases via Minimal Marketable Releases (MMRs). These concepts, and more, are overviewed in the following diagram.
Let’s define what these terms mean:
- Minimal 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.
- Minimal 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 or MMP.
- Minimal 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.
- Minimal Marketable Product (MMP). An MMP is the first deployment of a Minimal Marketable Release (MMR). Having said that, the terms MMP and MMR are often used interchangeably. An MMP is aimed at your initial users, typically innovators and early adopters. The key is develop and MMP for the few, not the many, and thereby focus on the key features that will delight this core group of people. An MMP is a tool to reduce the initial time to market because it can be developed faster than a feature-rich product.
For a more detailed discussion, please read Defining MVP, MMF, MMP, and MMR.