C’est au cours de notre dernière mission en tant que Product Owner que nous avons eu ce débat : faut-il être « technique » pour être un bon PO ?
Bien sûr, les profils ingénieurs défendaient le oui…et les profils marketeux s’insurgeaient en disant que non, non, non, pas du tout 😉 .
Mais qu’en est-il vraiment ? Nous avons voulu creuser la question !

PO, Kesako ?

Pour la petite histoire, le poste de PO, ou Product Owner, est né avec l’arrivée des méthodes « Agiles » et plus précisément de « Scrum », qui est à l’origine d’un nouveau concept « d’équipe » s’articulant autour d’un PO, d’un Scrum Master et de Développeurs.

Les membres d’une équipe Scrum interviennent chacun suivant un scope et un périmètre précis, néanmoins les objectifs restent communs à tous – ces principes permettent à l’équipe de s’autogérer et de travailler collectivement à tendre vers une amélioration continue.

Si on en revient au PO et à la définition de son rôle, voici dans les grandes lignes ce que l’on attend de lui :

• Sa responsabilité principale : définir un produit qui apportera le maximum de valeur métier aux utilisateurs dans le temps et le budget impartis au projet
• Les compétences nécessaires : bonne connaissance du domaine métier, Leadership et capacité à prendre des décisions, esprit ouvert au changement, bon négociateur.

Le PO est le garant du Produit tout au long de sa vie – de sa conception, à son lancement et son évolution, il se doit de guider et de challenger l’équipe afin de trouver les meilleures solutions permettant de le développer et de le mettre en place.

Il assure également la cohésion du produit dans son ensemble – si on prend l’exemple d’un site web, l’intégration d’une nouvelle fonctionnalité nécessite de prendre en considération toutes les contraintes et modalités existantes – c’est au PO que revient la charge d’intégrer tous ces éléments au moment de son étude et de son analyse.

Alors, faut-il être technique pour faire tout ça ?

Prenons le temps d’analyser une fiche de poste type, afin de mieux cerner les attendus relatifs au métier de PO :
Au sein d’une des équipes « Produits », regroupant des intervenants métier, des développeurs et testeur, vous pilotez la réalisation de nouveaux produits et nouvelles fonctionnalités à forte valeur business.

• Analyser et spécifier les besoins émis par les métiers, et garantir une cohérence fonctionnelle entre les produits dont vous avez la charge
• Maintenir la roadmap globale des produits de votre équipe
• Piloter la mise en œuvre des évolutions (animation de l’équipe, suivi du reste à faire, reporting, etc.)
• Maintenir et partager la « vision produit » (fonctionnalités en place et à venir, parcours client, etc.)
• Maintenir les backlogs des produits de votre équipe
• Rédiger des user stories et critères d’acceptance en collaboration avec les métiers, les testeurs et les développeurs
• Piloter la correction des anomalies de recette et de production

Via ce descriptif de poste, on remarque que les termes Analyser / Maintenir / Piloter sont très souvent mentionnés, l’enjeu semble donc être mis sur la capacité de réflexion, de priorisation et de gestion plus que sur les compétences techniques (qui d’ailleurs ne sont pas mentionnées 😉 ) Mais on y fait aussi mention de « collaboration », que ce soit avec les « métiers », comme avec les développeurs et les testeurs.

Dans l’idéal, il faudrait donc savoir faire le grand écart et parler toutes les langues : Marketing, UX, PHP, Java, Finance…

De là, on peut se demander si les compétences « techniques » sont indispensables pour communiquer avec l’équipe.

Il y a forcément un avantage pour le PO à bénéficier de compétences techniques – en effet cela lui permet de :

• fluidifier les échanges (on parle tous le même langage).
• lui donner plus de légitimité afin de challenger l’équipe sur les estimations proposées ou le code mis en place.

De même, lors des phases de test, ses compétences peuvent l’aider à participer à la résolution des bugs : il sera plus apte à les spécifier en identifiant leurs origines / causes, voire même être force de proposition pour trouver des corrections.
Sans connaissance Java, PHP ou autres, il semble effectivement compliqué pour un PO de mettre son grain de sel dans le code ou de prendre le « lead » sur des problématiques techniques.

OK, être technique, c’est un avantage…mais pas une condition !

C’est un véritable « plus » pour le PO de disposer de compétences Techniques, celles-ci lui faciliteront son quotidien.

Mais ces seules notions ne peuvent suffire à un PO pour être considéré comme « Bon ». En effet les attendus sur ce poste sont bien plus larges–, une vision claire et partagée, la cohésion d’équipe, la compréhension et la priorisation des besoins utilisateurs – tout cela reposent également sur les capacités d’organisation du PO, de sa compréhension métier, de sa finesse d’analyse et de son relationnel.

Alors oui, être technique est un plus, mais on peut aussi avoir tout le reste et faire confiance à l’équipe pour la partie technique.

Mots clés : Méthodes Agiles / Scrum / Product Owner / Scrum Master