Trouver son orga produit, c’est s’informer, tester, s’ajuster, galérer… Voici l’histoire de ce qu’il s’est passé sous le capot de BlaBlaCar.
En bon consultant en strat’ qui se respecte, c’est en costard-cravate que Benjamin Retourné se pointe à son entretien d’embauche. Sauf que la boîte s’appelle Covoiturage.fr et que tout le monde est alors en jean-basket…
Un fashion faux pas qui ne l’empêchera pas de devenir, en janvier 2014, l’un des premiers PM du leader mondial du covoiturage, renommé BlaBlaCar entre temps (+ de 90 millions de membres dans une vingtaine de pays).
Près de 7 ans plus tard, celui qui est devenu Head of product chargé de l’expérience passager, est toujours à bord et est donc un témoin privilégié pour nous raconter la construction progressive de l’équipe produit au sein de la première licorne française et l’évolution de son organisation. Récit.
Commençons par un peu d’archéologie, en dépoussiérant la première annonce d’embauche pour un BlaBlaPM datant… de 2011 !
“Je me souviens que c’était inhabituel de recruter sur un poste comme celui-ci, différent de simple « Project Manager », et qu’on me disait : « Mais Fred, le produit, c’est toi. Pourquoi recruter quelqu’un d’autre ? »
Frédéric Mazzella, président fondateur de BlaBlaCar
Ce dernier a d’ailleurs retrouvé dans ses archives l’offre en question (ça, pas sûr que vous le trouviez ailleurs que dans Le Ticket)… où l’on se rend compte, au-delà du bon logo old school de l’époque, que les candidats devaient détenir de 2 à 4 années d’expérience de PM… idéalement en C2C !
Exigence qui frise avec l’anachronisme tellement la conso collaborative et le produit étaient des affaires d’initiés (/de hippies) à l’époque. L’heureux élu l’avait d’ailleurs joué plutôt honnête.
Malgré cette vision précoce, l’équipe produit plafonne pourtant longtemps à trois ou quatre personnes. “Déjà, le 1er PM de BlaBlaCar, c’était Fred Mazzella et ça reste un PM incroyable, explique Ben Retourné. Ensuite, on balbutiait pas mal et on essayait de trouver notre place entre la tech et le business. Le métier était encore nouveau”.
Ajoutons aussi qu’à cette époque, BlaBlaCar ouvrait des pays comme on enfile des perles (une quinzaine entre 2012 et 2015) et que le besoin était plus orienté vers des profils de launchers (= sorte de défricheur / développeur géographique).
2015 – 2017 : l’épopée des Tribes
En fait, le premier grand virage produit de BlaBlaCar se passe fin 2014. Fred Mazzella veut mettre l’accélérateur sur cette fonction et il organise un trip dans la Silicon Valley avec le head of product et les deux PM de la boîte, Perrine Labesse et Benjamin donc.
“On part une semaine à la rencontre des équipes produit de Airbnb, Dropbox, Twitter, Linkedin, SmartRecruiter… L’occasion de se rendre compte que, déjà, c’est un vrai métier qui est super développé et processé chez eux. Mais aussi qu’en 5 jours, on découvre 15 boîtes… et 15 manières de faire !”
Benjamin Retourné (BlaBlaCar)
Si quelques idées glanées sur place se concrétiseront par la suite, comme la création d’une équipe Member Voice (= voix du membre, l’ancêtre de ce que l’on appelle aujourd’hui la recherche utilisateur), c’est malgré tout une société européenne qui va inspirer la nouvelle orga produit de BlaBlaCar : Spotify.
“À l’époque, on fonctionnait en équipes composants (= par pôle de compétences), c’est-à-dire Desktop, Web Mobile, iOs et Android. Les PM ne faisaient que de la delivery (= en gros ici l’exécution d’une multitudes de petites tâches) et de la gestion de projet. On avait l’impression de ne faire que dépiler des tickets. On s’est donc dit qu’il fallait reconnecter la roadmap tech et produit avec des objectifs business, tout en gagnant en autonomie et en rapidité d’exécution”, explique Benjamin.
En 2015, BlaBlaCar opte donc pour la voie des feature teams (équipes fonctionnalités), popularisées trois ans plus tôt par la firme de streaming suédoise (en tout cas, par deux de ses coachs agiles).
En résumé (vraiment synthétique) : au lieu de fonctionner par métier, les équipes deviennent pluridisciplinaires (on rassemble des PM, des UX, des dev…) et exclusivement orientées vers une mission ou une donnée à améliorer. Elles sont donc autonomes pour améliorer ou créer une fonctionnalité.
Une équipe pilote est alors constituée en interne (dont Benjamin fait partie) pour tester cette nouvelle mouture. Devant l’autonomie acquise par l’équipe et l’enthousiasme général que cela provoque, l’ensemble des troupes basculent très vite ensuite vers ce modèle.
Six Tribes (tribus) sont alors mises sur pied:
- Grow (acquisition)
- Monetize (monétisation)
- Trust (confiance)
- Care (soutien aux membres)
- Engage (engagement)
- et Satisfy (maximisation du NPS)
Elles-mêmes subdivisées en sous-sections, les “Squads” (rien à voir avec le boysband).
“Ça devient vite le bordel”
Deux ans plus tard, l’expérience est malgré tout abandonnée. Sortie de route. Benjamin dresse le constat : “Si tu n’as pas de garde fou dans ce type de système, ça devient vite le bordel. Au bout d’un an et demi, tu te rends compte que chaque équipe a optimisé son pré carré mais que personne ne s’est soucié de la cohérence d’ensemble. Et ça, on l’a payé d’un point de vue tech. On avait créé une stack technique qui ne ressemblait plus à rien. On rajoutait, certes rapidement, des étages à l’immeuble mais les fondations étaient toutes pétées.”
Avec du recul, il estime que les leçons apprises lors du séjour en Californie ont trop rapidement été oubliées : “On avait vu que, certes, ce métier existait. Mais que la manière de l’appliquer dépendait de la culture de la boîte et des personnalités de l’équipe. Chez Airbnb, une boîte très design, les PM étaient très axés autour de l’expérience. Chez Linkedin, qui est plus orienté business, on retrouvait plus de PM dédiés à l’optimisation de la donnée. La culture de boîte changeait le métier et les organisations. Et en fait, ils bossaient tous différemment car ils optimisaient ce qui était le plus important pour eux.
Nous, on cherchait une méthode magique. On a donc pris la boîte la plus proche de nous pour la copier. Alors qu’en fait, il faut construire sa propre méthode en allant prendre ce qui te plaît par-ci par-là. Pour faire une analogie, je ne connais personne qui s’habille exactement comme dans les pubs des marques de fringue. On se crée notre propre style en fonction de la personne que l’on est”.
D’autant qu’il s’avère que la fameuse orga “à la Spotify” est un mythe… et que même Spotify ne l’utilise pas ! “Même au moment où l’on a écrit ce modèle, nous ne le faisions pas. Il y avait une part d’ambition et d’approximation. Les gens ont vraiment galéré à copier quelque chose qui n’existait pas vraiment”, indique le flegmatique Joakim Sundén, coach agile de 2011 à 2017 chez Spotify dans cette vidéo (où il semble d’ailleurs rendre un bel hommage au premier logo de covoiturage.fr avec sa chemise).
2017 – … : Les équipes “parcours utilisateur”
En 2017, Ben Retourné et une partie de l’équipe produit de BlaBlaCar retournent dans la Silicon Valley pour parler passage à l’échelle.“On était 2 PM la première fois, on était désormais 10. Donc on voulait voir comment les boîtes américaines étaient passées de 10 à 50 puis à 100. Et là, on s’est rendu compte qu’on avait sûrement un complexe d’infériorité en France car toutes les boîtes nous répondaient… qu’elles ne savaient pas ou que leur méthode n’était pas parfaite !”
La rencontre chez Twitter l’a de ce point de vue particulièrement marqué. “Dans la salle, tu avais le VP product et 4 ou 5 PM. On leur disait que nous nous marchions parfois sur les pieds à 10 PM donc on leur a demandé comment ils faisaient eux, à près de 100 PM. Blanc dans la salle… Le VP product répond finalement : “Je ne sais pas, on n’a pas trouvé la solution !”
Et là, tu réalises qu’ils galèrent comme nous en fait. Et que les US n’ont pas forcément la réponse à tous nos problèmes.”
Toujours est-il que, depuis, une nouvelle organisation produit, faite sur-mesure cette fois, s’est imposée chez BlaBlaCar.
Concrètement, l’équipe s’est organisée autour des trois grands types d’utilisateurs de la plateforme, à savoir les passagers, les conducteurs de covoiturage et les opérateurs de bus (au cas où vous auriez raté un train, BlaBla a en effet racheté Ouibus à la SNCF milieu 2019). Puis le découpage se fait en fonction du parcours utilisateur.
Par exemple, Ben, en tant que responsable de la partie passagers gère une squad qui s’occupe de la recherche, une autre de la réservation et une troisième de l’inscription (acquisition et SEO). Côté conducteurs et opérateurs de bus, on retrouve une équipe “publication” ou encore “communication”.
Enfin, des squad backend plus transversales gèrent certains services, comme le paiement par exemple. “On avait opté pour les Tribes pour l’autonomie. Là, on a voulu optimiser l’ownership du code avec des personnes qui gèrent des bouts entiers du code et de l’expérience, affirme Benjamin. Ils connaissent le sujet par coeur et peuvent donc l’optimiser à fond”.
Une organisation vivante
Un modèle qui pourrait servir d’inspiration à d’autres ? “Des méthodes d’orga, il y en a une quarantaine et on utilise tous les mêmes, répond-il. Il ne faut pas se prendre la tête et construire ce qui te va à toi. Moi, je pose tout le temps deux questions aux PM que je croise : comment tu es organisé ? Et qu’est-ce qui marche bien et qui ne marche pas ? Sinon, tu vas toujours trouver les idées des autres trop biens, sans connaître toute la réalité derrière”.
Message reçu. Donc… qu’est-ce qui ne marche pas chez BlaBla dans cette organisation Benjamin ? “Bè, comme on est une place de marché, il y a des bouts de notre orga qui sont à cheval entre plusieurs parties et on ne sait pas trop où mettre les gens parfois. Mais au final, je pense qu’on ne trouvera pas la règle idéale… et il ne faut même pas qu’on la cherche ! Je crois qu’il faut accepter que son orga soit conçue pour 80 % des cas et que, dans les 20% restants, ça ne marche pas. Et qu’il faut juste être hyper efficace pour résoudre les problèmes ensuite.”
Exemple très concret : un projet tombe sur la page d’accueil. Est-ce à l’équipe acquisition de s’en occuper ? Ou plutôt celle dédiée à la recherche passager ? Autrement dit, est-ce que la Homepage est un outil d’acquisition ou la première étape de la recherche des utilisateurs ? La traditionnelle querelle de chapelle…
Selon Benjamin, toutes les six semaines à chaque nouveau sprint, il y a toujours un projet qui tombe ainsi entre deux chaises. Mais, à chaque fois, la question se résout en quelques jours par la discussion. “Franchement, dans l’illustration évoquée, j’avais autant d’arguments pour l’une que pour l’autre. On s’est demandé alors pourquoi on faisait ce projet et il s’est avéré que c’était un problème purement passager et que les personnes qui ont déjà travaillé sur le sujet font partie de l’équipe recherche. Donc ce sont eux qui s’occuperont de cette page et de sa maintenance. On essaie ça pendant 6 mois et on voit”.
Cette dernière phrase résume bien, au final, l’un des principaux apprentissages de Benjamin sur le sujet. “L’erreur, à l’époque des Tribes, c’est qu’on s’était dit que ça allait être notre modèle pour les quinze prochaines années. Alors qu’en fait, quand on parle d’organisation, il faut toujours être dans une démarche de test, d’adaptation, de scale et de vigilance tous les 6 à 12 mois, en se demandant si on est toujours dans la bonne configuration. Et si ça ne marche plus, on change”.
Avant d’ajouter une nuance importante : “Il ne faut pas négliger un truc quand même: les gens se fatiguent des changements perpétuels ! Une startup, c’est une boîte qui va vite dans son exécution et dans sa réflexion. Ce qui ne veut pas dire tout péter tout le temps non plus !”
Il était dans le Ticket :
Cet article est issu du Ticket n°003. On l’a publié avec cette interview du VP product de Deezer et celle de Simon de Thiga.
Comment ?! Vous n’êtes pas abonné(e) ? Corrigeons tout de suite cela 👇
