![400](../pics/apm-product-portfolio-team.png)
Agile Product Management
Introduction
Small and medium-sized enterprises often struggle with the implementation of digital product management.
They have a heterogeneous portfolio of products targeting their customer segments. The development capacities are limited and shared between the products. Often a team is responsible for the development and support of multiple products.
The digital products have different life cycles and customer segments. They are often implemented with different technologies and development stacks [1]. Life cycles are strongly influenced by the customer segments, the technology stack, and the architecture [2].
The organization has to optimize the development capacities to maximize the value for the company. The product portfolio manager is responsible for the overall strategy and the alignment of the products [3]. She must allocate the limited development capacities to the most successful products.
Indirectly, she is responsible for a reasonable distribution of the realization capacities between the development teams. Smaller companies cannot afford idle developers.
The organization has to answer the following questions:
-
How shall the requirements elicitation, consolidation, prioritization, and implementation be performed?
-
How shall the product roadmaps and releases be organized?
-
How can the development capacities be optimized? Who should transform the product requirements into technical requirements?
-
How shall the architecture and technology stacks be managed?
-
How shall the tracking and feedback be implemented?
We present a pragmatic approach to solve these challenges. The approach scales up to eight development teams or around eighty developers.
The number of digital products is not limited. Prefer grouping similar offerings in a generalized product. Try to have less than five product families in the portfolio.
The approach is tailored for digital product companies.
Engineering services companies have different challenges and require a different approach. Services companies have no digital products. They only deliver services to their customers.
Portfolio Management Process
Portfolio
A product portfolio is a group of products. These might be end-user-facing or internal solutions like a software platform. They might directly generate revenue or support commercial offerings.
A product family is commonly defined as a group of related products. You can therefore view it as a cohesive product portfolio, a portfolio whose members have related value propositions and business goals.
The product family contains a set of digital modules to define the variants.
Beware that configurations are not product variants. Configurations are customer-specific settings requiring engineering activities and impeding the scaling of sales [4].
You should handle all product variants as a single product.
An effective product portfolio strategy should contain the following five elements.
- Vision and Strategy
-
An overarching vision that describes its purpose, the positive change it should bring about. The product vision describes the product’s purpose, the ultimate reason for creating it, and the positive change it should bring about.
The strategy is a tentative plan to achieve the vision. - Target Groups
-
The markets and market segments the portfolio serves.
Products with overlapping target groups are often an indication for a lack of focus. - Needs
-
The overall value it creates for the users and customers.
- Product Portfolio
-
The business benefits it helps achieve.
- Business Goals
-
The type of products it contains with the capabilities that set them apart from competitors.
The portfolio is the main instrument to align the organization to the common strategy, objectives, and goals [1].
Product Portfolio Manager
The portfolio product manager is responsible for all products in the portfolio. She decides the content of the portfolio backlog, the release plan, and the priority associated with the backlog items.
Ban the word project from your company’s vocabulary. Customers buy products, not projects [4]. |
The individual should have a track record of successfully managing products similar to the ones contained in the portfolio. Additionally, they will benefit from having the right leadership skills, be able to guide a group of product people, collaborate with senior stakeholders, and engage with senior management.
No matter which option you choose, it would be a bad idea if a single person made all portfolio decisions on their own. This would waste the knowledge and creativity of the people working on the individual products.
What is more, it might cause poor alignment and weak buy-in. I recommend a collaborative approach that involves the following individuals:
-
The product portfolio manager. He might be the head of the product development department.
-
The individuals managing the products contained in the portfolio.
-
Development team representatives which might include a UX designer for end-user-facing products, an architect, and senior developers.
-
Key stakeholders, for example, a sales representative, or customer support team member.
![400](../pics/apm-product-portfolio-team.png)
The following artifacts shall be created and maintained:
- Overall strategy for the organization
-
Ideally, the board of directors and senior management have defined and approved the company strategy.
- Vision and strategy of the product portfolio
-
It is used for the active and continuous management of the portfolio. A strategy has a customer focus and a technological focus. Align the product and modules accordingly to the vision.
- Portfolio of all products
-
The products should be prioritized. Each product has a different and published priority. Document the reasons for the priority.
- Roadmap and release plan
-
All products and modules should be aligned with the portfolio release plan to reduce the coordination effort. A roadmap has a horizon of twelve to eighteen months. A release plan has a horizon of six to nine months.
Experiment with quarterly releases. - Portfolio backlog
-
A single backlog for all products is maintained. The features are implicitly prioritized.
The strategy stack below displays the relationship between the organization strategy, the product portfolio strategy, and the product strategy.
![400](../pics/apm-strategy-stack.png)
Review and update the documents monthly. If your target market is slowly moving, you might be able to extend the review cycle to once every quarter.
A pragmatic roadmap and release plan will be:
|
Requirements Elicitation
Requirements Gathering
Each product has a product manager responsible for the requirement gathering for his products. She can delegate the gathering to team members or stakeholders. Technical support collaborators should often be involved in the requirement gathering.
She still has the responsibility for the product requirements. A product manager can be in charge of multiple products.
The product manager is responsible for:
-
The vision of the product
-
The roadmap of the product
-
The release plan of the product
-
The product backlog as a set of epics and related features. Any stakeholder or development team member can suggest a feature and add it to the product backlog. The product manager is responsible for accepting and prioritizing the features.
![400](../pics/apm-requirements-elicitation.png)
A feature represents functionality that delivers business value, it fulfills a stakeholder need. It is sized to be delivered by the development teams within a release interval. An epic is a set of related features that deliver a business value.
The below diagram shows the relationship between the products and the portfolio requirements. The product artifacts are the inputs for the portfolio artifacts.
The portfolio documents are the basis for the implementation of the product features. The portfolio manager uses the artifacts to align the company and optimize the generated value.
The product owner proxy translates the product features into technical requirements for the development teams. She is responsible for the traceability between the product features and the technical requirements. She coordinates with the portfolio manager to ensure that the development capacities are efficiently allocated. The coordination is more intensive and complex if the development teams are organized as component teams [5].
The development resources are shared between the products.
![400](../pics/apm-roles.png)
Try to create customer journeys for each product. Invest time in the user interface design. Stop solely collecting requirements. Invest effort in understanding the customer needs and the customer journey [5]. |
Each feature shall be associated with a tentative release date or tentative release version.
All these features are added to the organization product backlog. Once a month, the organization product owner consolidates the individual product backlogs into the organization product backlog. The consolidation is a collaborative effort between the organization product owner and the product managers.
Beware either the release date is fixed and the functionality is variable or the functionality is fixed and the release date is variable. You cannot fix both without compromising the quality of the product. |
Ideally, the backlog items are grouped to minimize context switches between products when the development team implements backlog items during an iteration.
Before making any decision, ask questions, for example:
|
The product roadmaps and release plans are synchronized with the organization portfolio roadmap and release plan. These documents should be reviewed quaterly.
Avoid becoming a feature factory. It describes a business focused on building features rather than solving problems for customers. Here are a few characteristics of a feature factory:
Focus on learning instead of planning and blindly executing. |
Requirement Consolidation
All product related features are added and consolidated to the organization product backlog. The portfolio product owner is responsible for the consolidation of the individual product items. Making these choices requires you to say no to ideas and suggestions.
The portfolio product owner collaborates with the product managers and stakeholders to prioritize the features. The final decision is made by the portfolio product owner [7, 2, 8, 9].
Without decision power, a product manager cannot thrive.
![400](../pics/apm-strategy-stack-and-ownership.png)
While I have described the connections between the layers top-down, changes in a lower layer can trigger adaptations in a higher one. Say that the portfolio strategy turns out to be wrong, then this may require changing the business strategy. To put it differently, the relations between the layers are bidirectional.
Prioritization
The prioritization of the features is based on the following artifacts:
-
Roadmap describing up to 18 months of product development.
-
Release plan describing up to 9 months of product development.
-
Customer journey describing the customer interaction with the product.
Prioritization is a tactical decision without strong strategic implications. The goal is to maximize the value of the product for the customer and the income of the organization.
Refinement and Implementation
The product owner proxy translates the features into technical requirements for the component teams. She is responsible for the traceability between the product features and the technical requirements.
The product owner proxy is the product owner role in the SAFe framework.
Acceptance criteria shall be formulated for each feature. The acceptance criteria are used to validate the implementation of the feature. Ideally, the acceptance criteria are formulated as automated acceptance tests.
A product owner proxy is necessary if the development teams are organized as component teams. A component team is specialized in a specific technology stack or a specific domain.
The product owner proxy takes over the responsibility of a technical team manager and of a requirement engineer.
Ideally, the product managers shall grow their capabilities to formulate clear and concise user stories. A user story should be SMART and INVEST compliant. Do not fall in the You aren’t gonna need it trap.
The size of a team backlog should be limited to provide work for two iterations. |
The developers should deepen their understanding of the customer domain and how their products are used.
The optimal solution is to make the product owner proxy obsolete. This transformation requires a significant investment in training and coaching. The specialized component teams must be transformed into cross-functional feature teams. A cross-functional team is able to refine a customer requirement, implement the functionality, and deliver the solution to the customer.
The architect shall be involved in the refinement of the technical requirements.
Ideally, a user interface specialist should be involved in the refinement of the user stories.
The architect is responsible for the overall architecture and technology decisions. She should influence the technical requirements to ensure that the overall architecture is not compromised. An evolvable architecture is a key success factor for digital products and has life cycles of more than five years. The most frequent flaw of digital products is the lack of high-quality user interfaces. |
Architecture and Technology
Software architecture is about all important design decisions that are hard to change. Architects concentrate on design decisions that have a high impact on the costs of the system.
Architecture and design are a continuous process to achieve technical excellence [10, 11]. Specification by example is a key practice to ensure that the architecture is implemented as designed. Automated acceptance tests and continuous delivery are key practices to validate and verify the solution.
Non-functional requirements can also be validated with fitness functions and automation [10].
![400](../pics/apm-architecture-design.png)
Examples of software architecture decisions are:
-
Technical stacks
-
Technical debt management
-
Overall software architecture
-
DevOps and SecDevOps
Consider documenting all architecture decisions as Architecture Design Records ADR. These decisions have a high impact on the cost, maintainability, and the availability of the system.
Tracking and Feedback
The product owner proxy translates a feature requirements into a set of component backlog items a specific team should implement. She is responsible to provide traceability between portfolio requirements and technical requirements.
The implementation efforts of technical work packages should be tracked to provide information about the implementation costs of a feature.
The realization team shall provide:
-
Traceability between backlog items, features and epics
-
Effective effort at backlog item level
-
The effort for a feature or an epic is the aggregated value of the effort for the related backlog items. This approach works if a feature always belongs to a single product.
The effort data is available for inferring development costs for a product, a release, an epic, or a feature.
Never use the estimated or effective effort data for performance evaluation. Otherwise, the data will be manipulated and become meaningless. |
DevOps
Modern digital products development requires a DevOps approach [4] [5]. The three major DevOps platforms are GitHub, GitLab, and Azure DevOps.
Invest in the structure of your backlogs and products in the DevOps platform. Define and document your custom fields and tags to support the product management process.
A regular hierarchy is:
-
Epics and features for the products and portfolio backlog. An epic has a set of features.
-
Product backlog items and stores as the refinement of features. A feature has a set of product backlog items. If useful, a product backlog item has a set of tasks.
-
Issues are analogous to product backlog items or tasks. A product backlog can be an issue or have a set of issues.
-
Use tags to categorize all items.
-
Add custom fields to support the product management process.
Any item can be associated with milestones and releases. Any item can be associated with iterations and teams.
Azure DevOps Supports all major items of the product and portfolio management process.
Your organization will need to experiment to find the best fit for your processes. Prefer to adapt your processes to the platform capabilities instead of customizing the platform. A big decision is to have one backlog for all products or one backlog per product. The definition of organizational tags is another area of experimentation. More configuration effort is necessary to define the custom fields to support effort tracking and reporting. You will need to invest in training and coaching to ensure that the product managers and product owners are able to use the platform effectively. You will need to create custom reports to extract key performance indicators. Beware that involved collaborators need an individual user license for the platform. |
Checklist
-
A product has one product manager.
-
A product has a vision and a strategy.
-
A product has a roadmap and a release plan.
-
A product has a list of prioritized epics and features. Use tags to categorize the features specific to a module. The feature has a tentative release date or milestone.
-
A portfolio has a portfolio manager.
-
A portfolio has a vision and a strategy.
-
A portfolio has a roadmap and a release plan.
-
A portfolio has a list of prioritized features and stories.
-
A development team has a product owner proxy [6].
-
A development team has a list of refined and prioritized technical requirements.
-
The list of technical requirements is traceable to the product features.
-
The amount of work to implement the list of defined technical requirements is around two iterations.
-
A product backlog item has an identifier, a name, a description, a priority, and an optional estimation. Functional items have acceptance criteria. Acceptance criteria are formulated as automated acceptance tests [7].
-
The effective effort to implement a technical requirements is tracked.
-
The start and end date for the implementation of a technical requirement is tracked.
-
Acceptance criteria and acceptance tests are available for each story or feature. A trace is available between the acceptance criteria and the acceptance tests. Before each release, the acceptance tests are executed and the results are documented [8].
Terminology
Agile | SAFe | LeSS | Disciplined Agile |
---|---|---|---|
Portfolio |
Agile Train |
Product |
Portfolio |
Product Manager |
Business Owner |
Product Owner |
Product Manager |
Portfolio Manager |
Product Manager |
Product Owner |
Product Manager |
Product Owner Proxy |
Product Owner |
Product Owner |
Product Owner |
Architect |
System Architect |
Developer |
Architecture Owner |
Train Engineer |
Release Train Engineer |
Scrum Master |
Team Lead |
LeSS states that one product owner should be responsible for one broad product. One product owner can manage up to eight development teams. The number of Scrum Masters is between one and three based on the maturity of the teams. Product owner proxy roles are strongly discouraged.
SAFe states that one release train should have at least seventy train members. A train has a train engineer, a product owner, and a system architect. Each team has a team coach and a product owner. Product owner proxy roles are standard.
Disciplined Agile follows mainly the terminology or Roman Pichler. The Disciplined Agile framework is sponsored from Project Management Institute and is less common in Europe.
Be pragmatic. Think big and start small. Emphasize principles and good practices. Each product should have one product manager. But a product manager can handle multiple products. The portfolio manager should be responsible for the overall strategy and the alignment of the products. Add additional roles as needed. Often you will initially need a technical product owner proxy and a senior designer. |
References
[1] S. Sinek, Start With Why. Penguin Books Ltd, 2011 [Online]. Available: https://www.amazon.com/dp/B005JZD3B4
[2] R. Pichler, Agile product management with Scrum. Addison-Wesley, 2010 [Online]. Available: https://www.amazon.com/dp/0321605780
[3] R. Pichler, Strategize. Pichler Consulting, 2016 [Online]. Available: https://www.amazon.com/dp/0993499201
[4] M. Kersten, Project to Product. IT Revolution Press [Online]. Available: https://www.amazon.com/dp/1942788398
[5] J. Patton, User Story Mapping. O’Reilly and Associates, 2014 [Online]. Available: https://www.amazon.com/dp/1491904909
[6] C. Alvarez, Lean Customer Development. O’Reilly Media, 2014 [Online]. Available: https://www.amazon.com/dp/1492023744
[7] R. Pichler, How to Lead in Product Management. 978-1-9163030-0-3, 2020 [Online]. Available: https://www.amazon.com/dp/B085L8Z4YS
[8] G. Adzic, M. Bisset, and T. Poppendieck, Impact Mapping. Provoking Thoughts, 2012 [Online]. Available: https://www.amazon.com/dp/0955683645
[9] A. Osterwalder, Value proposition design. 2014 [Online]. Available: https://www.amazon.com/dp/1118968050
[10] N. Ford, R. Parsons, and P. Kua, Building Evolutionary Architectures: Automated Software Governance, Second. O’Reilly Media, 2023 [Online]. Available: https://www.amazon.com/dp/B0BN4T1P27
[11] M. C. Feathers, Working Effectively with Legacy Code. Prentice Hall, 2004 [Online]. Available: https://www.amazon.com/dp/0131177052
[12] G. Kim and N. Forsgren, DevOps Handbook, Second. IT Revolution Press, 2021 [Online]. Available: https://www.amazon.com//dp/B09G2GS39R
[13] J. Humble and D. Farley, Continuous Delivery. Addison-Wesley Professional, 2010 [Online]. Available: https://www.amazon.com/dp/0321601912
Links
-
[1] Product Owner Formation Marcel Baumann. 2021.
-
[2] Digital Product Manager Marcel Baumann. 2022.
-
[3] Six Levers for Better Agile Product Development Marcel Baumann. 2018.
-
[4] DevOps for Small Applications Marcel Baumann. 2021.
-
[5] First Steps in DevOps Marcel Baumann. 2022.