Le product manager : au centre de l’UX, de la technologie et du business

Lors du Web2day 2019, nous avons assisté à la conférence de Claire Dufetrelle, head of product management chez FABERNOVEL TECHNOLOGIES. Elle décrypte le métier de product manager, qu’elle exerce depuis 5 ans.

Concevoir un produit et le faire évoluer, en puisant dans l’expertise précieuse des professionnels qui l’entourent

Les professions changent et progressent en continu. En ce sens, le product manager est sans doute une version évoluée du chef de projet. On peut néanmoins le distinguer : il ne passe pas son temps à faire des plannings et organiser des réunions, ce n’est plus l’essentiel de son métier. Son objectif : concevoir un produit, le faire évoluer et puiser dans l’expertise précieuse des professionnels qui l’entourent.

On peut ainsi résumer les différentes parties prenantes des équipes produit :

• Business : la viabilité du produit
• Technologie : la faisabilité du produit
• UX design : la désirabilité du produit

Ces 3 piliers sont essentiels à la réussite des produits. Les projets ne tiennent pas debout lorsque l’un de ces éléments est défaillant. Le product manager, lui, est au centre de ces trois problématiques. Une place parfois compliquée à tenir, tant les trois éléments cités ci-dessus peuvent souhaiter aller dans des sens opposés.

C’est quoi, un produit ?

Il est nécessaire de bien définir ce qu’est un produit. Ce mot évoque des objets, qu’on oppose généralement aux services et aux expériences. La voiture est un objet, une coupe chez le coiffeur est un service, un saut en parachute est une expérience – tout comme le Kinder Surprise. On n’achète pas un Kinder Surprise pour le chocolat (il suffit de comparer le prix au kilo à la qualité du chocolat proposé), on achète un Kinder Surprise pour l’expérience : déballer le Kinder Surprise, diviser la sphère en chocolat (sans la casser) puis découvrir la surprise, et être heureux.

Appliqué au numérique, Claire Dufetrelle prend l’exemple de Spotify : “c’est un service de streaming musical : ce sont des expériences (découverte, suggestions, communauté…) mais aussi des produits : un site web, un logiciel desktop, des applications mobiles et même des produits événementiels”. Plus schématiquement, nous pouvons dire qu’un service est incarné par différents produits qui permettent de créer des expériences. Le produit est un intermédiaire qui doit refléter un service.

Les 6 rôles du product manager : récolter l’information, analyser, arbitrer, organiser, mettre en production et faire évoluer le produit

Aux prémisses des produits, le product manager a généralement une idée, plus ou moins précise, de la suite des événements. Il va concevoir un cahier des charges, rédiger des spécifications, les développeurs vont développer le produit, il sera testé puis mis en prod. C’est la théorie. En pratique, de nombreux événements vont venir bousculer le cycle de production : un concurrent va arriver, la direction va changer d’avis, les designers aussi, les utilisateurs ne vont pas aimer le produit… Les imprévus sont par nature imprévisibles, mais ils arriveront, c’est un fait qui doit être accepté par le product manager – qui a plusieurs manières de réagir.

Il peut mettre des œillères et ne pas prendre les événements en considération. À l’inverse, il peut se transformer en girouette et changer l’orientation du produit à chaque micro-événement ou chaque avis des parties prenantes. Dans les deux cas, c’est prendre un risque pour le produit. Le rôle du product manager est justement de trouver le juste milieu, toute la problématique est là. Créer un produit nécessite de nombreuses expertises : commerce, marketing, design, utilisateurs, direction d’entreprise, développeurs… « Tout le monde a un avis et certains produits sont conçus en fonction de celui qui crie le plus fort ou de celui qui a la place haute place dans la hiérarchie. Le product manager doit éviter ces travers, c’est à lui de prendre soin du produit ».

Pour ce faire, il doit :

• Récolter l’information
• Analyser
• Arbitrer
• Organiser
• Mettre en production
• Faire évoluer le produit

