How to Choose Your Product Organisation Model?

As specified in our article on the four major Product organisation models, there is no ideal division. However, each type of division has its strengths and weaknesses, which can be more or less relevant depending on the context. We have tried to formalise them to help you choose your Product organisation model when the time comes.

To get the most out of this article, we recommend, if you haven't already, to start by reading the article "Four Major Product Organisation Models," which discusses today’s major organisational models.

We have evaluated these different models based on criteria that we believe are important for a Product organisation. We relied on the practical experiences of Thiguys and interviewed CPOs.

• Squad Empowerment
• User Orientation
• Skill Specialisation
• Team Autonomy and Dependency Management
• Code Mutualisation and Reusability
• Ability to scale up the organisation
• Continuous Product Improvement
• Cost

Squad Empowerment

It's obvious that any team and individual are more effective when their work has a purpose, meaning, and a concrete impact on the final Product.

In a Component Team logic, teams often manage a small part of the Product, depending on technical divisions. For example, frontend teams define interfaces but usually have to deal with APIs created by other teams (backend). As responsibilities are dispersed (the quality of a developed feature depends on the work of at least 3 or 4 different teams), teams may tend to shift responsibility to others. Backend teams may complain that frontend features were poorly thought out and poorly coded; front-end developers may complain about having to deal with a poorly designed data model, and so on. To avoid these problems, it is essential to promote internal co-construction between teams and address client-supplier relationships. The latter tends to resurface regularly when working in Component Teams.

Regarding this, the Component Teams model, in our opinion, should be avoided when choosing your Product organisation. In this model, a single Component Team can paralyse others.

Vertical models (Feature Teams, Impact Teams, etc.) empower squads. They must define their own goals, vision, backlog, always with a focus on delivering value to the user. Most significant decisions are made within the teams who “build”, even if they always act within a given strategic framework.

The SAFe model represents, in our opinion, an intermediate approach to empowerment. Squads are normally autonomous and empowered at the Program Increment level. However, depending on the implementation of the model and the number of hierarchical layers above the squads, they may end up disconnected from both users and Product strategy.

User Orientation

By nature, vertical teams (whether Feature or Impact Teams) are user-oriented, as their division is designed based on user issues. The team organised by objectives has this advantage over the Feature Team of not perpetuating a specific functionality. Once a Feature Team is created, the squad may tend to continue developing the feature in question even if it no longer meets the Product objectives to justify its existence.
Vertical teams also include all the necessary skills to conduct user research in their scope (see chapter 6 "How to Industrialize Product Discovery" in our book on Product oriented organisations).
Conversely, Component Teams are less user-oriented by nature, as they reflect more of a technical organisation. Moreover, user research is not carried out by each team but is often performed at another level of the organisation within dedicated teams (for example, back-end teams being completely disconnected from user contact).

Skill Specialisation

Here, the different models are in direct opposition. Component Teams are an environment that favours specialists who want to deepen a particular expertise; they are particularly suitable for complex technical contexts or those requiring very specific skills (specific technology or programming language), which are better grouped within the same team. For example, a team dedicated to Data Science.

Conversely, Feature Teams and vertically scaled agile models such as SAFe favour "T-shaped" profiles; excelling in one expertise but having the ability to occasionally extend their scope to other areas. The "full-stack" developer model capable of handling front-end, back-end, and even DevOps development is well-suited to this type of squad; as the squad size must be limited. The vertical squad cannot accumulate specialist profiles. Moreover, this type of squad has the notable virtue of significantly reducing the risks of disruption due to the absence of one or more team members.

Team Autonomy and Dependency Management

• frequently delivering value to the user
• valuing the creativity and expertise of each team
• bringing decision-making closer to operational teams.

Each team can theoretically progress at its own pace without waiting for developments made by others. Of course, this autonomy has limits, and some adherences are inevitable. Vertical teams must align with each other frequently. The goal is to avoid developing redundant features or making contradictory choices. This is especially true for teams organised by objectives, which can all impact the same Product feature.

This synchronisation between squads and additional management of transversal projects impacting all teams consume time and energy. However, as mentioned earlier, it is possible to simplify this process through tribes, chapters, and guilds. SAFe also places great importance on planning activities, which help anticipate dependencies and align squads.

Code Sharing and Reusability

Advocates of the Component Teams model argue that code reuse is one of its advantages. By nature, each component team has a clearly defined scope. It tends to reuse and optimise its own components, evolving them according to the needs of other teams.

Feature Teams have more flexibility to develop their own solutions. Thus, the model may generate more duplicate work and less mutualization. However, guilds and chapters can promote component reuse or identify code refactoring to prioritise later by each Product Owner. As the Product's source code belongs to everyone, it is the responsibility of each team to contribute correctly (by identifying opportunities to reuse existing code).

This often-heard argument should not, therefore, be considered, in our opinion, when choosing your Product organisation.

