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

component product manager - 1.jpg

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.


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.

component product manager - 2.jpg

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.
component product manager - 3.jpg
  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.
component product manager - 4.jpg

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

Read more

Scrum master ทำแค่เนี๊ยะ

Scrum master ทำแค่เนี๊ยะ

เวลามีคนถามว่า Scrum master ทำอะไร แล้วผมตอบว่าทำให้ Scrum เวิร์คสำหรับทั้งองค์กร ซึ่ง โฟกัสหลัก ๆ 4 อย่างก็จะอยู่ที่ Product owner, ทีม, engineering practices และ องค์กร บางครั้งที่ผมจะได้ยินเสียงตอบกลับมาเบา ๆ ว่า “แค่เนี๊ยะ?” ในฐานะ

By Chokchai
how to สร้าง Knowledge Management

how to สร้าง Knowledge Management

ตอนเรียน Large Scale Scrum กับ Jurgen de Smet สิ่งหนึ่งที่ผมได้เรียนรู้ คือ ปัจจัยสำคัญหนึ่งที่ทำให้องค์กรหนึ่ง ๆ จะเร็วขึ้นได้ คือ จะต้องเรียนรู้ไปพร้อม ๆ กันได้ ซึ่งถ้าอยากทำแบบนั้นได้ก็จะต้อง share ownership

By Chokchai
โลกการเขียนโค้ด ตอน ซามูไรกับสปาตั้น

โลกการเขียนโค้ด ตอน ซามูไรกับสปาตั้น

ซามูไรที่ได้รับความไว้วางใจให้แก้ core logic จะมีสัญชาตญาณซามูไร คือแก้ตรงนี้ จับยามสามตาแล้วรู้เลยว่าจะไประเบิดตรงโน้น แล้ววิ่งไปสกัดบั๊กไว้ก่อนความเสียหายจะเกิด (ถ้าเป็นในหนัง ตอนนี้เป็นบทที่บั๊กร้องว่า “มืงรู้ได้ไง?!” :D) หลังจากที

By Chokchai
ประสบการณ์ TDD

ประสบการณ์ TDD

มันมีบางชั่วขณะ ที่ผมอินกับ Test-Driven Development (TDD) มาก จนอยากจะแนะนำทักษะนี้ให้คนเขียนโค้ดทั่วโลกที่สนใจเลย ผมคิดว่า ทักษะนี้มีผลเยอะมาก ๆ กับความรู้ความชำนาญในการเขียนโค้ดของผมทุกวันนี้ แต่ที่ผมไม่เคยอธิบายเป็นคำพูดออกมาได้คือ ทำไมนะ? เมื่อเช้าตอนกำลังอ่านเกี

By Chokchai