Requirement Areas are NOT around product modules

Baseline vs. change is an important distinction in product development. Missing that contributes to a common misguided practice in creating RAs (Requirement Areas) around product modules. Product module is about baseline, while RA is about change. Instead of creating RAs around product modules, we create RAs around product changes.

Let’s first revisit the concept of RA. I find it useful to look at it in two views:

1. static view. RA contains both work and people.
- A RA is a subset of the product backlog, i.e., a group of customer-centric items. One item only belongs to one RA.
- A RA has a few (4-8) feature teams. One team only belongs to one RA, and avoid too few teams for the sake of adaptiveness.

2. dynamic view. RAs in a product evolve over time. Teams are stable, but areas are dynamic.
- What areas we have in a product is changing to reflect the change in the distribution of high-value work.
- Teams move to different areas over time, though they themselves are stable, as well as their organizational line.

Around product modules

Let’s elaborate on the practice of creating RAs around product modules. Product modules are the baseline view of the product. They are customer/user oriented, not technical components. Taking WeChat as an example, its product modules may include WeChat, Contacts, Moments, Channels, etc. Some companies may treat these product modules as products. This is related to product definition. When we define the product broadly, as suggested in LeSS, they become product modules. When creating RAs around product modules, we have RAs such as “Moments”.

The “Moments” RA includes 1) all the work related to the product module “Moments” and 2) a few feature teams dedicated to this area permanently, which means no expectation of change, thus often coupled with line organization. It seems to fulfill RA’s definition in the static view: 1) customer-centric items; 2) a few feature teams. It is actually possible that high-value work just naturally fits into some product modules. For example, when we develop “Moments” in the beginning, we see lots of value under that theme and decide to invest a few teams working on it. Creating “Moments” RA can be a good choice. The problem is with the dynamic view of RA - what happens with changes?

1. when value fluctuates in different modules

When high-value work fluctuates in different modules, we often don’t respond to the change until much later. Sometimes, there is more high-value work in the “Moments” module; at other times, there is more high-value work in the “Channels” module. RAs are supposed to evolve accordingly, but why is it not happening? The baseline nature of product modules boosts identity, but strong identity is a double-edged sword. On one hand, it promotes more ownership and accountability; on the other hand, it results in local optimization - there is always enough “high-value” work in any module. Moreover, the coupling with line organization makes prompt adaptation more unlikely. In the end, we may still adapt through reorganization, which is painful and happens later than we should.

2. when value cuts across multiple modules

When high-value work cuts across multiple modules, we introduce dependency across areas. Since any module-based RA can’t accommodate the high-value work alone, we split the work and put them into various area backlogs. The complexity in handling cross-area dependency is essentially caused by the same dynamic as with component teams. The module-based RAs become big component teams, which inevitably leads to delayed value delivery, let alone the limited learning and other weaknesses. Therefore, we want new RAs to emerge and accommodate new value, i.e., creating RAs around product changes.

Around product changes

In fact, the definition of RA - a group of items - already indicates around what we should create it. Items are about changes (see "Story is about change"), so we create RAs around product changes. What is the relationship between product modules and product changes? That’s the relationship between baseline and change. Once product changes are implemented, they are incorporated into the baseline product modules.

However, product changes are transient, and its grouping is elusive. Where can we look for clues on how to group them? There are a few options. You can look at what’s in your product roadmap. Bas suggests using the roadmap as a way of creating RAs (see “Requirement Areas”). If you plan with product initiatives, those initiatives are also candidates for RA. For example, AI-powered is a popular initiative nowadays, and we may create an "AI-powered" RA. If you define product goals, e.g., improving customer retention, all the work needed for achieving that goal can be a significant amount; thus, another candidate for RA. Even projects are possible RAs as they are for product changes, although there can be major differences in other aspects, such as projects may focus on output rather than outcome, and they may be organized as feature groups rather than feature teams.

Creating RAs around product changes provides advantages in adapting to changes.

1. “When value fluctuates in different modules”, with product-change based RAs, adapting is easier. This is because moving teams from one RA to another does not require a change in reporting line, and APOs may develop less strong identity with transient product changes than persistent product modules.
2. “When value cuts across multiple modules”, RA always follows value (see "Follow value in defining RAs"); thus, one RA completes the value delivery. For example, in a newly emerged “AI-powered” RA, teams in this area can develop those items from end to end. There is no need to manage the dependency among items spread in multiple area backlogs. Those teams might previously have worked in the “moments” or “customer retention” RAs. Their knowledge can still be useful as AI capability will most likely be powered on top of the baseline product; meanwhile, they all need to learn how to develop AI application.

Conclusion

Why is creating module-based RAs such a common misguided practice?

One reason is missing the dynamic view of RA caused by lacking a clear distinction between baseline and change. When writing this article, I realize that I have not tried to explain the concept of RA with multiple views (static and dynamic), while in fact it is common to use multiple views for describing nontrivial things, e.g., 4+1 views for architecture. So, a better explanation can help.

Another reason is more tricky. We almost unconsciously look for clear ownership for product modules (see “We love individual responsibility more than we would admit”). If product modules are not owned by RAs, then by whom—which teams? What if the architecture and design of product modules lose integrity or the code and tests become not maintainable? LeSS promotes collective ownership through collaborating across teams (not only in the same RA but also from different RAs). All teams take shared responsibility for the whole product and product modules; this design makes some people uncomfortable. Creating RAs around product modules for this reason is also harder to change.