This week I had the opportunity to join an awesome two day workshop – PRODUCTMANAGEMENT – facilitated by Roman Pichler.

High intensity input regarding Products, Roadmaps, Stories, Teams, Personas and Product Management. WOW. In this post I share my Sketchnotes (mainly german but maybe some pictures help all EN readers too).

I try to highlight some key insights so that you can check if you should join this path of experience too.

For a product – ask:

What needs does the product address?

Who interacts with the product?

By using a visualization what products you are building and how your teams are structured you can explore whether all share the same understanding of what a product is. It will for sure challenge your status quo.

Build your product from outside to inside. Structure it by customer groups and check for common needs to address.

A product consists of features (parts the user interacts with) and components implementing the features. By a product you generate revenue, increase productivity/reduce costs, it creates additional value and is used by a heterogenous user market.

We need to consider the product life cycle – with the phases -launch, product market fit, growth, end of life or huge change and adaption to initialize a new growth cycle.

Depending on where the product is positioned in the life cycle curve you need to apply different management and process strategies.

Starting with highly experimental environments moving to a more standardized and productivity+efficiency focused environment.

Part of portfolio management is to balance all products and life cycles (not having to much products in EOL)

Consider the difference between feature teams and component teams and pros/cons for both team variants. Applying a team mix for common assets (and e.g. building platform teams) can be an option too.

Aim for loosely coupling of products.

Resolve dependencies or apply proper management of dependencies between products.

Use e.g. company wide retrospectives (with delegates from every product) and look ahead planning. On tactical level Scrum of Scrums are useful.

Based on goals and needs for the product – you generate the product backlog with functional aspects and derive an architecture model guiding the technical implementation.

A project lifetime is much smaller than a product lifetime. Projects are used to implement a release of a product.

An option is to scale by responsibilities. Have a product and n feature teams building that product. A chief product owner takes the responsibility for the product. Product owners take the responsibility for features. All work with a common backlog.

For faster growth:Scale by products. Split your product in multiple ones. Every products has an own product backlog and product owner. The chief product owner keeps the overview on the product line.

Benefits are less coordination and smaller backlogs. Disadvantages can be cross cutting aspects like UI and security that can be challenged by feature drifts.

Consider the Stacey Matrix for your product. Usually products flow from the chaos/complex towards the complicated/simple areas during their product life cycle.

Product roadmaps build the high level picture.

You can build goal oriented roadmaps structured by milestones/releases where goals or parts of your goals are achieved.