Opinions en ébullition: Le challenge de créer un produit quand tout le monde a son mot à dire

Introduction

Dans l'univers complexe de la gestion de produit, chaque personne impliquée veut ajouter son ingrédient à la recette : un mojito fraise-moutarde servi dans une passoire, ça vous tente ? Non ? Ah bon.

Comment faire alors pour créer un produit cohérent qui répond aux besoins des utilisateurs lorsque tout le monde veut ajouter son grain de sel (alors qu’on ne lui a pas forcément demandé) et que les utilisateurs ne savent pas eux-mêmes ce qu’ils veulent ?

Cet article a pour but de vous donner les grandes lignes de comment nous approchons le sujet chez Gojob à chaque étape clé de la conception d’un produit (de la recherche à la définition du problème, l'idéation, la conception, le prototypage, les tests, l’alignement stratégique, jusqu’au lancement & monitoring).

1. La recherche & définition du problème

Lorsqu’on se lance dans la conception d’un produit, on est (normalement) passé par une étape d’analyse de données et de recherche utilisateur afin d’identifier le problème principal que l’on souhaite résoudre. On sait tous qu’un élément de data n’est pas une opinion, c’est un fait. Pourtant, tout comme avec l’avis du voisin, on peut finir par construire une chaise à 2,53 pieds si on en fait n’importe quoi.

1. Car il est facile de se perdre dans les fins fonds de l’océan de données que nous avons à disposition et de naviguer dans la mauvaise direction 🚢 ;
2. Car on peut faire dire à la data ce que l’on souhaite si on ne regarde que ce qu’on veut voir…

Il est donc crucial de prendre de la hauteur et de savoir interpréter de manière appropriée la data que l’on a à disposition, car sinon on peut vite se noyer dans du bruit inutile.

Pour vous donner un exemple : chez Gojob, nous avons pour objectif de faire en sorte que nos intérimaires aient la meilleure expérience utilisateur possible. Cet objectif nous a conduit à effectuer une analyse approfondie des tickets de support pour comprendre ce qui crée le plus de frustration pour nos utilisateurs. Ce processus méticuleux de catégorisation, orienté par une compréhension profonde de la structure des données, a été essentiel pour éliminer tout biais potentiel. Si nous n’avions pas fait attention à la data disponible, et que nous n’avions pas remarqué le pic de tickets associé à bug en février 2023 et que nous l’avions inclut dans notre total de tickets, nous serions aujourd’hui en train de nous focaliser sur les mauvais problèmes et en train de construire des solutions dont personne n’a vraiment besoin.

En parallèle, lorsqu’on a interrogé nos utilisateurs sur leurs plus gros problèmes, on a eu un nombre de réponses variées incalculable. Il est important de savoir prendre de la hauteur et de faire la part des choses, bien sûr que c’est frustrant de devoir faire 2 clics sur un bouton pour une action au lieu d’un seul, mais est-ce la priorité face à des problèmes de paie ? (C’est une question rhétorique, n’attendez pas la réponse 😉).

2. L’idéation

Une fois le problème majeur identifié, on passe à la partie idéation. Selon moi, c’est l’aspect le plus fun du job de Product Manager. N’aime-t-on pas tous identifier le pire problème puis trouver LA solution qui rendra notre produit meilleur que les autres et qui fera que nos utilisateurs ne pourront plus s’en passer ? YES !! Sauf que souvent, les gens tombent amoureux/ses de la (leur) solution plutôt que du problème... Combien de fois ai-je entendu "il faut faire ceci ou cela" pour résoudre X ? Au moins 47 fois (j’ai compté). Comment faire alors lorsque tout le monde pense avoir la bonne solution et vient voir les PM pour la leur soumettre ?

Exemple :

• Problème de base : les intérimaires ont besoin de documents précis chaque mois et nous contactent pour qu’on les leur envoie. Générer ces documents est extrêmement chronophage pour les équipes (10min / intérimaire).
• Solution demandée : "Peut-on créer un flow automatisé qui permet en 2-clics de générer un document à envoyer aux intérimaires ?".

Le flow automatisé réduirait le temps passé à générer le document de 10 min à 30 secondes max, c’est top comme solution, non ?! Sauf que le problème n’est pas là… Le vrai problème c’est que nous générons déjà ces documents en masse et que parfois ça ne marche pas. Devoir passer par une génération automatique en plus des outils existants soulage les personnes en charge de refaire la génération manuellement mais ne résout pas le problème à sa source, qui est "la génération de document n’est pas fiable". Implémenter une telle solution serait donc partiellement acceptable, le staff Gojob perdrait moins de temps à traiter les demandes c’est sûr, mais les intérimaires continueraient à être mécontents car ils devraient toujours nous faire des demandes écrites pour recevoir ce document alors qu’il est censé être disponible dans leur application.

C’est pour ça qu’en tant que PM, notre boulot est de faire machine arrière et de comprendre "pourquoi". On utilise beaucoup la méthode des 5 pourquoi qui est une méthode d'analyse de problème qui consiste à poser la question "Pourquoi?" de manière itérative jusqu'à atteindre la cause fondamentale d'un problème. Cela permet de comprendre en profondeur les causes sous-jacentes d'une situation et d'élaborer des solutions plus efficaces en traitant la racine du problème. La méthode encourage une exploration approfondie des problèmes au lieu de se contenter de solutions superficielles.​ Si on continue sur notre problème des documents mentionné ci-dessus, la méthode des 5 pourquoi donnerait quelque chose du style :

3. La conception, le prototypage, et les tests

Dès qu’on a franchi le cap d’avoir identifié quel est le problème principal et décidé de la solution la plus adéquate parmi plusieurs, on se pose un peu plus sérieusement avec les équipes Tech et Design pour mettre à plat comment on va attaquer la chose et on assiste souvent au choc des Titans (j’espère que vous avez du pop-corn !).

Rémi (best engineering manager 🫶) veut ajouter des gradients dans l’appli mobile mais ce n’est pas dans le design system et Yajing (UX) émet son (juste) mécontentement avec plein de "?????". Tim (upper left staff engineer) dit que ma proposition (Julie, PM, enchantée), est éclatée au sol et que de toute façon "on ne peut pas faire ça techniquement". Tout ça pour qu’au final, Alexian (dev expert wifi/clim) code le front-end sans regarder les designs disponibles dans Figma car "jaune / bleu, c’est tout pareil de toute façon".

L'univers des opinions diverses est en effervescence, chacun défendant sa vision du produit. En tant que PM, mon rôle est de naviguer entre les gradients souhaités par Rémi, les interrogations artistiques de Yajing, les contraintes techniques soulevées par Tim, et d’empêcher Alexian de partir en freestyle. Transformer ce choc des Titans en une symphonie harmonieuse tel un chef d’orchestre demande diplomatie et compréhension (mais aussi beaucoup de patience /o/). En fin de compte, le plus important c’est de faire des compromis, que tout le monde soit entendu et AIT entendu (c'est-à-dire, que tout le monde soit aligné avec la direction que l’on prend même si cela va à l’encontre de sa propre opinion de base).

