fbpx

Product Owner/Product Manager, faut-il les différencier ?

Partager sur

Partager sur facebook
Partager sur twitter
Partager sur linkedin

Les Clubs Métiers du Hub réunissent des experts métiers des startups investies par les fonds d’investissement en capital risque de Bpifrance. Pour inaugurer le lancement du Club Produit, nous vous proposons une série d’articles consacrée au métier de Product Manager. 

bpifrance LeHub Clubs_logo research_V1_AUG2020

Nous commençons une série de de quatre articles qui visent à éclairer les startups seed du portefeuille ou les jeunes équipe produits (1-3 product) à se faire une opinion sur le parcours carrière du PM. Dans ce premier article, nous nous intéressons aux bases, avec la question de la distinction entre Product Owner (PO) et Product Manager (PM). Une seconde partie évoquera le plan de carrière du PM ; un troisième abordera les perspectives d’évolution de carrière du PM; enfin, nous proposerons une ouverture sur les autres métiers de l’équipe produit.

 

Une distinction en théorie

La galaxie produit est en constante évolution et a donné naissance à pléthore d’intitulés de poste : Product owner, Product manager, UX/UI designer, User researcher, Product marketing manager, Product Owner… Essayons d’y voir clair plus particulièrement sur le duo PO/PM qui peut prêter à confusion. Pourquoi cette distinction existe-t-elle ? Est-elle réellement pertinente en théorie ? Et dans la pratique?     Commençons par les différences observées sur le marché et dans la littérature entre un Product Owner (PO) et un Product Manager (PM) :

  • Le PO est celui qui, en étroite collaboration avec les équipes de développeurs mais aussi celles du marketing et du design, va animer le Delivery. Il assure le suivi des tâches effectuées lors des sprints (phases de développement – entre 2 à 5 semaines) en adoptant le plus souvent une méthode agile (Scrum, Kanban ou SAFe).
  • Le PM est davantage porté sur les aspects stratégiques du produit et sur le Discovery des fonctionnalités. Par discovery on entend la phase de recherche d’une certaine centricité utilisateur. Une des façons de percevoir la mission du PM est de “minimiser le risque produit en se concentrant sur l’apprentissage” (Melissa Perri, Escaping The Build Trap). Concrètement, le PM est censé passer une bonne partie de son temps à comprendre l’utilisateur et à cultiver une vision long terme du produit… en assumant souvent en outre le rôle de PO ! 

 

Des modalités variées dans la pratique

En réalité, ces distinctions de rôles ne sont pas vraiment nettes, ce qui ne facilite pas la tâche du responsable talent ni du directeur produit. La plupart des PM font du delivery et de nombreux PO peuvent toucher à la recherche utilisateur. Pour Melissa Perri, auteure et experte des sujets produit, la transversalité des tâches au quotidien rend cette distinction obsolète : le PO est plutôt un rôle porté dans une organisation type Scrum, tandis que le PM désigne plutôt un job

 

Pourquoi n’existe-t-il pas de distinction plus nette ? On peut trouver de bonnes explications dans le fait que le Delivery a été beaucoup plus structuré par des méthodologies (Scrum, Kanban, etc.) par rapport au Discovery. Par ailleurs, nombre de startups n’ont pas atteint la taille critique pour permettre aux PO/PM de se spécialiser dans un rôle ou dans l’autre. 

VOUS SOUHAITEZ ENTRER EN CONTACT AVEC DES STARTUPS INNOVANTES ?

Le danger de l’usine à features

Les rôles se confondent donc souvent, et l’équipe produit peut alors être considérée comme un véritable couteau suisse qui va gérer les bugs et le support. On parle alors d’”usine à features” si l’équipe perd la vision produit en multipliant les fonctionnalités… au risque de nuire à la cohérence de l’expérience utilisateur ! 

 

De plus, l’équipe produit de moins de cinq PO/PM va souvent se cantonner à l’exercice du delivery. Ca n’est qu’ensuite, avec le développement de l’équipe produit (souvent accompagné de l’intégration de nouveaux talents spécialisés ou experts), que l’on voit apparaître des logiques de renforcement du discovery.

 

Cette distinction floue, a poussé un certain nombre de startups comme MeilleursAgents et Captain Contrat à abolir le distinguo PO/PM et à les réunir sous une casquette unique de Product Manager, déclinée en “junior” et “senior”. Une décision à l’image de ce qui se dessine outre-Atlantique. Un autre positionnement plus tranché (mais critiqué !) consiste en la suppression pure et simple du poste de PO, afin de responsabiliser l’ensemble de l’équipe sur ses tâches. Dans cette configuration, le  risque de dysfonctionnements opérationnels se trouve néanmoins accru. .

 

La solution, un Super PM polyvalent ?

La fusion des rôles au sein d’un “super PM” s’appuie sur plusieurs fondements :

  • Elle colle plus à la réalité du terrain. La plupart des équipes produit étant relativement restreintes, le rôle du PM est souvent polyvalent dans les premières phases de structuration. 
  • Elle nourrit et facilite le travail du PM. Être proche des développeurs et comprendre comment les features marchent permet d’avoir une compréhension plus fine de son produit et, in fine, de mieux prioriser les tâches. 
  • Elle rend le recrutement plus facile. Les rôles de PO et de PM n’étant pas suffisamment ciselés et les réalités recouvertes par leur intitulé de poste étant souvent hétérogènes au sein de l’écosystème, il est plus difficile de comprendre la pertinence d’un profil externe.
  • Elle permet d’offrir un plan de carrière plus intéressant avec un continuum de compétences de PO et de tâches de PM sur 3-5 ans.
  • L’origine de l’utilisation du terme owner est assez artificielle, elle vient d’un changement de terminologie de product manager à product owner entre deux éditions du livre Scrum Guide, les auteurs ayant considéré que PM renvoyait trop à l’image d’un Manager.

 

On approfondit très bientôt le sujet en abordant le plan de carrière PM, avec des enseignements  de MeilleursAgents et Captain Contrat !

One Response

  1. Dans les faits et surtout en France, le PO a pris l’ancien job de Chef de Projet MOE essentiellement parceque la transition agile ne s’est pas accompagnée d’une remise en question des modèles mentaux dans les organisations déjà un peu anciennes. Ça s’est étendu comme la bonne pratique et le PO est devenu un delivery manager. En parallèle les anciens Chef de Produit sont devenus des PM. On reste dans un découpage « gens très intelligents qui pensent » / « gens très appliqués qui exécutent ».
    Grossière erreur à mon avis, on rebrandé d’anciennes organisations avec des mots et rituels agiles sans réellement évoluer.
    Depuis plusieurs années, les leaders du web ne font plus la distinction. Ils ont un seul rôle, celui d’une personne qui est OWNER de son produit, qui le pense et le délivre avec son équipe. Ils pensent le rôle comme celui de patron d’une startup, et ils l’appellent Product Manager.
    Pour ma part je crois totalement dans le second modèle (et le met en pratique dans mon équipe) parcequ’il mise sur l’empowerment. Le management donne des objectifs et le PO/PM invente les solutions avec son équipe et rend des comptes sur les outcomes. Le bon côté c’est que ça donne un fort niveau de contrôle local, on choisit la bonne idée et on la délivre comme une proposition de valeur. La contrepartie c’est qu’il faut des personnes capables de porter une vision et une stratégie tout en étant très hands on.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.