In the whitepaper “Designing a Product Group: An Eight-Step Design Algorithm” I walk through a complete algorithm for designing a product group using the Daily Banking unit: from mission and key capabilities to unit boundaries, team structure, and leadership model.
This article zooms in on one specific tool from that case — an advanced Heat Map with a specificity dimension, grounded in ideas from Transaction Cost Economics (TCE).
Heat Map: beyond raw frequency
A basic Heat Map is a table where rows are Product Backlog Items and columns are architectural components or functions. A cell is marked whenever a given component is involved in implementing a particular item. Counting “lit” cells per column reveals which components and functions are used most often and therefore should be represented inside teams that consume a broad range of work from the Product Backlog.
Typical Heat Map with frequency
In the Daily Banking case, frequency alone was not enough to make structural decisions, so the Heat Map was extended with a second dimension: specificity. Specificity captures how much a function depends on a unique product context, domain expertise and architecture. In TCE logic, highly specific functions are better kept inside the unit, because moving them outside increases transaction costs: coordination, alignment, and adaptation overhead. Low‑specificity functions, by contrast, can often be centralized without significant economic loss (f.e. In Commodity Platforms).
Four‑level specificity scale
In Daily Banking the following four‑level specificity scale was used:
- 0 – low: standardized, repeatable, generic function.
- 1 – moderate: requires some domain context, but is easily reusable across units.
- 2 – high: product‑dependent, requires deep domain expertise.
- 3 – very high: critical for key scenarios and tightly coupled to the product core.
For each function the design team explored questions such as:
- How strongly does this function depend on a specific product or domain context?
- Can it support multiple product groups without modification?
- How deeply is it embedded in the architecture of Daily Banking?
Frequency gradients with Pareto logic
To make frequency more actionable, a four‑level frequency scale based on the Pareto principle (80%) was added:
- 0–20% — rare: used in a small share of Product Backlog Items.
- 20–40% — occasional: appears episodically.
- 40–80% — frequent: high‑frequency function.
- 80–100% — constant: involved almost all the time.
The underlying design goal is straightforward: ideally, teams should be able to pull around 80% of all Product Backlog Items without external dependencies. The frequency scale makes this transparent by showing which components and functions must be inside teams so that “most” work flows end‑to‑end within the product group.
Decision matrix: include, exclude, consider
Combining frequency and specificity produces an economic boundary for the product group.
On top of that, a simple decision matrix was introduced to distinguish three categories of functions and components:
- Include: high frequency and high (or very high) specificity — these clearly belong inside the product group.
- Exclude: low frequency and low specificity — these can remain centralized or outside the unit.
- Consider: all ambiguous cases that require further analysis.
Decision matrix based on frequency and specificity
In Daily Banking this led to several non‑obvious insights:
- Backend, Web, iOS and Android combine high or very high specificity with frequent use, which makes their inclusion in the group economically obvious and structurally critical.
- CRM, ABS, DBMS, Call‑center and Sales (branches) show episodic frequency and moderate specificity, which places them in the “consider” zone: centralized placement still looks economically justified, but not definitively.
- Marketing and Digital Sales also land in the “consider” zone: their participation is frequent, but their specificity is moderate, so they cannot be included automatically.
At this point, the Heat Map and decision matrix provide a first structural cut, but not final answers for everything in the “yellow zone”.
Yellow zone and additional lenses
The “consider” area of the matrix aggregates functions that do not clearly fall into “inside” or “outside”. Frequency and specificity highlight the trade‑offs, but they do not fully capture operational reality.
To resolve the yellow zone in the Daily Banking case, an additional lens was introduced — types of operational dependencies between functions and components (Thompson: pooled, sequential, reciprocal).
This extra perspective makes it possible to see where centralized placement is still acceptable, and where reciprocal, day‑to‑day interdependence effectively forces functions to live closer together inside the same product group to avoid excessive coordination costs.
Full context, including the complete algorithm, all diagrams and cluster structures, is available in:
- Whitepaper “Product Group Design: An Eight-Step Design Algorithm” (eng)
- Article “Product Group Design Case Study” (rus)