4 grands modèles d'organisation Produit 😎

Cet article est un extrait de notre dernier livre, le Product Academy Volume 3 dédié aux organisations Produits. Ce livre s'adresse à tout ceux qui souhaitent structurer leur organisation en vue de faire les meilleurs Produits numériques possibles.

Toute organisation confrontée à des problématiques de croissance va inévitablement se scinder au fil du temps en différentes équipes ; chacune ayant son propre domaine de responsabilité. Les squads Produit n’échappent pas à la règle. Ainsi, c'est à ce moment là que la question de modèles d'organisation Produit se pose.

Ici, notre focus est la répartition des compétences dans les équipes et le périmètre fonctionnel qui leur est associé. C’est une préoccupation majeure des CPOs. Nous laissons de côté la dimension hiérarchique. Cette dernière définit les lignes de responsabilités et les relations entre tel manager et tel individu ou équipe.

Taille des squads

L’un des critères principaux de tout découpage est bien sûr la taille maximale de chaque squad. Un consensus semble se former autour d’un nombre idéal de 8 personnes ; la fameuse “pizza team”, pouvant confortablement partager en toute convivialité deux pizzas margherita. Il est évidemment acceptable de déroger à ce chiffre magique et de constituer des équipes de 5 à 12 personnes ; gardez cependant en tête qu’au fur et à mesure que les squads croissent, le nombre de liens à maintenir entre les individus explose (de 10 pour une équipe de 5 à 66 pour une équipe de 12 !). La communication devient inévitablement plus difficile, les rituels s’éternisent, la productivité individuelle et collective diminue. En plus d’être proportionnellement plus lentes que des équipes plus petites, les squads trop larges ont également tendance à sous-estimer la difficulté des tâches, en se révélant souvent démesurément optimistes dans leurs estimations.

Construire des petites squads, c’est une nécessité pour faciliter la communication ; mais il faut également limiter les dépendances et adhérences entre ces squads ; le risque reste néanmoins de reproduire au niveau collectif les problèmes de communication exposés plus haut. Les squads doivent être les plus autonomes possible et leur périmètre cohérent afin d’éviter le travail en double, les réunions d’alignement interminables et les guerres de périmètre.

Pour aller plus loin : Découvre notre livre sur les organisations Produit

Découpage

