La Culture de l’imperfection

Dans notre société, la recherche de la perfection est désormais une constante. On est en quête de vacances parfaites, de l’appartement parfait, du couple parfait. Il est donc logique de poursuivre aussi cette perfection dans notre travail quotidien.  
Ainsi la question mérite d’être posée, qu’est-ce qui est mieux que parfait ? Est-ce que le produit parfait existe vraiment ?

Done is better than perfect

C’est un adage que nous avons tous entendu et qui nous est même familier en agilité. Mais pourtant il n’est pas toujours respecté au quotidien. La raison n’est pas le manque de bonne volonté ou le fait de ne pas croire à cette citation. Ce n’est pas non plus le manque d’envie de finaliser un produit. Le principal obstacle à la réalisation de cette citation est quelque chose qui nous anime au quotidien : l’utilisateur.  
Effectivement nous avons envie de penser à l’utilisateur final. C’est d’ailleurs l’essence même de notre métier : développer un produit qui réponde un maximum à ses attentes. Cependant, l’erreur qui doit être évitée est de penser à tous les utilisateurs. La perfection n’existe pas dans ce monde, un produit ne pourra jamais répondre parfaitement aux besoins de chaque utilisateur, ni à la façon dont chacun d’eux interagit avec notre produit. Cette réflexion est déterminante et doit rester dans notre esprit pendant sa construction.

On m’a souvent répété « as-tu pensé à ce cas ? » pour évoquer une situation particulière, souvent plus compliquée à gérer. Penser à toutes les variables est effectivement important pour la maîtrise de son périmètre, vouloir à tout prix bien les contrôler nous éloigne de notre objectif : done. Il est impossible de couvrir la totalité des cas utilisateurs, il est donc essentiel de se focaliser sur les plus pertinents.

Done gets results

Délivrer permet d’avoir quelque chose de plus concret que la perfection : des résultats. En effet l’itération est ce qui rythme nos cycles de production et le feedback tient un rôle prépondérant dans ce mécanisme. Le feedback qui a le plus de valeur reste celui de l’utilisateur final, et le meilleur moyen de le recueillir est la mise en production la plus rapide possible.  
Pourquoi tarder alors ? Le principal frein trouve parfois sa source dans une peur de l’imperfection. Cette peur nous entraîne dans une paralysie de l’évolution du produit. Nous voulons un produit parfait, donc nous repoussons sa mise en production, qui retarde ainsi les premiers feedbacks, et qui ralentit à son tour l’évolution du produit qui dépend de l’analyse de ces résultats. Ce cercle vicieux a au final des conséquences sur la  personne pourtant au centre de nos préoccupations : l’utilisateur.  

J’ai lu il y a quelque temps un exemple qui reflète parfaitement cet état d’esprit : au moment de sa construction, il faut mettre un navire à l’eau pour vérifier qu’il flotte. S’il coule, on trouve rapidement le trou pour le réparer. S’il flotte, on se concentre sur les améliorations à apporter.

Attention aux péchés

Ces réflexions me font penser au podcast de Product Squad où Rémi Guyot (Blablacar) est intervenu et a évoque les 7 péchés capitaux du Product Manager. Deux de ces derniers font référence à la perfection et à l’intérêt de plutôt rechercher l’imperfection.  
Le premier est le péché de colère. Le Product Manager est face à une situation simple qui résout le besoin de 80% de ses utilisateurs, mais nourri par la « colère » de ne pas avoir trouvé la solution parfaite, le PM plonge dans des cycles de réflexion. Cela induit une livraison plus longue, entraînant ainsi une mise en production et une itération retardées. Pour finalement faire le choix d’une solution trop complexe et qui ne sera toujours pas parfaite.  

Le deuxième est le péché de gourmandise. Le Product Manager ressent une empathie infinie envers ses utilisateurs et cherche des réponses à tous leurs problèmes. En créant une solution spécifique pour chaque utilisateur, il complique son produit et il finit par dégrader l’expérience principale qui fonctionnait pour la majorité. En étant trop « gourmand », il augmente la complexité avec une multitude de fonctionnalités. Le Product Manager nourrit alors son ego au détriment de son produit.  

Assumer l’imperfection

Le plus simple pour réussir à se débarrasser de la perfection est d’assumer l’imperfection de son produit. Le verbaliser rend les choses claires et limpides et enlève le poids de la responsabilité sur l’équipe et le Product Manager. Le produit que je développe actuellement n’est pas parfait, mais les différentes itérations que nous allons mettre en place vont le rapprocher des attentes de nos utilisateurs. Les données que je vais pouvoir récolter suite à sa mise en production vont être pertinentes pour son cycle de vie.
L’approche MVP semble se prêter parfaitement à ce besoin. En tant que Product Manager, j’accepte de sortir le plus rapidement possible un produit imparfait en production afin de récolter les retours de mes utilisateurs. Ces retours me permettent de prendre les meilleures décisions pour l’améliorer et pour continuer à le faire grandir tout en apportant de la valeur à l’utilisateur.

Cela permet d’avoir une plus grande transparence sur les fonctionnalités délivrées et une communication plus fluide envers ses stakeholders : j’assume que mon produit est imparfait et qu’il va évoluer. Reid Hoffman, fondateur de Linkedin dit ceci : “If you are not embarrassed by the first version of your product, you’ve launched too late”. Le MVP doit servir essentiellement à recueillir des retours, qui vont alimenter une roadmap avec des fonctionnalités demandées par les utilisateurs, d’où l’importance de le lancer le plus rapidement possible.

Une autre approche intéressante est le fail fast. Je livre une version imparfaite de mon produit tout en limitant les conséquences d’un potentiel échec. Ainsi, chaque échec me fournit des informations pour ma future itération. Cela permet donc de tester rapidement l’appétence des utilisateurs pour une fonctionnalité avec un moindre coût et de diriger notre énergie vers le bon angle d’approche.  

Imperfection ≠ anomalies

Il est très important de faire la nuance entre ces 2 termes et de garder une grande exigence en termes de qualité. Un produit imparfait ne sous-entend pas un produit qui bugue. Il est aussi déterminant que l’équipe reconnaisse cette différence.  
L’imperfection accélère le rythme de mise en production et procure un retour utilisateur rapide alors que l’anomalie ralentit le cycle de production.  

Un produit imparfait peut répondre correctement aux attentes de tous ces utilisateurs, même avec un parcours dégradé pour certains d’entre eux, sans que ce soit quelque chose qui pose un problème, si ce dernier est maîtrisé : je maîtrise mon produit et je traite la grande majorité des cas utilisateurs. Cependant, une infime partie de mon trafic ne bénéficie pas d’une expérience optimale, est-ce une anomalie ? Non, le temps passé à améliorer l’expérience utilisateur pour cette minorité devrait être investi dans l’évolution des fonctionnalités futures de mon produit.

Conclusion

Si la perfection existe, nous ne la cherchons pas. Poursuivre à tout prix quelque chose qui s’en rapproche ne peut être que contre-productif. Nos utilisateurs ne désirent pas un produit parfait mais un produit utile, qui répond à leurs besoins. C’est en forgeant qu’on devient forgeron, l’idée de test and learn doit rester au cœur de la réflexion quotidienne d’un Product Manager. Continuons donc à ravir nos utilisateurs et soyons fiers de nos produits parfaitement imparfaits.  

‍