Ability to scale up the organisation

Organisations adopting the Feature Teams model sometimes struggle with scaling and changes in priorities. If a Feature Team is temporarily overwhelmed, should another one be created? In this case, what will its backlog contain? Should the feature be split in two? And if the feature the team was working on turns out to be less relevant than expected, what should be done?

The Feature Team model works well for issues on which the company wants to invest in a sustainable manner. However, it may not be easy to manage in the case of sudden growth or rapid changes in priorities. When choosing your Product organisation model, you will need to consider the nature and impact of your activity on this criterion.

The Component Team model poses fewer problems because its scope is inherently durable; a component does not disappear overnight. Additionally, the Component team, being non-multidisciplinary by nature and therefore less collaborative than a vertical team, may suffer less from size constraints. To some extent, you can simply add developers to the team as needed. If the team becomes too large, the question of dividing the component team may arise.

In the SAFe model, squads being largely undifferentiated, scaling up is normally simpler. You can add collaborators to a given team until it reaches the maximum size of a pizza team; after which, creating another team is sufficient. The more squads the company has, the more the capacity to deliver automatically increases, provided that the velocity of each squad is maintained.

Continuous Product Improvement

Continuous improvement is one of the key activities of a Product team. It's not just about developing and deploying new features; sometimes, it's better to improve existing ones rather than starting something new.

The vertical dividing model is clearly the most suitable if the Product team wants to promote continuous improvement. Each squad is autonomous in its scope and responsible for its backlog. The Product Owner or Product Manager is free to prioritise with the team the improvement of existing features or the creation of new ones based on value criteria. This system limits the temptation to focus only on new features (often uncertain in terms of return on investment) at the expense of quick improvements that bring a lot of value but are never prioritised in project mode.

In the Component teams model, each team independently carries out improvements. Synchronisation is required to prevent the efforts of one team from being completely ignored by others. In our experience, since the roadmaps of each team are often already filled with urgent needs identified by other teams, the continuous improvement part is generally reduced to a minimum (or at the discretion of the Product Owner). Finally, as this model often leads to a breakdown of tasks into project mode, small improvement tasks are often indefinitely postponed.

Frameworks like SAFe rely on each Product Manager or Product Owner to prioritise continuous improvements in Program Increments. The Product Owner has the ability to negotiate a reduction in their capacity to develop new features to focus more on incident management, technical debt reduction, or improvement of existing features. When choosing your Product organisation model, if continuous improvement is an important measure in your activity, the component model may not fit your needs.

Cost

In principle, no model is inherently more costly than another. Choosing your Product organisation model should not initially consider this criterion.

However, the transition from a horizontally divided organisation to a vertical one can indeed lead to increased costs if you want to integrate all the necessary skills into each squad. For example, an organisation with a web team of 20 developers and a mobile team of 4 developers could transform into 5 Feature Teams of 5 developers each (which would require recruiting an additional developer).

The transition to a SAFe model can also be done with a constant workforce or require strengthening skills in the Product Management part (portfolio and program layers). This is often the case, as one of the goals of this framework is to create a global transformation at the organisational level.

This is one of the reasons why the hybrid model can be suitable in some cases, retaining rare skills or certain core applications in their own Component Team and transforming the rest of the organisation into user-oriented vertical teams.

Finally, it should be noted that time losses and potential inefficiencies generated by an inappropriate dividing model can constitute hidden costs. If a vertical model proves to be more effective in terms of governance (minimising meetings, time to market) or delivered quality (thanks to better decisions made on the ground), it can easily justify the recruitment of a few additional skills compared to a horizontal model.

Conclusion

The so-called "Spotify" model, organised vertically into Feature Teams, is currently the favourite of pure players. Many IT departments of large companies have adopted it or are experimenting with scaled agility models such as SAFe or LeSS. However, none of these solutions represent a miracle cure. To choose your Product organisation model wisely, you must first think about your context and needs.

In our opinion, what is essential is to find a breakdown that gives meaning to the work done by the teams. It should also limit dependencies between squads (and thus time wasted in meetings) and rely on relatively small-sized teams (pizza teams).

Thus, the Feature Team model seems naturally more compatible with our vision of Product Management. We at Thiga believe that a team 100% organised by components will not be as effective in the long run.

However, the vertical slicing also poses challenges that are not always easy to resolve; on the management of cross-functional aspects, team alignment, skills management, etc.

The creation of hybrid models, mixing completely vertical and independent Feature Teams, and some Component Teams on targeted topics, can represent an interesting middle ground, if not a transition solution.

Component Teams can also be formed temporarily, for example, to catch up on functionality delays. In the case of launching a mobile application, a dedicated squad can develop all the features available on the web at once, currently carried by Feature Teams; once the mobile application has caught up in terms of functionality, you can consider dismantling the team to bring its skills back into various Product squads.

To go further: Download our book on Product oriented organisations.