Bonjour la commu !
Je suis actuellement étudiante chez OpenClassrooms à la formation Product Manager qui délivre un titre RNCP un peu plus général « Manager en stratégie et développement de projet digital ». J’aimerais devenir Product Owner mais n’ayant pas d’expériences dans le monde de l’informatique, je voulais avoir vos avis et vos expériences si jamais vous aussi vous avez suivi ce parcours 
Je suis issue de la communication et dernièrement de l’insertion professionnelle.
Hello et bienvenue !
Ma copine fait actuellement la formation. A la différence qu’elle a déjà une expérience en informatique (Data analyste / scientist en risque bancaire), donc ce n’est pas le même parcours et donc pas les mêmes conseils que je pourrai te donner.
Mon point de vue, et cela n’engage que moi : il y a vraiment 2 domaines à connaitre qui font un énorme plus sur le CV.
- Le marketing : savoir faire des études de marché, étudier le besoin, questionner des utilisateurs, créer et valider des hypothèses…
- Le développement informatique : savoir coder est un énorme plus, pour une simple raison, l’empathie des devs vers toi. Sérieusement quand je dis à un dev « tkt moi aussi je sais coder et je comprends en partie tes problèmes » avec une assurance suffisante, ça permet de rassurer et créer vite un lien de confiance. Et aussi pour le CV, ça rassure les « bons » recruteurs et les équipes avec qui tu travailleras.
Sur la formation PM le marketing et la comm’ vous le verrez. Le développement, moins. Essayez au moins d’apprendre un langage, pour le fun, sur le marché du travail ça aide. SQL aussi.
1 « J'aime »
Tout ce qui est en rapport avec le produit est intéressant pour être PO : Marketing, communication, facilitation.
A mon avis, savoir coder n’est pas du tout nécessaire, c’est même souvent un problème. Par exemple un PO qui se mêle des décisions techniques de l’équipe, ou qui veut les « challenger » pour aller plus vite ou pour faire autrement. C’est aussi la porte ouverte à des User Stories trop techniques, au détriment de la valeur pour les utilisateurs.
Bref, le code, ce n’est pas le rôle du PO et pour éviter des confusions, des guerres d’égo et autres problèmes inutiles, il vaut mieux que le PO ne soit pas en ex développeur. Par contre, il doit être capable de comprendre les difficultés des développeurs et parler avec eux.
3 « J'aime »
Bonjour Madame Sylvie,
Les PO qui agissent comme ceci
Citation
Par exemple un PO qui se mêle des décisions techniques de l’équipe, ou qui veut les « challenger » pour aller plus vite ou pour faire autrement. C’est aussi la porte ouverte à des User Stories trop techniques, au détriment de la valeur pour les utilisateurs.
Bref, le code, ce n’est pas le rôle du PO et pour éviter des confusions, des guerres d’égo et autres problèmes inutiles, il vaut mieux que le PO ne soit pas en ex développeur
Tout simplement de un mauvais PO. Je crois qu’une certaine base en programmation peut-être utile. Mais à condition, que le PO ne veulent pas faire le travail du Dev ! Le Scrum Master doit intervenir pour corriger cette mauvaise situation.
Oui, le marketing peut aider a promouvoir son produit. Mais, je crois qu’il faut aussi connaitre le domaine d’affaire du produit. Et parfois, avoir codé des fonctions dans ce produit ou des produits du même domaine d’affaires aident à mieux comprendre le « comment ».
D’une certaine manière, un bon PO doit être bilingue. Etre capable de parler un langage que ces utilisateurs vont comprendre pour aller chercher les besoins. De l’autre coté, un langage peut-être plus techniques (pas du code bien sur) pour faire comprendre ce que les développeur devront livrer comme incrément.
Chaque projet, va demander un assemblage de connaissance et de compétence pour bien jouer le rôle de PO. Sans pour autant, en élimant dans l’absolue.
Plusieurs « Soft Skill » aideront le PO a bien effectuer son travail.
Je suis raccord avec Sylvie. Pour autant, je ne jetterais pas le conseil de Benjamin. Apprendre la technique peut servir l’empathie, mais il faut bien avoir en tête qu’on le fait pour comprendre les développeurs, et non pour concevoir le produit. Cela permet aussi de rendre le produit moins « magique », de mieux cerner ses points forts ou ses limites, et donc de savoir si on peut ou non adresser tel ou tel segment de marché.
Le « métier » est aussi un miroir aux alouettes du même acabit. J’ai connu des PO plus intéressés par la résolution de problèmes ontologiques que de savoir si ça allait se vendre. D’un autre côté, il faut quand même comprendre le métier pour discuter avec les utilisateurs, et pouvoir traduire leur jargon au reste de l’équipe.
3 « J'aime »
Je parle de mon expérience, et donc de mes biais.
J’ai vu 3 choses importantes en « hard skills » pour un véritable PO, au sens Scrum (CEO de son produit), et uniquement de mon expérience :
- Il comprenait la technique, et donc avait quand même appris à coder. Ca ne veut pas dire que c’était forcément un dev. Mais il est encore plus empathique envers les devs.
- Il connait bien l’UX et le marketing. Il sait comprendre un besoin utilisateur, faire des parcours clairs et simples.
- Il sait manipuler la data utilisateur de manière scientifique, ou proche, et les bases de données, pour prendre des décisions liées à des hypothèses.
Donc savoir coder ou ne pas savoir coder peut être tout autant un problème. Ca dépend… J’ai vu les deux autant.