TLDR : Comme dans la majorité des problèmes de couple, la clé ici est de :

1. Bien communiquer autour des décisions prises, de savoir expliquer pourquoi quelque chose a été fait, mais surtout d’avoir des arguments qui tiennent la route (malheureusement pour moi, "car j’ai décidé" n’est pas un bon argument, oops 🥲).
2. Rester objectif : c’est important de ne se rappeler que résoudre le problème est plus important que d’implémenter TA solution (falling in love with the problem, not the solution, remember?).
3. Garder son calme (allez, respire un bon coup).

De toute façon, une fois qu’on finit par se mettre d’accord, il reste une étape clé : le test avec les utilisateurs finaux qui parfois vient tout chambouler. On utilise des outils comme Maze pour présenter des scénarios distincts aux utilisateurs (internes ou externes) et récolter leur feedback. S'ensuit alors une multitude de points à prendre en compte : comment savoir lesquels considérer et lesquels ignorer, surtout quand les utilisateurs ne sont pas forcément capables de donner un feedback constructif ?

Chez Gojob, on classe les retours en fonction de leur impact sur les objectifs de notre fonctionnalité. On identifie les points critiques, les aspects récurrents, et on évalue l'importance pour l'expérience utilisateur.

Par exemple, lorsqu’on a décidé d’afficher les relevés d’heures dans l’application pour permettre aux intérimaires d’identifier les incohérences avant que la paie ne soit clôturée, on a récolté l’avis de presque 200 intérimaires et de 50 membres du staff. On a ensuite catégorisé les retours et identifié ceux qui revenaient le plus souvent pour les implémenter rapidement puis on a noté les moins importants dans notre backlog afin de tester plusieurs options une fois la feature lancée, car il ne faut pas se perdre dans la quantité non plus et savoir avancer.

4. L’alignement stratégique avec les stakeholders

