Pour une organisation produit fluide

Il y a beaucoup de questions autour de l’organisation d’équipes « Produit ».

• Quel découpage, et donc quelle manière de voir la production de valeur et d’adresser les questions sous-jacentes de dépendances ?
• Quels process, par exemple pour prioriser toutes les initiatives et organiser toutes les équipes qui les portent ? Ces équipes étant parfois indépendantes dans la réalisation, parfois moins. Et certaines fois, oeuvrant à différents aspects d’un même objectif, quand d’autres fois elles adresseront des objectifs stratégiques différents.

On comprend rapidement que ces questions autour de l’organisation des équipes « Produit » sont loin d’être simples. D’autant que plus l’organisation est grande, plus ces questions se font complexes. Pour ma part je les ai rencontrées chez tous les clients pour lesquels j’ai travaillé en tant que Product Manager. Avec à la clé, à chaque fois, une ou plusieurs réorganisations vécues, dans des intervalles pour le moins restreints (12-18 mois). Et quand j’en parle autour de moi, à d’autres POs ou PMs la situation semble identique.

Beaucoup de choses ont été écrites ou dites autour du découpage des équipes produits. Autour de la planification et du cadencement du delivery. Autour de la priorisation des portefeuilles d’initiatives. Etc. Et il y a des éléments intéressants dans toutes ces discussions et tous ces articles.

Dans l’implémentation, ces modèles doivent être adaptés, car ce qui marche pour l’un ne marche pas pour l’autre. Ils le sont le plus souvent, et c’est tant mieux : car en produit comme ailleurs, il faut se garder de tout dogmatisme.

Mais à chaque fois j’observe que, quelle que soit la position adoptée, elle finit par avoir des rigidités. De nouvelles questions se posent face à des cas non anticipés. Ce qui marche un jour, ne marche pas toujours. Il faut alors faire évoluer le modèle. Encore et encore. C’est d’ailleurs le mot d’ Henrik Kniberg et Anders Ivarsson en prélude de leur article de 2012 présentant le modèle Spotify, un des modèles qui a suscité beaucoup de discussions et d’enthousiasme au sein de la communauté produit : « Ici [à Spotify], le modèle aura déjà évolué quand vous aurez fini de lire cet article« 

Aussi il semble judicieux de prendre cette contrainte de l’adaptation à un contexte sans cesse changeant comme un élément fort du modèle que l’on choisit, quel qu’il soit. On a besoin d’une organisation produit fluide.

Pour cela, une idée très simple me semble relativement négligée : celle de la mobilité des individus au sein de l’organisation. Il me semble en effet y avoir beaucoup de bienfaits à ce que les « product people » évoluent, de manière régulière dans différentes équipes et différentes tribes.

J’ai pu, à titre personnel, en faire l’expérience chez un client où, en tant que product manager, j’ai parcouru 3 tribes et 4 équipes produit en l’espace de 30mois. Et c’était génial ! Pour moi. Comme pour mon client d’ailleurs. Car par cette mobilité, j’ai pu :

• acquérir une vision globale des problématiques et donc mieux comprendre la stratégie de l’entreprise, comment les différentes parties pouvaient y contribuer et comment mieux orienter mon travail pour maximiser la valeur produite à une échelle plus grande que celle de mes équipes
• apporter un nouveau souffle à des produits qui s’étaient enfermés dans une certaine inertie, voire un fatalisme sur leur mission, leur périmètre, et même la manière d’aborder certaines initiatives
• faire circuler l’information rapidement aux bonnes personnes, et fluidifier le fonctionnement inter équipes et même inter tribe sur des sujets d’alignement de roadmaps ou pour faire avancer des projets ad hoc.

Revenons sur ces points.

Optimisations locales vs optimisation globales

Considérer les équipes produits comme des entités à part entières, autonomes, des véritables startups staffées pour accomplir leur mission, permet de leur laisser les mains libres et prendre des décisions informées par la proximité du terrain. Mais on ne peut pas tout avoir. Et dans les faits, cette proximité du terrain induit une certaine myopie par rapport à la Big Picture.

