Apolline Vernay

Il existe de multiples façons de devenir Product Owner ou Product Manager. Certains ont fait des études d’ingénieur ou de commerce plus ou moins prestigieuse, et d’autres y sont arrivés au détour d’opportunités professionnelles et parfois de reconversions. Ces parcours un peu différents et tout aussi intéressants donnent à ceux qui les empruntent une vision singulière de leur métier.

C’est le cas de Nicolas, qui est devenu Product Manager après des études courtes et des débuts en tant que développeur. Il nous raconte son histoire.

Mes premiers pas

Après DUT Informatique, j’ai occupé le poste de développeur de 2010 à 2018, une première année dans une ESN puis huit ans dans une PME que j’ai co-fondée avec trois autres associés, et qui accompagnait les entreprises dans leur gestion des estimations et devis IT à travers une application web et des formations.

Au début de ma carrière, j’étais un développeur parmi tant d’autres, je ne faisais pas de distinction entre front-end et back-end mais je tentais de résoudre des problèmes : des problèmes de CSS, des problèmes de serveurs qui ne démarrent pas, ou encore des problèmes d’API.

Quoi qu’il en soit, mon métier me plaisait : en tant que développeur, les jours passent mais ne se ressemblent pas. Les problématiques rencontrées sont variées et chaque jour est un nouveau défi.

Comment je me voyais dans 5 ans ?

A cette question classique posée lors des entretiens, je répondais alors de manière assez conventionnelle en disant que je souhaitais devenir un Lead ou Senior. À mon sens, il était évident qu’un développeur chevronné devait évoluer vers un poste de mentor.

A l’époque, je n’avais pas forcément envisagé d’autres possibilités pour moi. Cependant, au fil de mes expériences, j’ai compris que les chemins de carrière sont nombreux et qu’il est possible d’explorer différentes voies

Les premiers pas vers le produit

En tant qu’associé et en raison de mon ancienneté dans ma PME, j’ai été invité à participer à des réunions stratégiques où j’étais le seul référent technique. Ma présence avait pour objectif d’informer les parties prenantes sur ce qu’il était possible ou pas de faire.

De fil en aiguille, j’ai été confronté aux débats d’idées, aux parties prenantes qui expliquaient leurs besoins et leurs problèmes. Cette réflexion de plus haut niveau m’a plu : il ne s’agissait pas seulement de développer une nouvelle fonctionnalité ou de résoudre un bug, mais avant tout de concevoir des solutions aux problèmes des utilisateurs. La passion pour le “Product” a commencé à naître naturellement.

Petit PO deviendra grand

À force de veiller sur internet, je suis tombé sur des articles de plus en plus ciblés autour des sujets de l’agilité, notamment sur news.humancoders.com, qui était ma source d’inspiration quotidienne en matière de technologies et de produits.

Au fil du temps, j’ai compris qu’avant de développer une solution, il fallait identifier le problème. En équipe, nous avons donc décidé de mettre en place une philosophie agile dans notre entreprise.

Au début, nous avons suivi le Scrum Guide de manière assez stricte. Les résultats ont été intéressants : notre organisation était plus structurée et les développements avançaient de manière plus cohérente. Tout n’était pas parfait mais nous avons mis en place une démarche d’amélioration continue et itérative.

Nous avons cherché quelqu’un pour organiser et animer l’ensemble des rituels agiles, et avons décidé d’avoir un Product Owner. Ayant été à l’origine du mouvement en interne, je me suis porté volontaire.

Un long fleuve pas toujours tranquille

Mettre en place une culture “produit” dans une petite entreprise n’est pas une tâche aisée. Le premier obstacle rencontré est le manque de confiance en soi. Je me suis beaucoup interrogé sur la manière de faire : Est-ce que j’agis correctement ? Mes collaborateurs trouvent ils un intérêt à cette nouvelle méthode de travail ? Est-ce que cela sert à quelque chose ?

La communication avec les parties prenantes n’a pas été facile. En tant que développeur, j’ai longtemps travaillé en solitaire et je n’avais pas l’habitude de parler à beaucoup de monde. J’ai dû faire un travail personnel pour apprendre à aller vers les autres et à leur poser les bonnes questions.

En outre, suivre le Scrum Guide ne suffit pas toujours : bien que tout y soit défini, il reste des subtilités propres au métier de Product Owner et/ou Manager qui ne sont pas expliquées et qu’il faut découvrir par soi-même. Il est donc nécessaire de s’adapter en permanence à l’entreprise, à l’organisation interne et aux parties prenantes avec lesquelles nous travaillons.

On fait le bilan, calmement

Je suis un Product Owner / Product Manager heureux. Le développement ne me manque pas. Je continue de résoudre des problèmes mais je m’épanouis beaucoup plus en participant en amont à la réflexion autour de la conception ou de l’amélioration d’un produit.

Cependant, le fait d’avoir été développeur me donne un avantage non négligeable : je comprends leur langage. Je comprends leurs craintes, leurs doutes, et je peux ajuster mes user stories en conséquence. Concrètement, je m’assure que les descriptions sont claires et précises, avec des exemples et maquettes précises qui aident à mieux comprendre les besoins et les attentes des utilisateurs. De cette façon, je m’assure que les développeurs disposent de toutes les informations nécessaires pour travailler sereinement.

Mais tout n’est pas parfait : j’ai toujours cette vision technique qui, parfois, m’empêche de prendre de la hauteur sur certains sujets. Par exemple, il m’arrive de contester une estimation alors que, théoriquement, ce n’est pas au PO/PM de chiffrer le ticket.

Quoi qu’il en soit, je ne regrette pas ce choix : en me réorientant, j’ai tenté de bousculer mes certitudes et mes habitudes, ce qui m’a permis de trouver une voie qui me correspond davantage.