J’ai noté ce point en 4, mais le processus de création de produit n’est pas linéaire (même si on aimerait bien), il est plutôt carrément itératif. Même si on tend vers un fonctionnement en one-piece flow chez Gojob, on doit communiquer avec de multiples personnes (utilisateurs, devs, design, stakeholders, etc…) à différentes étapes et ce plusieurs fois. Ainsi, il y a beaucoup d'alignements à faire notamment avec les stakeholders. En tant que PM, on se doit de les embarquer sur la vision du produit très tôt afin qu’ils soutiennent notre initiative et qu’on soit tous sur la même longueur d’onde au niveau des priorités business.

Que faire alors lorsque les stakeholders, passionnés, mais moins familiers avec les processus produits, expriment des opinions puissantes qui vont à l’encontre des recommandations qu’on leur fait ? On a tous déjà une fois dans sa vie vu cette image qui vaut 1000 mots :

Il est donc crucial de savoir répondre aux attentes du C-level pour avoir tout le monde on board, tout en restant maîtres du produit (après tout c’est nous les PM, right ?). Chez Gojob, on commence par :

• Présenter de la data solide, simplement et de façon structurée : comme mentionné précedemment dans l’article, fournir des données quantifiées pour étayer les décisions est un point d’entrée pour toute discussion mais ce n’est pas suffisant. Il faut également savoir formaliser simplement et de manière structurée et argumentée ses convictions.
• Prioriser les problèmes en amont : rien de pire qu’un PM qui n’est pas force de proposition dans un meeting. Être préparé(e) est très important et permet d’avoir un avantage.
• Être aligné(e) aux objectifs business : chaque trimestre Gojob partage ses OKR business, si on va à l’encontre des priorités établies, c’est déjà peine perdue.
• Écouter : c’est toujours bénéfique de considérer tous les points de vue, surtout qu’on ne peut pas tout savoir. Ca nous permettra également d’ajuster nos recommandations en fonction et de trouver des scénarios win-win.

Mais le plus dur reste bien évidemment de :

• Tenir ses convictions : tout en expliquant pourquoi et en restant diplomate. En effet, il peut y avoir des pressions diverses, mais rester fidèle à ses convictions, appuyé par des données solides, renforce la crédibilité. Cela nécessite parfois une communication délicate pour persuader sans compromettre l'intégrité du produit 💪.

Une fois les stakeholders dans la poche, le plus difficile est fait, mais il nous reste encore quelques challenges à relever !

5. Le lancement & monitoring

C’est là que vient le moment fatidique de lancer la solution en prod ! Est-ce qu’on a bien pris en compte tous les avis sans avoir pour autant créé un "Frankenstein-Product-Monster🧟‍♂️" qui est composé de l’avis de chacun et qui finit par faire plus peur qu’autre chose ?

• On identifie le top 3 des metrics qu’on veut suivre afin de regarder s’ils performent comme attendu et on s’y tient : si on lance les relevés d’heures (RH) dans l’app avec pour but de réduire les réguls de paie, aller regarder si le trafic de la page Academy a baissé n’est pas pertinent. Fini les dashboards à 40 KPIs pour un produit, SVP 🙏. Voici les 3 aspects qu’on souhaiterait étudier en priorité si on continue sur la lancée des relevé d’heures :

  • Est-ce que la feature est utilisée par nos intérimaires ? → Nombre de réclamations effectuées comparé aux personnes ayant accès à la feature.
  • Est-ce qu’elle nous facilite la vie ? → Temps de traitement des réclamations comparé à avant.
  • Est-ce qu’elle permet d’éviter les réguls de paie (corrections de bulletin d’une période de paie sur le mois suivant) → Évolution du taux de régul. chaque mois.

• On priorise les retours (pareil qu’à l’étape de user research ou de testing) pour les traiter correctement : modifier l’arrondi d’une textbox pourra attendre 2026, OK ?
• On organise des sessions régulières de revue post-lancement avec toutes les parties prenantes pour évaluer les performances et établir les futures itérations pour que tout soit clair. L'objectif est de maintenir un dialogue ouvert, d'ajuster les stratégies en fonction des résultats réels, et d'assurer une amélioration continue sans compromettre l'intégrité du produit. Puis on itère, on itère, on itère !

L’enjeu principal étant de trouver l'équilibre délicat entre l'innovation et la stabilité, où chaque ajustement post-lancement compte pour évoluer vers un produit à la fois performant et aligné avec la vision initiale.

Conclusion

Deux options s’offrent à vous pour faire face au millier d’opinions qui vont se présenter à vous tout le long de la conception de votre produit :

• Vous pouvez développer votre capacité à distinguer les signaux utiles du bruit, créant ainsi un processus itératif d'amélioration continue et de succès durable en lisant cet article avec assiduité.
• Achetez des boules quiès.