De développeur à product owner, mes conseils pour une transition en terrain connu

Chers développeurs, vous trouvez le métier de PO (product owner) plutôt cool ? Vous vous dites : “est-ce que c’est fait pour moi ? Mais comment faire ?” Je vais vous raconter tout ce que je sais à travers mon expérience. Pendant 7 ans, j’ai roulé ma bosse à travers différentes expériences de développeur. Depuis quelque temps, j’avais des envies de changement, j’en ai parlé autour de moi et, un jour, mon supérieur m’a proposé de prendre un poste de PO vacant. J’ai tout de suite accepté et, deux ans plus tard, me voilà devant mon écran en train de vous expliquer mon parcours. Voilà, pour mon histoire. Maintenant, la première question à se poser, c’est : est-ce que je suis fait pour ce métier ?

Suis-je fait pour être PO ?

Avant de se lancer dans une transition, qui n’est pas irréversible, mais qui n’est pas à prendre à la légère, il est important de se demander si nos envies et surtout nos qualités correspondent à ce nouveau challenge.

En effet, le métier de PO, vous le connaissez grâce à vos expériences de développeur, vous avez sûrement dû le côtoyer. Vous en connaissez les missions principales et, avec le temps et l’investissement que vous mettrez dans cette transition, vous réussirez sûrement à maîtriser tout ce que l’on peut qualifier d’opérationnel (les outils de ticketing, les outils de prototypage, l’agilité et ses process, etc.). Ces compétences sont incontournables, mais vous les développerez avec le temps. Ce qui suit n’engage que moi, bien évidemment. Pour être un bon PO, il est nécessaire d’avoir certaines qualités intrinsèques, que voici !

L’empathie est sûrement la première des qualités. En effet, le PO doit être à l’écoute et capable de comprendre les besoins des utilisateurs afin de les restituer et les formaliser au mieux. Les entretiens, le dialogue, prennent une grande place dans notre mission de l’élaboration d’un produit au suivi en passant par le développement.

Ensuite, il est primordial d’être diplomate et pédagogue. En effet, lorsque l’on travaille sur un produit, nous avons à coordonner des parties prenantes ayant des attentes et des contraintes différentes. Vous devrez certainement faire entendre à vos interlocuteurs que tout n’est pas possible pour le bien du produit même s’ils sont persuadés du contraire. Dans ce cas, avec un peu de patience et de persévérance, vous arriverez à leur faire entendre raison.

Par ailleurs, il est nécessaire d’être curieux. Laisser traîner ses oreilles permet d’emmagasiner des informations qui, même si elles ne vous sont pas utiles dans l’immédiat, le seront peut-être plus tard. Aussi, dans l’élaboration d’un produit, savoir ce qui se fait ailleurs est également un atout indéniable. Votre produit existe potentiellement chez des concurrents, peut-être ont-ils imaginé des solutions intéressantes ? Vous y trouverez une source d’inspiration non négligeable. Cette description est, bien entendu, non-exhaustive et personnelle, vous trouverez forcément des avis divergents.

Enfin, que vous pensiez être fait pour ce métier ou non, n’oubliez pas de prendre en compte un atout primordial : vous êtes développeur !

On efface tout, on recommence… ou pas !

Lorsque j’ai entamé cette nouvelle aventure, je suis passé du statut de développeur expérimenté à celui de PO junior, ce qui m’a paru un peu déstabilisant. Mais j’avais sous-estimé mon atout principal : avant, j’étais développeur… Je ne partais donc pas de zéro.

En tant que développeur, vous avez sûrement déjà travaillé sur un produit en collaboration avec un PO. Même si, parfois, vous pouvez vous demander : “mais le PO, il fait quoi en fait ???”, vous connaissez la réponse ! Pendant que vous travaillez sur votre projet, vous l’avez déjà vu :

• organiser des réunions et discuter avec d’autres services de différents sujets
• mettre en place les différents rituels de suivi de développement du produit
• vous exposer son backlog rempli de users stories
• vous présenter des prototypes
• etc