Car réfléchir local, c’est optimiser de manière locale, et donc trouver des optimums locaux. C’est bien, mais il est possible de trouver une meilleure solution. Les POs et PMs essaient de maximiser la valeur à l’échelle de leur produit, mais faire cela, ce n’est pas optimiser la valeur à l’échelle de l’organisation – il peut y avoir une meilleure allocation de ressources, par exemple sur des projets qui semblent plus alléchants en termes de ROI, ou pour sécuriser des équipes sous staffées.

Pour illustrer, prenons la courbe ci dessus. Admettons que je me trouve à gauche, mais trop proche du premier sommet. Mon champ de vision ne peut pas voir le second, pourtant plus haut.

Avec quelques pas de recul, je peux mieux voir le sommet le plus haut, qui représente métaphoriquement une situation plus optimale que le sommet voisin .

En d’autres termes, si je suis trop zoomé sur le contexte de mon produit, je peux passer à côté d’impacts qui sont plus importants à l’échelle de ma tribe, voire de mon organisation. Soit que je travaille sur les mauvais sujets. Soit que j’affecte mal mes ressources.

Il m’est souvent arrivé de prêter des ressources, développeurs, ou designers à d’autres équipes. Non que je n’avais pas de sujets ; mais que les sujets des autres équipes étaient plus importants à l’échelle de l’organisation (plus d’impact ou plus hauts dans les objectifs stratégiques) et que, ma responsabilité étant de maximiser la valeur délivrée pour l’organisation, la décision la plus adéquate était de mobiliser des ressources sur ces sujets à plus fort impact global.

Inertie de la vision produit

Avoir un PM stable longtemps sur un périmètre, c’est un peu comme si une équipe de football était entrainée par le même entraineur pendant 40ans : finira inévitablement par arriver le moment où l’entraîneur aura fait son temps. Il est sûrement compétent, révolutionnaire peut-être, mais là n’est pas la question. La question c’est ce que l’équipe aurait gagné a être menée par une autre main, qui ne renie pas le travail passé, mais l’enrichit.

A titre d’exemple, on peut citer les Milan de Sacchi et celui de Capello. Le premier total, méthodique, intense physiquement. Le second plus organisé défensivement, mais tout autant voire plus brillant offensivement, et globalement plus dominateur. Sacchi est reconnu comme un tacticien révolutionnaire. Capello, qui contrairement à son prédécesseur avait été un joueur de premier plan, et avait vécu certaines situations de l’intérieur, comme un gestionnaire. Au milieu de leurs règnes respectifs, une équipe forgée et enrichie par l’ajout de nouveaux joueurs. L’un a construit sur le travail de l’autre, les deux approches se sont complétées, et le résultat fut un Milan incroyablement dominateur, à 10 000 lieues de ce que l’on a pu voir dans les derniers années (même s’il y a du mieux récemment).

La réfutabilité est critère de progrès : une vision produit sera donc vraie jusqu’à ce qu’on prouve qu’elle est fausse. Et pour le prouver, c’est mieux d’avoir une pluralité de voix. La diversité, c’est le brassage des voix, des idées et des approches qui s’entrechoquent, s’influencent mutuellement et s’enrichissent. En quelque sorte, plus on est de fous, plus on rit.

Or une trop grande stabilité des équipes sur un périmètre ne permet non seulement pas de prendre de la distance par rapport à la vision produit, pas plus que de développer les différents membres de l’équipe : on travaille sur le même périmètre, avec les mêmes personnes, les mêmes approches (et parfois, préjugés) et les même technos… Cette inertie nuit au produit lui-même, qui lentement étouffe de respirer toujours le même air, et à l’équipe, qui n’apprend que peu.

A la manière de sprints agiles, qui sont des timebox pour minimiser le risque et ajuster le tir en vue de la période suivante, questionner une vision produit de manière régulière est important pour rendre son produit plus robuste et s’assurer qu’il va dans la bonne direction.

Cloisonnement des interactions de travail

L’écosystème d’un produit est généralement limité au sein d’une organisation. On travaille avec certaines parties prenantes. On a des dépendances avec certains produits. Mais globalement la zone d’interaction d’un produit ne s’étend pas au delà d’un périmètre limité de parties prenantes.

