"Component Product Manager"

During the past half year, I have seen the similar situation at least three times in various organizations. This probably means that it is worth an elaboration.

"Component Product Manager"

We know of component team, but what on earth is "component PM (Product Manager)"? Doesn't it sound absurd? I did not really hear the exact term being used, while it came out from the people whom we together ponder over the situation - "we have not only component team, but also component PM"!

We were discussing about how to transition from separate backlogs to one shared backlog. As shown in the below diagram, they currently have respective PMs and development teams responsible for certain areas (A/B/C) within the product. In order to move towards one backlog, besides the teams, the PMs also need to change.

This term contains two parts - Component and Product Manager, and let's understand them separately.

• Component
• The component responsible by PM is to some extent customer oriented, as a customer or business area inside the whole product.
• It may depend on other areas to together create value, but it is occasionally valuable on its own, as illustrated in the shared backlog on the right side of the above diagram.
• Product Manager
• Its alternative name is Product Owner, but they are actually more like BAs (Business Analysts). In some organizations, they are also called so.
• They specialize in certain area. As they are coupled with teams, the corresponding teams specialize in the same area.

In short, "Component PMs" are the BAs specialized in dependent areas.

Challenges

When we have all teams share one backlog, the generic teams (1/2/3) who work on whatever features with highest value simply can't continue to couple with the specialized BAs. Therefore, these BAs need to decouple with the teams and somehow connect to the one backlog, as shown in the below diagram.

It is common that the same technical stack is used across those areas, thus, the teams usually feel comfortable in expanding their scope to develop features from end to end. So, this time, the limit is more on the specialized BAs. They see it a big challenge to learn and analyze broadly across the whole product, for whatever features with highest value in the one backlog. You may argue that developers can learn broadly, why can't BAs do the same? It is of little avail if you encounter a view that developers only need to code for specification, while it is much more difficult for BAs to learn broadly, thus they have to specialize in some area. So, the better strategy is to focus on the system optimizing goal, which is to discover and deliver the most value as the whole organization.

What further complicates the change is that specialized BAs are often located in the product department, rather than the development department. As BA is a part of feature team, the necessary organizational redesign (aka organizational flip) for feature teams is bound to span both product and development departments.

Change Paths

According to the LeSS framework, it is actually one-step change to create both one product backlog and feature teams.

• (one product backlog) All teams follow one priority, not constraint by current skills. When work and skill do not match, it triggers learning.
• (feature teams) Each team includes dedicated BA, and BA will cross-learn in the same way as other members do. All team members have the same reporting line.

It is possible to have more gradual steps, i.e. gradually break down BA's specialization on areas and change the organizational structure as well.

1. (one product backlog) BAs are still specialized in areas, then, they are de-coupled from teams. However, BAs follow the same priority from one backlog, and are not allowed to analyze features in lower priority just in order to keep busy. (hint: observe what they will do then)
2. (one product backlog) BAs break down the specialization on areas, as shown in the below diagram. They learn broadly to be able to work according to one priority.

1. (feature teams) BAs join feature teams, and any BA belongs to one team stably.
2. (feature teams) BAs and developers align performance measures across product and development departments, so as to break down functional silo and really have common goal.
3. (feature teams) Reporting structure is changed so that all feature team members have the same reporting line, as shown in the below diagram. This further promotes cross-learning within the teams.

Eventually, we evolve into the LeSS structure - multiple feature teams share one product backlog.