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.
Poor division |
Observable consequences |
Final impact |
Unsuitable squad size |
• Social laziness if the squad is too big • Underuse of Product profiles if the squad is too small • Bottleneck if the squad is too small |
• Low predictability • Low velocity |
Squads oriented towards "output" rather than "outcome" (i.e. focused on deliverables and not results) |
• Experience gaps on user routes • Squads' work not assigned any meaning • Culture of measurement lacking • Decisions made intuitively more than rationally |
• Low NPS/customer satisfaction • Employee turnover within teams • Mismatch between Product expectations and market expectations |
Low squad autonomy |
•Management of energy-consuming dependencies: time spent in meetings and workshops. • Dilution of responsibilities. |
• Low velocity • Employee turnover within teams |
Blurring around the team scopes |
• Experience gaps on user routes Redundant work in multiple teams • Communication problems between the teams, personal conflicts |
• Product debt • Time to market is longer |
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):
Horizontal division (Component Team) |
• Back-end squad |
Vertical division (Feature Team) |
• Driver search squad |
Vertical division (Impact Team) |
• Grow squad: responsible for maximising the volume of business transiting through the platform. |
Vertical division (Persona Team) |
• Driver |
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!