4 major Product organization Models 😎

This article is an excerpt from the Thiga Product Academy Volume 3: Product oriented organizations. The book is intended for those looking to structure their organization to create the best possible digital products.

Any organization facing growth challenges will inevitably divide over time into different teams, each with its own area of responsibility. Product squads are no exception to this rule. It is at this point that the question of Product organization models arises.

Here, our focus is on the distribution of skills within teams and the associated functional scope. This is a major concern for CPOs. We set aside the hierarchical dimension, which defines lines of responsibility and relationships between managers and individuals or teams.

Squad Size

One of the key criteria for any division is, of course, the maximum size of each squad. A consensus seems to be forming around an ideal number of 8 people; the famous "pizza team" that can share two margherita pizzas. Deviating from this magic number is acceptable, forming teams of 5 to 12 people. However, as squads grow, the number of connections to maintain between individuals explodes (from 10 for a team of 5 to 66 for a team of 12!). Communication inevitably becomes more challenging, rituals linger, individual and collective productivity decreases. In addition to being proportionally slower than smaller teams, overly large squads also tend to underestimate the difficulty of tasks, often being overly optimistic in their estimations.

Building small squads is a requirement to facilitate communication, but dependencies and interdependencies between these squads must also be limited. However, there remains a risk of reproducing, at the collective level, the communication problems mentioned earlier. Squads should be as autonomous as possible, with a coherent scope to avoid duplicate work, endless alignment meetings, and scope wars.

For further reading: Discover our book on Product oriented organizations.

Division

Division is just one element among others in the organization. Regardless of the chosen approach, there must also be methodological consistency (Lean Startup, Design Thinking), the implementation of processes (design, user research, Growth...), and appropriate governance (see our article on OKRs "How to steer the goals of a Product team?"). Even if your organisation excels in all these other areas, a poor division can alone raise major issues.

The 4 characteristics of a poor division and their possible consequences are listed below. If you recognise the shortcomings of your organisation in at least one of these observations, it's probably time to change your team's division.

Product Organization - Consequences of a poor division

The good news is that most of these shortcomings can be avoided by choosing the right division model. The bad news is that there is no ideal and unique division (just as there is no ideal organisation). It all depends on your Product, your context, and the characteristics of your organization.

The 4 Division Models 🤔

There are schematically 4 team division models.

Horizontal Division ➡️

This division model is often called Component Teams. Squads are structured according to technological logic, often separating "front" and "back" squads, creating squads for each channel (web, mobile, IoT...), or building squads dedicated to a specific application layer (e.g., payment infrastructure, email service...). The most commonly encountered minimalistic version on simple products is a division into 4 squads: one for front-end, one for back-end, one iOS team, and one Android team.

Vertical Division ⬇️

In this model, squads are organised according to business logic and user orientation; often by feature (Feature Teams - popularised notably by Spotify), but also sometimes by user journey step, persona, or goal (Impact Teams). Regardless of the chosen division approach, each squad is:

• Multidisciplinary: It brings together all the skills necessary for the development of a complete Product, to accomplish its mission autonomously.
• Multi-component: It is capable of working on all technical layers of the Product (especially front and back). Its scope also encompasses a vertical slice of the Product, regardless of the technical architecture.
• Stable and enduring: The team needs time to find its rhythm, as a minimum duration of one year seems to be the consensus. If the topics worked on by the team become non-prioritised for the organization, it is always better to shift the squad to a new scope rather than dismantle it entirely.
• In constant learning: Each squad member must go beyond their original expertise so that tasks can be performed by several people, and each person feels they are progressing individually.
  
  

Bringing Value

Vertical division allows the organization's mission to be ingrained in its structure: bringing value to users. All while promoting the autonomy and creativity of each squad. 

By nature, this type of division raises questions about managing transversal issues and coherence between the work provided by each squad. How to ensure that the final user experience is consistent? How to manage that each team can modify any part of the code and impact the work of all others (especially in the case of Impact Teams)?

To address this issue, companies practising vertical division often create an intermediate level. Spotify, which has extensively communicated on the subject, proposes a tribe system grouping several squads. This level provides coherence, ensures synchronisation between different squads, and carries transversal initiatives. Chapters (communities of practice) are also implemented: these communities cut across squads and are organised by skills. Thus, Product Managers from each squad occasionally gather to share best practices and discuss their backlog; similarly, Product Designers can share user research conducted within each squad. They can also agree on interface principles or user journeys.

Finally, guilds replicate the chapter model but at the scale of the entire Product organisation. They are then dedicated to cross-cutting issues involving more diverse skills and constitute important work axes for the company (e.g., security, machine learning, atomic design).

Vertical Division and Intermediate Level: Example of Spotify. (Tribe, squads, guilds, chapters, ...)

Hybrid Division 🧜

It is not uncommon for Product teams to mix vertical and horizontal division. For example, in an organization divided into Feature Teams working on a mobile application, the ideal would be for each squad to have its own iOS and Android developers to respect the principle of team autonomy and deliver value regardless of the channel considered. In practice, such a solution is costly and sometimes counterproductive; mobile developers are often more effective when grouped together rather than dispersed in different squads.

Some companies choose to combine vertical division (for some teams) and Component Teams for certain channels with specific constraints (mobile, IPTV for a media player...) or very important foundational applications (backend for payment processing for a bank).

Flexible Vertical Division (e.g., SAFe) 💆

Almost all agile frameworks, including SAFe, LeSS, or Scrum@Scale, advocate for forming multidisciplinary teams, following the vertical model (composed of developers, Product Designers, Product Owners/Product Managers, testers, etc.), without necessarily restricting them by nature to a specific scope.

The SAFe framework suggests implementing 3 levels of granularity:

• Portfolio, which brings together Epic Owners and Portfolio Managers, handling a backlog of epics associated with major strategic and business priorities.
• Program, which groups Business Owners and Product Managers managing a feature backlog; planned at the scale of Product Increments (usually, 5 sprints of 2 weeks each).
• Squads, which take on features, transform them into user stories, and integrate them into sprints.

While squads may gradually specialize in certain subjects or themes over Program Increments (PI), they are inherently non-specialized and can absorb any functionality. Every 5 sprints, a PI Planning session plans the next 5 sprints by distributing prioritised topics to different squads but also anticipates potential dependencies. However, it may happen that squads are attached to a Value Stream, representing an entire domain of the organization (business unit, Product, etc.).

Here's an example of a possible team division for a carpooling service (such as BlaBlaCar or iDVROOM):

Concrete Examples of Team Dividing in a Product Organisation

In a Nutshell 🌰

A poor division results in significant costs: turnover, time to market, technical debt, low customer satisfaction, etc.
There are 4 major Product organization Models

• Horizontal: Technological logic, by business competence (front, back, iOS, Android, ...) >> Component teams
• Vertical: 
  • Feature teams: User-centric and autonomous teams (by feature, by user journey step, ...)
  • Impact teams: Teams responsible for a strategic objective (e.g., increase user retention) 
• Hybrid: Majority of Feature or Impact teams with some Component teams.
• Flexible Vertical: Multidisciplinary squads with a variable scope. Prioritised features are distributed among teams to be delivered as soon as possible.

4 models, but which one to choose? 🤔

There are no right or wrong choices when selecting an organisation model. Each product oriented organization should reflect on the model that will bring the most advantages based on its context. We've tried to provide more insights in the article "How to choose your Product organization model?"

Exciting, isn't it? Find everything in our book on Product oriented organizations!