Passage à l'échelle produit : les convictions, bonnes pratiques et visions du VP product de Deezer

Passer à l’échelle est synonyme de multiplication des équipes… et des emmerdes (pardon, des complexités). Benoît Terpereau nous raconte ses tentatives et idées pour y faire face. 

Avant de commencer, petit aperçu du fonctionnement interne de la licorne. Bon, allons-y sans tortiller inutilement : est-ce que Deezer utilise l’orga en feature teams “à la Spotify” ? Réponse… oui !

Sauf que la plateforme française ne parle pas de “tribus”, comme sa rivale scandinave, mais de “startups”. Un changement sémantique pas si isolé dans l’écosystème. Dans le podcast Product Squad, la responsable produit d’une autre licorne hexagonale, Contentsquare, explique par exemple que, chez eux, ils parlent de “Square”. 

Deezer compte donc 6 “startups”, dans lesquelles se trouvent différentes escouades (sorry Squads) :

• Acquisition/ Conversion,
• Engagement,
• Contenus (56 millions de titres en ligne, rappelons-le),
• Partenariat (que cela soit pour les montres connectées, la TV, les voitures, ou avec la FNAC ou des Telco internationales…)
• et enfin les grosses fonctionnalités (Flow et la recherche), toutes situées au siège parisien.

La dernière, dédiée aux innovations et aux nouvelles expériences, se situe pour sa part sur les bords de la Garonne, à Bordeaux. 

Pour conclure ce petit portrait global, mentionnons que l’équipe produit de Deezer regroupe une petite trentaine de PM (fait notable : autant de femmes que d’hommes) issus de 6 nationalités différentes.

Voilà pour la composition. Place au jeu maintenant avec Benoit Terpereau, son VP produit, qui était l’ancien responsable technique de My Little Paris et directeur de l’innovation produit chez Enablon (une boîte méconnue mais qui a pourtant été vendue 250 M€ en 2016, soit une des dix plus importantes sorties françaises des dernières années).

La galère des projets transverses

Ce dernier, arrivé chez Deezer en septembre 2018, juste après une levée de fonds de 160 M€ destinée à accélérer au Moyen-Orient et en Afrique du nord, trouve cette orga plutôt pertinente. “Oui, il peut y avoir des problèmes de cohérence graphique ou technique. Ce qu’on appelle la loi de Conway (= ce qu’une entreprise produit est le reflet de son organisation. Autrement dit, les différences de design ou de code s’expliquent par la différence des équipes qui les font), indique Benoit. Mais on y répond avec une équipe design qui est transversale et des lignes directrices tech précises. Oui, il y a cet article récent qui dit qu’il ne faudrait pas adopter le modèle Spotify, écrit par un ancien PM de Spotify – qui utilise Deezer au passage…

Mais il faut juste bien adopter ce modèle en faisant en sorte que ce type d’organisation soit plastique et évolue en fonction des objectifs de l’entreprise”. 

Non, le vrai problème orga aux yeux de Benoit, ce sont les dépendances. Quand un projet transverse dépend d’au moins deux équipes. Ce qui devient de plus en plus fréquent à mesure que la boîte s’agrandit. C’était d’ailleurs le thème de sa conférence (à retrouver en ligne ici), il y a quelques semaines, lors de l’événement UXDX. 

Voici les trois solutions qu’il évoque pour résoudre ce cauchemar organisationnel des équipes qui se marchent sur les pieds. 󠀱󠀱

1️⃣ Créer 󠀱une équipe virtuelle 

Cette pratique, qu’il a d’ailleurs expérimentée chez Enablon par le passé, consiste à monter une équipe temporaire, le temps de quelques sprints, en prenant les compétences nécessaires au sein de différentes équipes.

“C’est dur à faire passer auprès des responsables de ces dernières, car tu leur enlèves des ressources. Mais ça tue les interdépendances”, témoigne Benoit. 

2️⃣ Le/La manager à temps partiel

Ici, l’idée est de désigner un(e) PM pour être manager à temps partiel d’un projet transverse, en plus de son travail traditionnel. La personne aura donc la légitimité pour s’incruster dans la roadmap des différentes équipes concernées.

Ce qui a l’avantage de ne pas bouleverser l’organisation… mais peut épuiser à la longue la personne en question ! 

3️⃣ Les product ops 

Voici enfin une nouvelle profession qui est en train d’émerger dans les scale-ups : les product ops. Ce sont des personnes qui vont gérer les données pour les PM, les processus mais aussi… nos fameux sujets transverses (Thiga a d’ailleurs écrit un article plus détaillé sur cette fonction en début d’année).

 “Dans ce type d’orga avec des tribus, le/la VP produit est la seule personne transverse. Donc si un projet tombe entre deux chaises, soit tu as un/e PM ambitieux qui va le prendre. Soit, quand tout le monde est charrette, tu te retrouves à le reprendre toi. Mais ce n’est pas là où l’on t’attend, explique Benoit. Moi, je pense que demain, il y aura moins de profils dans les silos mais plus en transverse. C’est d’ailleurs ce que l’on voit dans des boîtes comme Payfit qui ont un département Product ops”.

