1. Apprendre à déléguer

“je me vois comme une rampe de lancement sur laquelle les équipes peuvent s’appuyer. Je suis là pour donner de l’impulsion.”

Audrey intègre Evaneos en tant que Product Manager en 2017.

Evaneos est une marketplace de mise en relation entre voyageurs et agents de voyages à destination pour co-construire des itinéraires sur-mesure.

En tant que Product Manager, Audrey appréciait le fait d’être les mains dans le cambouis, de devoir mettre de l’huile dans les rouages, d’avoir un impact direct sur le produit.

Désormais Head of product depuis 2020, Audrey est en charge d’une équipe de 14 personnes (7 PM et 7 designers).

Moins disponible, il est plus difficile pour elle d’apporter ce liant au niveau opérationnel.

Il fallait donc accepter de lâcher du lest, construire un système où les équipes sont “empowered«  pour qu’elles soient vraiment autonomes pour prendre des décisions.

2. Redonner du sens

“Nous devions formaliser une histoire imagée de ce que nous voulions que soit l’expérience qu’un voyageur vivra avec Evaneos dans 10 ans.”

Audrey a pris son poste de Head of Product après une année de Covid, sans business. La taille des équipes avait été diminuée par 2, et de nombreux profils seniors avaient quitté la société.

Le premier axe de travail a donc consisté à redonner de la confiance, par du coaching collectif sur les pratiques Product, mais aussi à redonner du sens à l’équipe.

Pour cela, il apparaissait important de formaliser la vision produit, vision qui était dans la tête des plus anciens mais restait très abstraite pour les autres. Il fallait créer une histoire à la fois inspirante et réaliste sur ce que serait le produit d’ici 5 à 10 ans.

Audrey a choisi de formaliser cette vision produit en vidéo, sous forme de petits mockup de personnages. Il y a une version courte (4 min) et une version longue (10 min), en français et en anglais, accompagnée d’un document de “décryptage” qui met l’accent sur les concepts clés de la vision.

2 ans après, les équipes s’y réfèrent encore que ce soit pour confronter les initiatives du quotidien à la vision long terme ou encore pour accueillir les nouvelles recrues.

3. Basculer en Impact Teams

“Il fallait trouver un équilibre entre une vision produit très expérientielle et la réalité business de notre modèle.”

Après avoir retravaillé la vision, le choix est fait de basculer d’une organisation historique par produit à une organisation en Impact Team, pour 3 raisons :

• Mieux maîtriser les investissements : Quand s’arrêter dans l’amélioration continue d’un produit ? Comment répartir l’effort différemment pour s’adapter au contexte business ?
• Ancrer la mesure de l’impact au coeur de la démarche Product.
• Se débarrasser des interdépendances entre les squads quand il s’agit de livrer de la valeur , ce qui ralentit le rythme de conception & de livraison.

Chaque impact team a un objectif business, rattaché à un objectif macro au niveau entreprise et est rendue autonome pour atteindre cet objectif, quel que soit le produit ou la stack technique à faire évoluer. Cette organisation implique de ne pas couvrir 100% du périmètre fonctionnel, il peut donc y avoir quelques “trous dans la raquette” au niveau de la maintenance mais ils sont connus et il y a une réalité opérationnelle où chaque équipe est garante du “run d’un périmètre.

4. Adapter la conception

“Shape Up amène du ryhtme et un focus que l’on n’arrivait pas à avoir avec des OKRs.”

Initialement l’équipe se pilotait avec des OKR par semestre, ce qui est bien en termes de temporalité car on a le temps de mesurer les effets d’une fonctionnalité mais c’est difficile de garder les équipes focalisées sur un seul enjeu pendant 6 mois, c’est trop long.

Depuis près d’un an, l’équipe a adopté la méthodologie Shape up avec des cycles de 8 semaines : 6 semaines focus sur des initiatives avec des objectifs business chiffrés et 2 semaines de “cool down” pendant lesquelles sont gérés les sujets de maintenance non critiques et les petites évolutions à la marge.

La particularité de cette méthodologie c’est que, théoriquement, si un projet n’est pas fini à temps, dans les 6 semaines, il est abandonné.

Donc au lieu de se projeter jusqu’à la fin du cycle, au risque de déborder hors des 6 semaines et de voir son projet s’arrêter, les équipes cherchent à amener de la valeur utilisateur très rapidement, au bout de 2 ou 3 semaines, et itèrent dessus ensuite.

5. Documenter la discovery

“Si la connaissance reste dans notre tête, elle n’est pas utilisable par le reste de l’entreprise.”

Pour Audrey, la discovery n’est pas de la responsabilité du PM tout seul. Chez Evaneos, c’est un quator qui a l’ownership de cette phase : le produit, la tech, le design et la data.

Afin de soutenir les équipes, il a donc été décidé de renforcer les compétences de toute l’équipe Produit sur les méthodes de discovery et de recherche utilisateur.

Plusieurs templates ont été formalisés dans un Notion d’équipe, notamment une “research problem base”, qui centralise tous les problèmes utilisateurs que l’on investigue, et la base de données d’insights qui en découle, synthétisant les éléments de connaissance utilisateur identifiés.

Cela permet à la fois de faciliter pour tous, l’accès à la connaissance utilisateurs, mais aussi d’homogénéiser les pratiques.

En revanche, l’équipe reste libre sur la façon de mener la discovery, il n’y a pas de templates imposés pour les interviews, pas de questions type à se poser avant de lancer un AB Test, etc…

C’est de la responsabilité du fameux quatuor !