Bref, tout ça vous est finalement familier, vous avez déjà des bases !

En plus, le contact entre le PO et le développeur est permanent. Par exemple, quand un dév’ essayera de vous expliquer qu’il a rencontré un problème technique qui l'empêche de réussir son développement, vous le comprendrez mieux que n’importe quel autre PO et vous saurez expliquer à vos autres interlocuteurs le problème. Lors d’une démo, vous serez capable d’exposer à vos stakeholders une problématique technique et son impact sur l’avancement du travail. Dire qu’il y a un problème, c’est bien, savoir l’expliquer, c’est mieux…

Vous serez peut-être amené à comprendre le fonctionnement d’une API ou d’une base de données. Si vous connaissez ces sujets, il vous sera plus aisé de tester des appels à cette API ou même de faire une requête SQL par exemple. Dans l’idéal, vous ne devriez pas avoir besoin de faire ce genre de choses mais, soyons pragmatiques, si cela est ponctuel et que vous pouvez débloquer une situation, pourquoi s’en priver ? Le processus de développement d’un produit n’est pas toujours un long fleuve tranquille… Bon, finalement, vous êtes plutôt bien armé pour vous lancer, maintenant, on passe à l’action !

Comment réussir ma transition ?

Ça y est, vous y êtes ! “Euh… et, maintenant, je fais quoi ?” Tout d’abord, lorsque vous commencerez, vous aurez peut être la sensation d’être un peu perdu face à certaines situations. Si vous avez la chance de pouvoir le faire, il existe des formations de quelques jours permettant de rappeler les différentes missions et tâches d’un PO (dont une très bonne que j’ai faite chez Xebia, Certified Scrum Product Owner, qui m'a permis d'être certifié, comme son nom l'indique...). Ensuite, une fois le développement d’un produit lancé, je me demandais souvent ce que faisait mon PO pendant cette période, en plus des différents rituels SCRUM. Eh bien, sachez qu’en tant que PO, il y a toujours quelque chose à faire ! La preuve... Quand les développeurs commencent à bosser, le PO, lui, continue à peaufiner son produit, son backlog est en perpétuelle évolution. Il prépare les échéances futures en suivant sa roadmap. Et si, vraiment mais alors vraiment, il a un creux dans son planning, il en profite, entre autres, pour faire de la veille concurrentielle, trouver des solutions pour améliorer des process qui le mériteraient, etc.

Par ailleurs, vous allez certainement être confronté à des problématiques et ne serez pas certain des actions à mettre en place... vous préférerez peut-être trouver des solutions par vous-même, ayant peur de déranger ou pensant que c’est un aveu de faiblesse. Tous ces sentiments sont compréhensibles. Pour autant, si vous avez des collègues plus expérimentés avec lesquels vous êtes à l’aise, n’hésitez pas à les solliciter. Le partage d’expérience peut être bénéfique pour tout le monde.

Enfin, vous avez peut-être déjà pris cette habitude dans votre quotidien de développeur, la veille est un très bon moyen d'accélérer la montée en compétences et d’enrichir ses connaissances. Elle contribue grandement au fait de se sentir définitivement PO et permet de s’habituer à un nouveau champ lexical, celui du produit. En effet, la vision d’un projet pour un développeur se transformera en une vision produit pour un PO.

À vous de jouer !

Voilà, j’ai partagé avec vous mon expérience de transition vers un poste de PO. Vous trouverez sûrement d’autres témoignages ailleurs, plusieurs avis valent mieux qu’un. Le principal reste de vous faire votre propre point de vue. Je ne regrette absolument pas mon choix, je considère que ma transition est un succès et, ainsi, je ne peux que vous conseiller de sauter le pas, la tâche paraît plus dure qu’elle ne l’est en vérité. Alors, amis développeurs, si le cœur vous en dit, lancez-vous !