Et demain justement ?

Lors de son entrevue avec le Ticket (effectuée dans des conditions… ubuesques que l’on vous racontera un jour), Benoit a aussi évoqué sa vision du métier et des organisations à l’avenir. Creusons tout ça.

Dans la catégorie nouveaux métiers, on vient de parler des product ops. Ajoutons aussi les product strategists, des PM qui travaillent uniquement… sur l’année suivante !“L’an dernier, en septembre, j’avais déjà ma roadmap pour 2020, assure-t-il. Quand on est sur un marché concurrentiel, il faut essayer de déceler et anticiper les futures tendances profondes. Donc de rencontrer des nouveaux acteurs émergents, de faire de l’analyse business et financière… Et comme les PM ont rarement le temps de faire vraiment de la strat’ et de la discovery correctement, c’est intéressant d’avoir un métier dédié à cela, décorrélé des techs”.

Jusqu’à l’année dernière, avant un changement de stratégie en interne, Deezer comptait d’ailleurs une stratège produit dans l’équipe. “Dans un monde idéal, à la fin de Q3 (= 3e trimestre), tu as ta stratégie pour l’année suivante que tu peux donner aux PM pour qu’ils puissent commencer à travailler sur la discovery, enchaîne Benoit. Et la clé de tout le système, c’est d’être en dual-track.” 

Traduction de cette dernière notion : les PM bossent avec un trimestre d’avance sur les tech. Précisons au passage que l’on n’est pas obligé d’avoir des product strategists pour s’organiser en dual-track. C’est la petite griotte confite sur le gâteau. 

“Par exemple, en Q1, le PM travaille sur la livraison de Q1 avec sa casquette de product owner (si besoin d’une petite définition de ce qu’est un PO, c’est ici) mais aussi et surtout à la discovery de Q2. Et quand on arrive à Q2, tout est ainsi déjà prêt pour les tech”, illustre Benoît. Avant d’ajouter un petit bémol : ceci est la théorie mais cela reste rare encore, car difficile à mettre en place. Il faut en effet réussir à désynchroniser les PM des dev’ à un moment donné. 

“Chez Enablon, on l’avait fait en faisant un trimestre blanc. Les techs n’ont fait que de la maintenance et de la résolution de bugs pendant que nous, au produit, on faisait de la discovery. Une fois que tu as fait ça une fois, tu es bon. Mais je n’ai pas réussi à le mettre en place chez Deezer, donc on essaie plutôt de grapiller du temps par-ci par-là”.“Le tandem CTO / CPO est temporaire” 

Être orienté « objectifs »

Autre conviction forte de Benoit : le rapprochement inéluctable de la tech et du produit au sein d’une même fonction. “Le tandem CTO / CPO (Chief Technical/product Officer) est temporaire selon moi et, demain, on aura certainement des Chief Product & Tech Officer ou Chief Development Officer. Car on se rend compte que chaque fois que tu mets des doubles casquettes, cela crée beaucoup de frictions qui n’ont pas lieu d’être”, présage ce profil technique, diplômé d’une école d’ingé.

“Certes l’émulsion entre deux personnes est intéressante mais je pense qu’il faut être fort dans les deux disciplines. Il y a une chose qui me gène dans le produit aujourd’hui, c’est qu’une partie des PM se dédouanent des problèmes de dette technique. Beaucoup disent : “Je ship de nouvelles fonctionnalités, occupez-vous de la maintenance”. Sauf que le produit ne gagne jamais quand il y a deux bandes passantes : les techs mettront toujours ce qu’ils veulent dans les tickets”. 

Alors oui, on entend déjà les commentaires : “Vous êtes bien gentils le Ticket, mais ces préconisations se destinent plutôt à des boîtes d’une certaine envergure et maturité. Mais on fait comment quand on est tout juste aux prémisses de notre passage à l’échelle ?”. Habile Bill.

Heureusement, Benoît a aussi quelques convictions profondes qui s’appliquent peu importe la taille de l’organisation : “Je pense personnellement que, même si tu as une petite startup, il faut sortir des équipes composants et passer à des structures orientées vers des objectifs. Ça, tu peux le faire même à une seule ou deux équipes. Pour moi, les feature teams vont même progressivement disparaître au profit des équipes qui s’attaquent à une problématique business. Ça donne le sentiment de vraiment participer au développement de l’entreprise”. 

Ce passionné de musique livre enfin un dernier petit conseil pour la route : “Il faut tester, tester et savoir reconnaître quand ça ne marche pas. Je vois des PM qui, au bout de quelques années d’expérience, pensent qu’ils savent. Moi, ça fait 11 ans que je fais du produit, 15 ans que je suis dans la tech… et je ne sais toujours pas ! Il n’y a pas une seule recette qui marche. Il faut donc être humble et être tout le temps en train d’apprendre”.

On ajouterait bien “en lisant le Ticket par exemple”. Mais c’est ce que vous êtes en train de faire visiblement 😉

---

Il était dans le Ticket :

Cet article est issu du Ticket n°003. On l’a publié avec ce sujet sur l’évolution de l’orga produit de BlaBlaCar et l’interview de Simon de Thiga.