Aussi, on peut voir passer des informations dont on n’a que faire, mais qui, passées à la bonne personne, auraient été très utiles : une mise en production qui peut avoir des impacts sur d’autres produits, une annonce au détour d’une réunion, même un article de veille… Seulement, travaillant toujours avec les mêmes personnes, on ne connait pas les personnes qui auraient été intéressées par ces informations, et on ne peut pas leur « passer le ballon ».

De même, quand un projet implique plusieurs produits qui n’ont pas l’habitude de travailler ensemble, on a vite fait de se regarder en chien de faïence. Tel produit back fait des évolutions dans son modèle de données sans en avertir le front. Ou bien telle équipe dont on dépend en pour une fonctionnalité importante a du mal a prioriser notre demande dans son backlog.

Plus on systématise une rotation des individus au sein de l’organisation, plus on casse ces silos (d’informations, de pratiques, d’initiatives, etc) qui se créént de fait avec une trop grande stabilité des équipe sur leur périmètre. C’est d’autant plus important passé une certaine taille d’organisation, comme il y devient plus difficile d’y faire circuler l’information de manière fluide et d’y harmoniser les pratiques entre équipes.

Plus on a la tête dans son propre contexte, plus on se rend myope de l’activité globale de l’organisation. Comme un attaquant qui ne se préoccuperait que du classement des buteurs, au point d’en négliger le classement de son équipe. Ou encore qui ne s’intéresserait qu’aux ballons arrivant prêt du but adverse.

Pour filer la métaphore footbalistique, on dira que, plus qu’un attaquant, ou un défenseur, on péfère un PM libero. Un peu à l’instar du Football Total de Rinus Michels où l’attaquant pouvait devenir arrière ; l’arrière attaquant ; et où globalement, la permutation des rôles en fonction des temps de jeu était un principe fondamental.

La raison derrière cette préférence est que de tels PMs ont plus de chances de connaître toutes les zones du terrain, et tous les acteurs qui s’y trouvent. Ils savent facilement trouver la personne qui pourra répondre à telle question, celle qui sera intéressée par telle information, et l’autre encore qui sera impactée par telle évolution. Ils ont construit un historique de travail avec différentes équipes qui simplifie la discussion et la coordination autour des nouveaux projets. Ils ont circulé à travers différentes tribes, chacune avec leur méthodes et rites et peuvent ainsi plus facilement faire circuler et harmoniser le cadre de travail au sein de leur organisation technique. Globalement, ils incarnent ces fluidifcateurs / maillons connecteurs très utiles pour mettre de l’huile dans les rouages d’organisation complexes (un rôle qu’on prête aussi d’ailleurs de plus en plus aux Product Ops).

Pour finir

En bref, systématiser une rotation des PO/PMs présente à mes yeux de nombreux avantages :

• on combat l’inertie produit par le renouvellement continu des points de vue sur un périmètre donné
• on encourage la pensée globale au détriment d’une pensée locale en améliorant la connaissances des différentes aires de jeux de l’organisation et de la manière où elle produit globalement de la valeur
• on fluidifie la collaboration en favorisant les rencontres et en intensifiant le renouvellement des interactions de travail
• on favorise l’appropriation collective de toute la chaine d’outils, ce qui contribue à réduire les zones de non droit et le risque de maintenance
• on harmonise les pratiques des équipes et encourage la consolidation d’une Definition of Done à l’échelle de l’organisation

Enfin, un dernier mot sur la fréquence de tels changements : une rotation tous les 12 mois paraît être une temporalité adaptée. Cela laisse en effet le temps nécessaire pour reprendre une roadmap existante, s’acculturer à une nouvelle équipe, rencontrer et construire une relation de travail avec des nouvelles parties prenantes, comprendre les enjeux du produit, se forger ses propres convictions, et mener des projets de bout en bout. Ne pas respecter une certaine durée, ce serait:

• pénaliser le produit (qui risquerait de faire du surplace à trop changer fréquemment de cap),
• frustrer le PO (qui n’aurait pas eu le temps de pouvoir bien faire son travail) et
• fatiguer les parties prenantes (qui n’auraient de cesse que de repartager leurs enjeux avec des nouveaux interlocuteurs).