Pendant la conception de produits, la collaboration entre le Product Designer et le Product Manager n’est pas toujours évidente. La répartition de certaines tâches est floue, ce qui peut rendre difficile la collaboration du duo, et la coopération avec l’équipe technique.
En travaillant sur la Banque en Ligne de Bpifrance, nous avons fait deux erreurs majeures :
- La Product Designer et moi (PM) n’avons pas réparti les rôles,
- Nous n'avons pas suffisamment impliqué l’équipe technique, que ce soit dans la recherche utilisateurs, le challenge des maquettes, ou la prise de décisions.
Ces erreurs ont causé plusieurs problèmes : difficulté à nous accorder sur des écrans, nombreux allers-retours avec les décisionnaires, perte de 3 semaines de développement à un moment crucial pour le projet, et sur un plan plus personnel, un manque de progression sur des sujets qui nous intéressaient.
Répartition des rôles entre le PM et le Product Designer
1. Quiproquo sur les missions
Lorsque j’ai commencé en tant que Product Manager, j’étais vraiment excitée à l’idée de travailler en binôme avec un Product Designer, mais je redoutais déjà le chevauchement de nos missions. Par exemple, j’avais hâte de parler à des utilisateurs, seulement, j’étais persuadée que cette responsabilité appartenait quasi intégralement à celui que l’on appelle « l’avocat des utilisateurs », le Designer.
Parmi les missions de ces deux membres de l’équipe Produit, certaines sont claires et acceptées.
- La gestion du backlog, la priorisation des fonctionnalités et l’analyse de leur impact commercial sont les responsabilités du PM.
- La conception de l'interface (UI), la création des maquettes, et l’optimisation de l’expérience utilisateur sont à la main du Designer.
Pourtant, une confusion demeure sur d’autres missions :
- Les tests utilisateurs et l’analyse des retours récoltés,
- L’organisation d’ateliers de conception de fonctionnalités;
- La collaboration avec les développeurs.
Les deux métiers requièrent des compétences communes (communication agile, empathie, curiosité, analyse de données) qui leur donnent la même légitimité à travailler sur ces éléments.
2. Division des périmètres
Sur le projet Bpifrance, une mauvaise répartition s’est faite sentir. Nous travaillons sur une fonctionnalité permettant aux clients d’échanger des documents avec leurs chargés d’affaires (responsables du montage des dossiers financiers) à la façon d’un Google Drive, de manière simple, rapide et sécurisée.
Situation :
La Designer et moi avons commencé par faire cavaliers seuls. Pendant la phase de discovery, elle interrogeait les clients pendant que je récoltais les retours des chargés d'affaires. Par manque de légitimité face à la Designer, je n’osais pas organiser de tests utilisateurs.
Résultat :
Cette répartition maladroite dirigeait naturellement nos visions vers des sens opposés, puisque nous ne prenions en compte respectivement qu’une partie des enjeux : pour les clients, le gain de temps et pour les collaborateurs, la réception de documents conformes.
Nous avons alors eu du mal à nous accorder sur des maquettes, et nous étions restreintes dans notre apprentissage.
Apprentissage :
Concernant la recherche utilisateurs, l’option d’une distribution stricte des rôles n’était pas optimale pour construire le meilleur produit.
3. Travailler ensemble
Finalement, concernant la délimitation des rôles, nous nous sommes mises d’accord sur le fait de ne pas nous mettre d’accord.
C’est-à-dire ?
Nous qui découvrions le monde de la finance et qui devions nous familiariser avec les problèmes et le jargon des clients de Bpifrance (les entrepreneurs), la logique était de réaliser cette recherche à deux.
Là où j’imaginais que la Designer gérait l’organisation de ces échanges avec beaucoup de facilité, la charge de travail qu’ils nécessitent générait une source de stress intense pour elle.
L’implication du PM permet entre autre de libérer de la charge mentale au Designer. Finalement, seule l’introduction des tests nécessite un responsable pré-défini.
La préparation de la trame, les échanges avec l’invité, l’analyse de l’interview et le partage des apprentissages aux parties prenantes doivent se faire à deux pour garantir un socle commun de connaissances et une prise de décision efficace.
Malgré les similarités, les deux alliés ont chacun des expertises différentes que l’autre respecte - ils sont complémentaires. Le Designer a le pouvoir de transformer des idées en réalité. Il peut transmettre ses bonnes pratiques pour limiter les biais afin de réceptionner une information objective et se débarrasser de la phobie des blancs lors des interviews.
Le PM, par ses échanges réguliers avec l’équipe technique et ses nombreux interlocuteurs (support client, Marketing, Business,...) apporte du contexte sur les contraintes existantes ainsi que sa vision stratégique, et rappelle les objectifs business, nécessaires à la conception de la solution.
Implication de l’équipe tech
1. Appels aux détracteurs
Au-delà de celle du tandem, la contribution des développeurs est précieuse lors des échanges avec les utilisateurs du produit.
Par exemple, nous appelons régulièrement des clients de Bpifrance ayant manifesté leur insatisfaction dans le NPS. Prendre volontairement son téléphone pour se faire passer un savon par des utilisateurs mécontents, ça peut sembler masochiste, mais il s’agit en réalité des 30 minutes les mieux investies de la semaine en termes de ratio temps / effort / bénéfices. Cet échange spontané qui ne nécessite aucune préparation permet de récolter des retours pertinents et d'identifier des bugs critiques.
Pour les utilisateurs, dont l'insatisfaction est souvent liée au manque de contact humain, le soulagement est d'autant plus grand à l'idée que leurs problèmes soient compris à la source, sans intermédiaire. L’équipe tech, qui connait son produit à la ligne de code près, est parfaitement placée pour guider les clients en direct, leur apporter des explications concrètes à leurs problèmes.
2. Challenge des maquettes
L’un des plus gros challenges du Product Manager consiste à aligner les décisionnaires sur les écrans à développer. Dans les ateliers de restitution de Discovery organisés à cet effet, le Tech Lead a toute sa place. S’il détermine que ce n’est pas faisable techniquement, toutes les étapes précédentes n’ont servi à rien. Plus (et plus tôt) l’équipe technique aura de visibilité sur les besoins des utilisateurs, plus elle sera déterminée à proposer des solutions de contournement aux obstacles.
Dans le cadre de notre Discovery continue, les designers organisent des interviews hebdomadaires avec les utilisateurs, auxquelles les développeurs sont systématiquement conviés (dans la limite de trois personnes par interview pour éviter de déstabiliser l’invité). Une occasion pour l’équipe tech de développer son empathie envers nos utilisateurs.
Si l’on attend d’avoir la solution pour passer le relai à la tech, on ne se sert pas non plus de leur capacité à comprendre les problèmes et on se trompe.
3. Dépassement des frontières
Finalement, notre équipe a remis en question les limites du périmètre de chacun. Les développeurs proposent des améliorations produit, enrichissent la liste parfois incomplète des critères d’acceptation et contribuent à la recherche utilisateur. Désormais, les développeurs sont impliqués dans le challenge technique des maquettes et partagent leurs questionnements concernant l’aspect fonctionnel de celles-ci.
Cela permet de limiter les retours de validation.
Ce raisonnement permet également d’atténuer les SPOF au sein de l'équipe.
|
💡 Un SPOF, point de défaillance unique, est l’élément du système qui, s'il venait à échouer, entraînerait l'échec global du projet. |
En fait, si une personne détient des connaissances ou des responsabilités essentielles pour la mission et qu'elle devient soudainement indisponible, cela peut entraîner des retards ou des échecs.
Il est donc préférable de partager les connaissances et de favoriser une communication ouverte au sein de l'équipe pour éviter une dépendance excessive à une seule personne.
Bien sûr, je ne vais pas me mettre à coder ou à créer des prototypes sur Figma (notre produit prendrait une tournure catastrophique). Il est nécessaire d’identifier un décisionnaire pour garantir des avancées efficaces, tout en encourageant chaque membre de l’équipe à partager ses connaissances avec générosité.
Apprentissages
Nous avons tiré plusieurs enseignements de notre expérience sur la banque en ligne de Bpifrance :
- Il n’y a pas de répartition universelle idéale des responsabilités entre le Product Manager et le Product Designer ; chaque équipe développe ses propres méthodes en fonction des appétences de chacun. Une bonne collaboration PM - Product Designer nécessite beaucoup de transparence dès le départ pour clarifier les périmètres.
- Alors que le duo est naturellement amené à collaborer étroitement, nous avons tendance à oublier d’impliquer le Tech Lead dans nos interactions. Pourtant cette collaboration est cruciale pour prendre des décisions éclairées. Je peux vous donner quelques exemples d’actions que nous avons mises en place :
- Participation du Tech Lead aux ateliers de conception avec les parties prenantes,
- Invitation des développeurs dans les échanges avec le client, notamment aux appels spontanés avec les détracteurs et aux interviews utilisateurs,
- Transmission de la gestion d’une EPIC, initialement à la main du Tech Lead, à chaque développeur.
Pour compenser le stress que nos métiers peuvent parfois générer, il faut savoir se faire plaisir. Adopter une approche holistique et flexible, où chacun peut contribuer s’il le souhaite à des missions qui sortent de sa fiche de poste y contribue grandement et décuple les chances de construire un produit pertinent avec des personnes motivées.
En laissant de côté nos égos et en reconnaissant la valeur de chaque membre de l’équipe, nous avons pu constater une amélioration significative dans notre façon de travailler ensemble.
