Jonathan PETIT-CHARLES Dans la vallée du produit agile

Recrutement : PO Data, Front, API, Back, OPS, …

R
Share this :

Il est de plus en plus courant de croiser dans l’IT des annonces de Product Owner “technique”, POFront”, POFlux” et j’en passe… définissant tous tant bien que mal ce que doivent être les missions d’un PO. Ayant tantôt des tâches relevant du bon sens et d’autres fois des tâches tellement spécifiques qu’on en viendrait à se demander si l’on parle toujours d’un Product Owner ou d’un expert technique.

Je pense qu’il est important de préciser que sous cette angle, on pourrait créer autant de types, de noms ou de profils de Product Owner qu’il existe de technologies, d’environnements ou d’individus. Pourtant, le travail demandé à ces différents PO devrait être le même, les attentes devraient être les mêmes et les redevabilités devraient être les mêmes.
Tout comme la définition du poste de PO est variable en fonction de l’entreprise et de son contexte, le “profil” du PO demandé est lui tout aussi variable et ce même pour un même POtype”.

Lorsque l’on s’attarde sur le framework Scrum, qui d’ailleurs est le seule à fournir un réel cadre au métier de Product Owner, la redevabilité première de ce dernier est de “maximiser la valeur du produit résultant du travail de la Scrum Team”.
Concrètement, cela se traduit par le fait que l’on attend du PO qu’il travaille de concert avec les parties prenantes et sa Scrum Team afin de co-construire un produit autour d’une vision unique.

Tout cela me pousse à me poser des questions, à savoir pourquoi définit-on aujourd’hui autant de types de PO ? Pourquoi ces annonces de POtype” prennent-elles autant d’ampleurs ?


Un POtype”, au risque d’en froisser beaucoup d’entre vous, je vous le dis d’emblée, est un non sens.
Le travail du PO est avant tout de maximiser en tout temps la valeur de son produit en travaillant avec son équipe l’impact qu’aura celui-ci auprès de ses utilisateurs et cela quelques soit la technologie ou l’environnement employé.
Qu’il soit POBack”, ou POFront”, on attend exactement les mêmes chose de celui-ci.

Une première piste de réponse pourrait se trouver du coté des RH, qui pour des besoins de rapidité, seraient amenés à inclure la techno ou l’environnement principal dans le nom de la fiche de poste.
Quoi de plus lisible qu’une annonce pour un poste de PO “Office 360” ou encore PO “Data Wherehouse” pour filtrer de facto les candidats intéressés mais qui n’auraient pas les compétences recherchées, leur permettant d’offrir une meilleure lecture de l’offre qu’ils proposent. Mais malheureusement, tout cela contribue grandement à cette standardisation du POtype”.

Une autre piste pourrait être une conséquence de toute cette hype que l’on retrouve aujourd’hui autour du poste de Product Owner. Se présenter comme spécialisé sur telle ou telle techno, environnement, ou domaine offre un avantage non négligeable en fonction du produit pour lequel on postule.
Certes, beaucoup de PO ont des “appétences” pour certains types de techno ou d’environnement, mais a t-on réellement besoin de cette complexification ? Les compétences recherchées pour recruter un PO doivent d’abord se concentrer sur les softs skills de celui-ci et surtout sur sa motivation à faire avancer et créer de l’impact.


Je dois avouer que je ne suis pas contre cette pratique, mais cela ne veut pas dire pour autant que je suis pour. Avant de définir un poste de POtype”, il faudrait davantage travailler le périmètre sur lequel celui-ci devra intervenir et par dessus tout, créer une vrai équipe pluridisciplinaire qui permettra de co-construire le produit confié de bout en bout.

Un travail en profondeur de la fiche de poste, avec une mise en avant du produit, de sa vision, ainsi que l’environnement et ses technologies pourraient largement suffire.
On pourrait même aller encore plus loin en y ajoutant les ambitions stratégiques ainsi que les résultats clés attendus (petit clin d’oeil aux OKR).

En effet, beaucoup de candidats ne liront pas certaines fiches de poste de POtype” estimant ne pas répondre aux critères demandés de façon explicite dans le titre alors même qu’ils pourraient apporter énormément de valeur au produit.
Un “bonPO n’aura certes pas l’appétence recherché pour un type de techno spécifiquement, mais il s’aura travailler avec son équipe et s’appuyer sur leurs compétences afin de faire émerger l’impact recherché.

Et vous, qu’en pensez vous de tous ces PO “type” ?


Agilement vôtre,

Transparence, Inspection, Adaptation,

Jonathan

Share this :

About the author

Jonathan PETIT-CHARLES
Jonathan PETIT-CHARLES

Consultant Produit (Coach Produit / Product Manager / Product Owner / Formateur Agile & Produit)
@ Benext Company / Octo Technology / Accenture

Jonathan PETIT-CHARLES Dans la vallée du produit agile

Jonathan PETIT-CHARLES

Jonathan PETIT-CHARLES

Consultant Produit (Coach Produit / Product Manager / Product Owner / Formateur Agile & Produit)
@ Benext Company / Octo Technology / Accenture