Le découpage n’est qu’un élément parmi d’autres de l’organisation. Quelle que soit l’approche retenue, il faudra également pour qu’elle fonctionne assurer une cohérence méthodologique (Lean Startup, Design Thinking), mettre en place des processus (conception, recherche utilisateur, Growth...), et une gouvernance appropriée (voir notre article sur les OKRs “Comment piloter les objectifs d'une équipe Produit ?”). Même si votre organisation est exemplaire sur tous ces autres domaines, un mauvais découpage peut poser à lui seul de graves problèmes.

Les 4 caractéristiques d’un mauvais découpage ainsi que leurs conséquences possibles sont listées ci-dessous. Si vous reconnaissez les travers de votre organisation dans au moins l’un de ces constats, c’est qu’il est sans doute temps de changer votre découpage d’équipe.

La bonne nouvelle, c’est que la plupart de ces travers peuvent s'éviter, en choisissant le bon modèle de découpage. La mauvaise nouvelle, c’est qu’il n’y a pas de découpage idéal et unique (tout comme il n’y a pas d’organisation idéale). Tout dépend de votre Produit, de votre contexte et des caractéristiques de votre organisation.

Les 4 modèles de découpage ✂️

On distingue schématiquement 4 modèles de découpage des équipes.

Le découpage horizontal ➡️

Ce modèle de découpage est souvent appelé découpage en Component Teams (équipes composants). Les squads sont structurées selon une logique technologique, en séparant souvent squads “front” et squads “back”, en créant des squads par canal ( web, mobile, IoT...) ou en construisant des squads dédiées à une couche applicative donnée (par exemple : socle de paiement, service d’emailing...).

La version minimaliste rencontrée le plus fréquemment sur des Produits simples est un découpage en 4 squads ; une front-end, une back-end, une équipe iOS et une équipe Android.

Le découpage vertical ⬇️

Dans ce modèle, les squads s'organisent selon une logique business et orientées utilisateur ; souvent par fonctionnalité (Feature Teams - popularisées notamment par Spotify), mais aussi parfois par étape de parcours utilisateur, persona ou objectif (Impact Teams).
Quel que soit le mode de découpage retenu, chaque squad est :

• pluridisciplinaire : elle regroupe toutes les compétences nécessaires au développement d’un Produit complet, pour accomplir sa mission en autonomie.
• multi-composant : elle est capable de travailler sur toutes les couches techniques du Produit (notamment front et back). Son périmètre englobe aussi une tranche verticale du Produit, indépendamment de l’architecture technique.
• stable et durable : une durée minimale d’un an semble faire consensus ; pour que l’équipe ait le temps de trouver son rythme de croisière. Si les sujets travaillés par l’équipe deviennent non prioritaires pour l’organisation, il vaut toujours mieux basculer la squad sur un nouveau périmètre plutôt que la démanteler entièrement.
• en apprentissage permanent : chaque membre de la squad doit aller au-delà de sa spécialité d’origine afin que les tâches puissent être réalisables par plusieurs personnes, et que chacun ait le sentiment de progresser à titre individuel.

Apporter de la valeur

Le découpage vertical permet d’inscrire dans la structure même de l’organisation Produit sa mission : apporter de la valeur aux utilisateurs. Le tout en favorisant l’autonomie et la créativité de chaque squad.

Par nature, ce type de découpage pose la question de la gestion des problématiques transverses et de la cohérence entre le travail fourni par chaque squad. Comment s’assurer que l’expérience utilisateur finale est cohérente ? Comment gérer le fait que chaque équipe peut modifier n’importe quelle partie du code du Produit, et impacter le travail de toutes les autres (surtout dans le cas d’Impact Teams) ?

Pour pallier ce problème, les entreprises pratiquant le découpage vertical créent souvent un échelon intermédiaire. Spotify, qui a beaucoup communiqué sur le sujet, propose un système de tribus regroupant plusieurs squads. Cet échelon apporte de la cohérence, assure la synchronisation des différentes squads et porte des initiatives transverses.

Des chapters (communautés de pratique) sont également implémentés : ces communautés sont transverses aux squads, et organisées par compétence. Ainsi, les Product Owners de chaque squad se réunissent ponctuellement pour partager leurs bonnes pratiques et échanger sur leur backlog ; de même, les Product Designers peuvent partager la recherche utilisateur effectuée au sein de chaque squad. Ils peuvent aussi se mettre d’accord sur des principes d’interface ou parcours.

Enfin, des guilds reproduisent le modèle des chapters mais à l’échelle de l’organisation Produit toute entière. Elles se dédient alors à des problématiques transverses mobilisant des compétences plus diverses et constituant des axes de travail importants pour l’entreprise  (par exemple : sécurité, machine learning, atomic design).

Le découpage hybride 🧜

Il n’est pas rare que les équipes Produit mélangent découpage vertical et horizontal. Par exemple, dans une organisation en Feature Teams avec une application mobile, l’idéal voudrait que chaque squad dispose de ses propres développeurs iOS et Android pour respecter le principe de l’autonomie des équipes et pouvoir livrer de la valeur quel que soit le canal envisagé. En pratique, une telle solution est coûteuse et parfois contre-productive ; les développeurs mobiles étant souvent plus efficaces regroupés ensemble plutôt que disséminés dans des squads différentes.

Certaines entreprises choisissent ainsi de concilier découpage vertical (pour une partie des équipes) et Component Teams pour certains canaux ayant des contraintes spécifiques (mobile, IPTV pour un acteur média…) ou bien des applicatifs socles très importants (back-end de gestion des virements pour une banque).

Le découpage vertical flexible (par exemple : SAFe) 💆

La quasi-totalité des frameworks agiles, notamment SAFe, LeSS ou Scrum@Scale, préconisent de constituer des équipes pluri-disciplinaires à l’instar du modèle vertical (composées donc de développeurs, Product Designers, Product Owner / Product Manager, testeurs…), mais sans forcément les restreindre par nature à un périmètre.

Le framework SAFe propose d’implémenter 3 échelons et 3 niveaux de granularité:

• Le portfolio, qui regroupe des Epic Owners et Portfolio Managers, manipulant un backlog d’epic associées à de grandes priorités stratégiques et business
• Le programme, qui regroupe des Business Owners et Product Managers manipulant un backlog de fonctionnalités ; planifiées à l’échelle de Product Increments (en général, 5 sprints de 2 semaines)
• Les squads, qui se saisissent des fonctionnalités, les transforment en user stories et les intègrent dans des sprints.

Si les squads peuvent progressivement se spécialiser sur certains sujets ou thématiques au fur et à mesure des Program Increments (PI), elles sont par nature non spécialisées et peuvent absorber n’importe quelle fonctionnalité. Tous les 5 sprints, une session de PI Planning permet de planifier les 5 prochains sprints en distribuant les sujets prioritaires aux différentes squads, mais aussi d’anticiper les potentielles adhérences. Il peut arriver toutefois que l'on rattache les squads à un Value Stream ; soit un domaine complet de l’entreprise (business unit, Produit…).

Voici un exemple de découpage d’équipes possible pour un service de covoiturage (tel que BlaBlaCar ou iDVROOM) :

Pour aller plus loin : Mets en place une bonne organisation Produit

In a nutshell 🌰

• Un mauvais découpage engendre un très gros coût : turnover, time to market, dette technique, faible satisfaction client, ...
• 4 types de découpage :
  • Horizontal : la logique technologique, par compétence métier (front, back, iOS, Android, ...) >> Component teams
  • Vertical :
    • Equipes user-centric et autonomes (par fonctionnalité, par étape de parcours utilisateur, ...) >> Feature teams
    • Equipes en charge d'un objectif stratégique (ex : augmenter la rétention des utilisateurs) >> Impact teams
  • Hybride : majorité de Feature ou Impact teams ainsi que quelques Component teams.
  • Vertical flexible : squads pluri-disciplinaires à périmètre variable. Les features prioritaires se répartissent entre les équipes afin qu'elle soient livrées le plus tôt possible.

4 modèles ok, mais lequel choisir ?🤔

Il n'y a pas de bons ou mauvais choix. Il s'agit de choisir le modèle qui apportera le plus d'avantages en fonction de votre contexte. On a essayé de vous apporter plus d'éléments de réponse dans l'article "Comment choisir votre modèle d'organisation Produit ?"

Passionnant n'est-ce pas ? Retrouve tout dans notre livre sur les organisations Produit !