Interview de Jeanne ONDA, Product Owner chez Axel

Est-ce que tu peux te présenter en quelques mots ?

Je viens des RH. Même si ce n’est pas la majorité des profils de Product Owners aujourd’hui.

Pour faire ce métier dans une grande structure – comme Algolia par exemple – il vaut mieux avoir été développeur avant. Tu peux moins facilement faire avancer le développement produit si tu n’as pas une compréhension technique. Chez Axel, notre évolution est encore devant nous. On essaie de designer des idées. Le métier est plus accessible même sans un background technique important.

D’où vient le métier de PO ?

Il existe depuis peu. Les premiers à l’avoir inventé étaient des géants comme Google ou Facebook pour leurs propres applications web. Des gens techniquement très qualifiés. Ces méthodologies ont fait leurs preuves. C’est pourquoi elles ont été reproduites par des entreprises plus modestes. Aujourd’hui sur des boîtes où la technique est moins complexe on peut s’en sortir sans se background mais il reste nécessaire de s’y intéresser et d’aimer baigner dedans.

Comment as-tu fait à tes débuts ?

Depuis le départ, je suis très en lien avec mes développeurs. Je leur parle matin et soir lors du Stand up meeting [ndlr : l’une des quatre cérémonies agiles*]. Le matin : pour savoir où on reprend, s’il s’est passé quelque chose pendant la nuit. Cela peut prendre 1’30 minute comme 20 minutes. Ces échanges m’ont permis de me familiariser rapidement avec leur univers. Aujourd’hui je suis proche de tout ce qu’il se passe. Cela prend du temps. Et en même temps, j’ai de mieux en mieux compris ce que je pouvais demander ou non. Dans quels délais et comment je pouvais les aider au mieux. Pour moi qui n’avait pas ce background technique et le besoin de plus de temps pour comprendre, c’est très utile. Je suis avec eux dans leur sujet. Méthodologiquement c’est le « truc » qui m’a le plus aidé.

Sur quel type de produits travailles-tu ?

Initialement, on fait de l’onboarding : l’intégration d’un nouveau collaborateur dans l’entreprise, sous la forme d’un chatbot qui permet de gérer la coordination de toutes les tâches liées. Le chatbot met en contact le nouvel employé avec toutes les parties prenantes : responsable RH, manager, etc pour que chacun réalise des tâches et que la personne se sente mieux.

Quel aspect de ton travail préfères-tu ?

Faire des choix forts pour l’entreprise. C’est une fonction très responsabilisante. Quel fonctionnalité on développe ? Qu’est-ce que l’on dépriorise pour l’instant ? Surtout à un stade comme le notre où le produit est en pleine croissance. Il y a des tas de choses qu’il faudra faire de toute façon. Intellectuellement c’est très stimulant. Il faut discuter avec toutes les parties prenantes : enquêtes, béta tests, échanges avec les utilisateurs, les développeurs… Réunir toutes les variables pour prendre les décisions nécessaires. Tout ce travail en amont te rassure, tu t’appuies dessus pour avancer. C’est un métier dans lequel tu prends des décisions importantes qui ont un impact énorme. Je n’en avais pas pris toute la mesure avant d’arriver sur le post et c’est maintenant ce que je préfère.

Peux-tu me parler de cette phase de travail en amont de la prise de décision ?

Moi je m’occupe principalement de la partie béta tests. Les 1res impressions sur le produit sont recueillies par mon CEO. Je reçois les béta testeurs, je fais installer la solution et je les assiste en mettant en place un suivi pendant trois mois sur la découverte de l’outil. Ce sont des réunions où l’on debrief de l’utilisation : ce qui est évident ou non dans la prise en main, ce qui fonctionne et ce qui fonctionne moins bien.

Nous avons pris le parti de ne pas tester juste notre cible. Notre échantillon de béta testeurs est plus large pour pouvoir se tourner vers un autre segment si l’on se rend compte qu’une adaptation doit être donnée au produit. Il arrive fréquemment que les beta testeurs nous révèlent des éléments très importants, que moi et mon équipe n’avions pas vu. Des clics superflus par exemple.

Et concernant ta formation ?

Ce qui m’a énormément aidé c’est de parler avec des Product managers. De les interviewer, comme ce que tu fais toi. Des méthodologies de user research il en existe beaucoup. Parler avec des pros m’a appris qu’à aucun moment on ne lance une nouvelle feature sans être sûr que c’est la bonne configuration. Dans mon entreprise on test rapidement. On ne passe pas des mois à travailler sur une fonctionnalité si elle n’est pas vendable. On avance par petits pas, en test and learn.

Ce qui m’a beaucoup aidé, pendant le confinement, ce sont les webinars, des organismes de formation orientés startups : Lion ou Noé par exemple.

Selon toi, quelles sont les qualités qui font un bon Product Owner ?

Aimer l’humain. 50% du travail consiste à gérer les besoins de chacun, les ego… On parle tout le temps, avec tout le monde et le but est de trouver des compromis. Organiser sans donner l’impression que l’on fait le chef.

Ensuite cela peut valoir le coup de faire un petit bootcamp pour être plus à l’aise sur la technique à l’arrivée.

Enfin je dirai qu’il ne faut pas avoir peur de prendre des décisions, d’être la personne vers qui tout le monde se tourne pour trancher.

T’est-il déjà arrivé de récupérer un projet que tu n’avais pas initié ?

Quand je suis arrivée j’ai commencé directement sur le futur produit donc non pas vraiment.

Que conseillerais-tu à quelqu’un qui débute dans le métier ?

Comme je l’ai dit : un petit bootcamp ne fait de mal à personne. Ce n’est pas nécessaire mais c’est beaucoup plus simple. Personnellement j’ai appris vite et sur le tas mais cela a été difficile au début. Une petite formation technique peut amortir l’atterrissage. Je ne pense pas qu’il faille absolument avoir un background développeur cependant.

Merci Jeanne pour tes réponses et ton temps. C’était un plaisir de parler métier avec toi.

Jérômine

  • Les cérémonies agiles sont au nombre de quatre : le stand up meeting avec le sprint planning, la sprint review et la retrospective permettent de borner le déroulement d’un projet en plusieurs phases nommées itérations ou sprints