Plongez dans les coulisses de l’organisation Produit d’En Voiture Simone avec Estelle Aubouin, Head of Product, qui a participé à la transformation de l’entreprise en instaurant l’agilité et les bonnes pratiques du Product Management.
1. La découverte du Product
“A mon arrivée, mon job de Product Manager devait se limiter à faire des maquettes fonctionnelles et à les envoyer à la tech.”
Estelle a intégré En Voiture Simone en juin 2018 en tant que 1ère Product Manager.
Son rôle était de mettre en place les bases d’une organisation en mode produit.
Seul problème : elle n’avait jamais fait de Product Management en tant que tel. Il a donc fallu apprendre sur le tas.
Mise en place de l’agilité en septembre 2018, élaboration de la première roadmap Produit, lancement d’une app mobile avec 2 développeurs, les chantiers se réalisaient avec succès pour cette première année.
Estelle concède que ce n’était pas vraiment du Product by the book, mais cela n’a pas empêché le produit d’avancer !
2. Optimiser le temps
”Une réunion qui déborde trop peut obliger à décaler un sprint, on doit donc être très bien organisé !
Progressivement, l’équipe grandit et Estelle passe CPO.
Elle se penche alors sur la question de la productivité et de la standardisation des process.
Un Product Playbook a été mis en place afin de lister toutes les étapes et validations nécessaires à la conception d’un produit ou d’une feature, avec des templates type pour chaque livrable.
On peut retrouver ce même travail chez Yespark dans ce qu’a mis en place Pascal Messana, Head of Product.
Pour Estelle, le travail d’un Product Manager est chronophage, il est donc dommage de perdre du temps sur les phases de gestion de projet. Si elles sont standardisées, c’est un gain de temps précieux !
Actuellement, l’équipe est composée de 2 Product Managers, d’un Product Designer et de 9 développeurs, et fonctionne en squads avec des sprints d’une semaine.
3. Amélioration continue
“Il faut dédramatiser, tout le monde peut faire des erreurs !”
Selon Estelle, c’est dur d’avoir une bonne culture du feedback, car cela oblige à prendre constamment du recul sur son métier et à faire son introspection.
Chez En Voiture Simone, les équipes s’astreignent vraiment à faire cette autocritique régulièrement dans le but de faire progresser le collectif.
Il y a 1 retro par squad et 1 retro spécifique à l’équipe Produit par semaine.
Cela permet de continuellement nourrir les réflexions sur les pratiques Produit de l’équipe, d’enrichir le Product Playbook et de faire évoluer certains templates de document par exemple.
Qu’il y ait des couacs, c’est normal, l’essentiel c’est de ne pas les reproduire !
Ce point de vue pourrait être partagé par Alexandra Leloup, VP Product de Deezer, qui met en avant la responsabilité collective de l’équipe sur chaque sujet.
4. Un team Support au top
“Pour attendre une haute satisfaction client, la client, la collaboration Support / Produit doit être parfaite.
La force d’En Voiture Simone, c’est que l’entreprise est jeune et que donc toutes les équipes se sont acculturées au Product en même temps.
C’est le cas de l’équipe Support qui fait gagner un temps précieux à l’équipe Produit sur le run mais aussi sur la discovery.
Côté discovery, la team Support identifie au fil de l’eau les feedbacks clients les plus pertinents sur Zendesk et les envoie directement au Produit.
Tout se passe via Harvestr, un logiciel de collecte et de centralisation des feedbacks utilisateurs.
Comme c’est le cas pour les équipes d’AB Tasty, lorsqu’un PM cherche un feedback sur une thématique, il y en a déjà des dizaines de répertorié !
Côté run, le Support est formé à évaluer la criticité des bugs, qualifier les demandes et utiliser les bons canaux d’alerte en fonction des problématiques. Cela facilite grandement le travail de la team Produit/Tech.
5. Un delivery plus focus
“On avait une fâcheuse tendance à avoir les yeux plus gros que le ventre !”
Côté delivery, l’équipe avait l’habitude de concevoir en amont l’ensemble d’une feature en la découpant en user stories. Une fois le projet défini et tous les cas d’usage prévus, les specs étaient livrées à la Tech.
Cependant, cela ne leur a pas permis d’éviter certains effets tunnels (complexité technique mal anticipée par exemple).
Désormais, si les grosses features sont toujours découpées en macro user stories indépendantes, celles-ci sont traitées une à une, de façon isolée par les PM.
Ainsi, l’équipe conserve la vision d’ensemble mais n’a plus la charge mentale d’anticiper tous les cas d’usage en début de projet.
Cette démarche vise vraiment à pousser l’incrémental au maximum pour gérer au mieux l’incertitude et les aléas.