Parmi ces tâches, deux sont essentielles. Arbitrer, car on ne peut pas dire oui à tout, on doit décider en prenant en considération tous les éléments, afin de respecter le produit, lui donner une cohérence qui va satisfaire autant que possible l’ensemble des parties prenantes (mais tout le monde ne sera pas satisfait à 100%). Et mettre en production, car concevoir des produits qui ne vivent pas n’a que peu de sens.

De nombreuses méthodes et théories unies par un même état d’esprit

De nombreuses théories sont associées à la conception des produits : on pense bien-sûr aux méthodes agiles, la méthode Scrum en particulier, au design thinking, au lean UX… Les discussions qui opposent les partisans de ces différentes méthodes ne sont pas toujours très pertinentes : globalement, ces méthodes sont toutes unies par un même état d’esprit, un référentiel de valeurs commun.

Scrum est sans doute le framework agile le plus connu. La méthode est issue du papier The New New Product Development Game (Hirotaka Takeuchi, Ikujiro Nonaka) et n’était pas spécifiquement liée à l’industrie du numérique. Elle puise ses principes dans ceux du rugby, d’où son nom (phases à respecter, rôle de chacun, travail itératif…). En 2001, l’Agile Manifesto fut rédigé, ainsi que le Scrum Guide – 10 ans plus tard. « La méthode Scrum est une méthode agile, ce n’est pas une méthode souple » : elle est très rigide et doit être appliquée à la lettre pour le bien du produit. Dans ce framework, le product manager est un product owner. Il travaille avec une équipe de développement, un scrum master et des stakeholders. Son rôle n’est pas de manager l’équipe mais de passer du temps avec les parties prenantes, les utilisateurs et les experts techniques pour récolter de l’information et prendre de bonnes décisions.

Parmi les autres méthodologies, on peut évoquer le design thinking (penser comme un designer). Le design thinking est apparu dans les années 80 avant d’être formalisé avec la création d’IDEO en 1991, l’engagement du CEO de SAP pour promouvoir la méthode et la création des d-schools, les écoles de design thinking (dont d.school Paris). Avec le design thinking, on s’appuie sur les personnes, des profils en T indispensables (de l’expertise dans un domaine associé à de l’ampleur, pour être curieux), des équipes pluridisciplinaire, pas de chef… On réorganise les espaces pour faciliter le travail collaboratif et accélérer la conception de prototypes. Comme avec Scrum, le respect des protocoles est important. De nombreuses variantes existent, mais elles ont toutes en commun de “partir dans tous les sens puis se recentrer”. Exemple avec le Google Design Sprint Process : Understand, Define, Diverge, Decide, Prototype, Validate. Dans une équipe de design thinking, il n’y a pas que des designers : on trouve aussi des compétences techniques, business, métier… Le product manager peut aider l’équipe en facilitant les process.

Des équipes décisionnaires, un point essentiel pour la réussite des produits

Scrum et Design thinking sont deux méthodes parmi tant d’autres : Kanban, Scrum of Scrum, Lean startup, Lean UX, Guerilla UX, Hooked… Si Claire Dufetrelle conseille de lire ces théories pour les connaître, elle insiste sur un point : “elles se ressemblent beaucoup, les idées sont toujours à peu près les mêmes”. En résumé :

• Équipe : profils pluridisciplinaires, tâches partagées, prises d’initiative valorisées et postes flous.
• Méthodes : elles guident les process, avec des successions de phases et des points d’étapes obligatoires
• Retours : ils doivent être fréquents, de la part des utilisateurs, des parties prenantes, des collègues d’autres équipes…
• Décisions : l’équipe est décisionnaire et protégée par le framework, la méthode.

L’équipe est aidée par les parties prenantes mais c’est elle qui prend les décisions. Il n’y a pas de chef, on se base donc sur des process pour prendre et justifier des choix. Les équipes sont à la fois responsabilisés et protégées par ces frameworks. Mais cette migration de la prise de décision, du fameux Codir aux équipes de développement, est sans doute la chose la plus compliquée pour les entreprises “qui se transforment” – et c’est pourtant l’élément le plus essentiel à la réussite des produits.