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

Use a dedicated overall portfolio product manager [2, 3].

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

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

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:

  • Aligned with the product vision and product strategy

  • Simple enough to show the direction and empower the team to discover the path

  • Crafted by the product teams and aligned with the leadership

  • Strict on outcomes and loose on outputs

  • It takes a couple of days to agree on its content

  • It aims for direction and accountability

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

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

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].

Beware that requirements engineering is a complex task [2, 6]. Formal training is recommended [1]. The books and articles of Roman Pichler are a good starting point [7, 3, 2].

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:

  • Could you help me understand how this feature relates to our goal?

  • Which evidence would you have this feature solves our users’ problems?

  • Which problem do you want to solve with this feature?

  • Let us say we implement this feature. How do we measure its success?

  • If we did not do it, what would happen?

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:

  • The product team measures its success by how much and often it ships.

  • The company believes that adding a new feature always adds value to the product.

  • The organization fails to test feature ideas before building them and fails to assess its success with users after the feature ships.

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

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

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.

Experiment to tailor your processes to the capabilities of the platform [12, 13].

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.

  • Roadmaps and plans

  • Portfolio backlogs

  • Product backlogs

  • Release trains and plans

  • Backlogs, sprints, sprint backlogs and boards for teams

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. I recommend strongly limiting the number of technology stacks to one or two stacks. The size of the development department is, in general, so small that professional level can seldom be guaranteed for multiple development stacks. Limited internal quality and high technical debt are commonly a plague for internally developed digital products.
2. The modern world is a more dangerous world. Companies should neutralize known security flaws in a matter of days. This is an ethical and legal compliance requirement.
3. The product portfolio manager is often called product responsible or development department manager. Beware that if your organization as multiple responsibles, you have multiple portfolios with separate agendas. Most companies are too small to afford such structures.
4. Configuration activities are customer-specific projects and not product related activities
5. Allocating work to component teams often means trade-offs with the priority of portfolio features. Try to nurture your developers into feature teams to remove this awkward tension.
6. A feature team should be able to provide the required requirement analysis capabilities. Only component teams require a product owner proxy.
7. DevOps approaches are only successful if the tests and continuous deployment are automated.
8. If the tests are automated, the results are available without additional activities.