Romain a une longue carrière produit derrière lui. Après son diplôme des Beaux Arts il a – entre autres – occupé le rôle de PM chez PeopleDoc, Contentsquare et aujourd’hui Bellman Immo.
Il nous parle de faire du produit dans des secteurs très différents, d’auto onboarding, de dépoussiérer un secteur archaïque, de culture de l’asynchrone et de faire de la discovery de manière artisanale.
Je suis diplômé des Beaux Arts et dans le cadre de mes études je travaillais sur des installations multimédia, ce qui m’a amené à me former à Flash et à l’action script. Pour moi le web c’était un médium d’expression créatif comme un autre.
"Ce que j’aime dans le produit c’est de résoudre les problèmes sans forcément savoir comment on va développer la solution."
Ensuite j’ai rejoint une association en tant que développeur full stack, je me suis spécialisé en développement front end qui se rapprochait le plus de l’aspect créatif et visuel. J’ai rejoint une startup (Icone) qui était un réseau social dédié à la mode (depuis ils ont pivoté vers le modèle agence pour des marques de luxe) où j’ai été propulsé au poste de CTO et j’ai monté une équipe de serial killer. Au sein de cette boîte un besoin produit est né et j’ai pris ce projet en main pour monter un produit. J’ai réalisé que je m’éclatais plus au produit qu’à la tech. Ce que j’aime c’est résoudre les problèmes et pas forcément de savoir comment on va développer la solution.
Pendant ma carrière j’ai eu la chance d’évoluer dans des entreprises au sein d’industries très différentes: un réseau social dans la mode, une entreprise de finance dans le cloud, une entreprise RH, puis Content Square côté analytics et expérience utilisateur, et depuis récemment une startup dans l’immobilier. Ce que j’évalue c’est le produit et les perspectives du produit. Même si c’est un secteur que je connais peu, si j’arrive à comprendre les challenges et les objectifs et que je sens que je peux apporter quelque chose aux utilisateurs, alors je fonce !
La première chose que je fais avant même de démarrer le job c’est d’organiser mon onboarding à 7, 30 et 90 jours. Je me donne des objectifs pour être sûr de ne pas être largué. Bien sûr ce plan d’onboarding est hypothétique et est amené à évoluer au moment où je commence. L’expérience d’onboarding peut vraiment varier d’une entreprise à une autre.
Dans l’une de mes expériences passées, l’onboarding commençait avec une semaine entière dans la peau du client, pour avoir une réelle compréhension du produit. Et je trouve ça génial, parce que peu importe ton équipe, tout le monde avait la même connaissance du produit. Mais en réalité l’onboarding est souvent peu défini. Donc plutôt que d’être dans l’attente je préfère prendre l’initiative de faire mon propre plan d’onboarding.
J’ai rejoint une boîte d’une cinquantaine de personnes (Bellman Immo) il y a un peu moins de 2 mois.
Ce qui est drôle c’est que sur le papier c’est pas très sexy. C’est un syndic de copropriété. Pour le contexte, le modèle historique du syndic de copropriété, c’est un petit cabinet avec un comptable et un gestionnaire qui gère les tracas du quotidien (envoyer un électricien pour réparer une porte …) et qui vote des travaux pendant les assemblées générales qui ont lieu plusieurs fois par an.
Ce qui a attiré mon attention quand ils m’ont contacté, c’était l’objet de mail de la recruteuse “Rejoins nous pour dépoussiérer le monde du syndic de copropriété”. Et l’idée de dépoussiérer ça m’a parlé, je me suis rendu compte qu’il y avait une idée d’innover dans un secteur archaïque. J’ai rencontré les fondateurs et j’ai adoré leur approche: ils n’ont pas pour ambition de réinventer la roue mais de transformer la roue en aéroglisseur.
L’intention c’est que la gestion de l’habitation soit sans stress, facile, et transparente pour les propriétaires. Comment ? En mettant à leur disposition des outils comme la visio pour assister aux assemblées générales, des outils de suivi de finances, la possibilité de payer en ligne… Ces outils on les retrouve dans un portail avec 2 back office: un back office pour le comptable / gestionnaire et un back office pour les propriétaires.
Tu as l’orga produit devant toi ! Avant c’était une responsabilité partagée par le CEO, le CTO et l’équipe de dev. L’objectif est de structurer tout ça et je le fais avec une product designer qui est arrivée en même temps que moi.
Je suis encore en phase d’observation. Le but n’est pas de casser les process en cours et interrompre le rythme actuel. Le moment venu on remaniera les process pour en mettre en place des nouveaux.
Par ailleurs, il y a déjà des process en place qui sont vraiment bien. Par exemple, nous avons un Product Board intégré à Slack qui permet à n’importe qui (gestionnaires, comptables) de faire des retours produit depuis un channel Slack, qui sont ensuite compilés dans un product Board.
Ce que j’aime beaucoup c’est qu’il y a une forte culture de l’asynchrone, de l’écrit, tout ou presque est dans Notion, il y a peu de réunions et le peu de réunions que l’on fait ont un objectif clair et défini.
La durée de la phase de discovery est très réduite. Nous avons besoin de prendre des décisions rapidement. Le gros challenge est de faire de la discovery de manière artisanale en essayant de se planter au minimum. L’objectif est de pousser la feature la plus MVP-compliant possible sans passer par 3 semaines de discovery. On le fait en se définissant des objectifs de discovery très clairs.
C’est le moment wow effect au moment de pousser une feature et que tu récoltes des feedbacks positifs ou négatifs d’ailleurs!
J’essaie d’identifier d’où peut venir mon erreur. Ça peut être une erreur de scoping du besoin, une mauvaise identification du persona concerné… Pour répondre à cette question en général je vais en parler directement à la personne concernée et je vais creuser le pourquoi de son insatisfaction.
Ça m’est arrivé par exemple cette semaine sur une nouvelle feature de génération de demande de devis avec saisie automatique des informations. Aujourd’hui tout ceci est géré par email. Le feedback que j’ai reçu c’est “j’utiliserai peu cette feature”. Il s’avère qu’il n’était pas forcément conscient de la bande passante que lui prenait la gestion d’erreur de transmission d’informations aux prestataires. Il n’avait pas conscience du pain point que l’on essayait de résoudre. On a pu recadrer la discussion et lui présenter comment cette feature l’aiderait dans son quotidien.
Je vois depuis un an ou deux de nouvelles formations produit se lancer. Pour moi ça revient à entrer par la grande porte, ce qui n’existait pas jusque là. Pour devenir PM le plus simple est encore de faire preuve de beaucoup d’empathie et d’y aller au culot, de tenter des moves en interne, ou bien, au moment de postuler, de construire des use case pour prouver sa connaissance produit, sa motivation et sa bonne compréhension du marché.
Donne plus de contexte. Que ce soit face à des execs, des investisseurs, des comptables ou des développeurs, un PM doit être capable de donner du contexte, de mettre en perspective ce qui est présenté, au risque de perdre ses interlocuteurs qui ne comprendront pas forcément le pourquoi du comment. Il faut savoir se mettre dans leur système de compréhension, s’adapter à leur objectifs, leur vocabulaire.