1. Getaround Connect

“Très rapidement, nous avons été convaincus que Getaround Connect était le futur de l’entreprise.”

Raphaël est arrivé chez Getaround (Drivy à l’époque) en 2014 pour développer Getaround Connect, une solution de télématique qui permet d’ouvrir les voitures avec son téléphone.

Jusqu’alors, Drivy était une marketplace où les locataires et les propriétaires devaient se retrouver pour se passer les clés.

Sur Getaround Connect, Raphaël a participé à la construction du business model et à la validation du Product Market Fit pendant 1 an, puis s’est chargé de constituer une équipe.

Cette solution a représenté jusqu’à 25% du CA de Getaround à tel point qu’il a été décidé de réintégrer Getaround Connect dans la proposition de valeur globale de Getaround.

Raphaël a alors rejoint une équipe Produit qui existait déjà, dans laquelle se trouvaient également 3 autres Product Managers.

2. Structurer le mid-management

“Cela me parait normal d’avoir un bon équilibre managérial entre mes 3 équipes.”

En 2020, Raphael est promu VP Product et récupère le Product, la Data et le Design. L’équipe est composée d’une trentaine de personnes et de 3 pôles (Data, Product Management & Design).

Alors que le Design et la Data était gérés par un head of, Raphaël devait initialement conserver en direct l’équipe Produit (6 PMs).

Le premier changement structurant opéré a été de faire évoluer Charles Vahanian au poste de Head of Product Management.

En faisant cela, Raphaël disposa donc d’un relai n-1 sur chaque team et s’assura de traiter les 3 pôles au même niveau.

3. Etre proche du business

“Si on ne se dit pas qu’une squad va durer pendant les 2 ou 3 prochaines années, on ne la crée pas.”

Actuellement, l’équipe compte 9 squads. Certains PM peuvent en avoir 2. Pour les squads rapprochées, des Tribes ont également été formées.

Chaque squad a une mission, dispose d’un périmètre fonctionnel bien défini et se doit d’être pérenne dans le temps.

Un business stakeholder de chaque département est rattaché à chaque squad :

• Cela évite le côté boite noire, ils sont contributeurs, ont de la visibilité sur la roadmap et sont acteur lors de la priorisation
• Cela oblige à rester focus sur un objectif unique, celui du stakeholder en lead

En revanche, cela n’est possible et pertinent qu’avec une taille d’équipe suffisamment grande selon Raphaël.

4. Prioriser par l’impact

“On a pas de framework dédié à la priorisation, l’important c’est que les outputs servent les OKRs.”

Les priorisations ont lieu chaque trimestre et doivent être faites par rapport aux OKRs de l’entreprise.

A la fin de chaque trimestre, chaque PM présente l’impact généré de chaque nouvelle feature sur les OKRs.

En tout, l’entreprise compte entre 6 à 8 OKRs. Chaque squad agit sur 1 à 2 OKRs en particulier.

Globalement, les PMs s’appuient sur 3 types d’inputs pour prioriser :

• Stratégie d’entreprise (vision marché)
• Business stakeholder (vision opérationnelle)
• Discovery (UX research et data : vision utilisateur)

Certaines features sont tagguées “exploratoire” et ½ journée par semaine dans la roadmap leur est réservée.

La roadmap est faite au trimestre avec des rituels à la semaine (kick off hebdo) et des plannings de suivi de charge pour chaque dev, mais il n’y a pas de rituels agile, pas de sprints.

5. Bien communiquer

“Si chacun sait quel est son rôle, on gagne beaucoup de temps.”

Pour chaque initiative, l’équipe utilise un framework décisionnel pour savoir qui fait quoi :

• R – ecommand : personne qui lead
• A – gree : personne qui valide ou qui a un “droit de véto”
• P – erform : personnes qui composent la squad
• C – onsult : personnes à qui demander des avis
• I – nformed : personnes auprès de qui communiquer
• D – ecision maker : personne qui tranche en cas de besoin d’arbitrage

Parmi les pratiques mises en place, plusieurs visent à fluidifier la communication :

• Un channel slack par feature (pour que les PM communiquent sur l’avancement de leur feature)
• Un channel slack par squad (pour que les gens puissent poser des questions en direct à une squad)
• Une “release update” d’équipe de manière hebdo

Enfin, la documentation est faite de manière continue, et cela facilite beaucoup les onboardings.