Pourquoi la Product Discovery est encore si peu répandue ?

Il y a quelques jours, j'ai eu une discussion au sujet de ProductFrogs avec une amie au cours de laquelle elle m'a dit : "C'est dingue, dans ma boîte on a un CPO, des Head of Product, des PM, on entend parler de Scrum et d'agilité toute la journée, mais c'est la première fois que j'entends parler de Product Discovery".

En creusant un peu, je comprends qu'ils fonctionnent avec un cycle en V classique (ou waterfall),  les fonctionnalités à développer sont dictées par le management, les PM les transforment en specs et les développeurs exécutent.

Sans dire où elle travaille, je préciserais simplement que c'est une grande entreprise française du tertiaire que tout le monde connaît et pour qui le développement logiciel est vital.

Malheureusement ce cas de figure est plus que courant, c'est même une situation que l'on retrouve dans la majorité des entreprises qui font du logiciel aujourd'hui (et que vous rencontrez peut-être vous même au quotidien ?). Alors oui, quand on regarde l'écosystème des start-ups, c'est une situation que l'on rencontre moins souvent, mais ces entreprises ne sont pas représentatives de l'industrie du soft en France.

J'écris donc cet article dans une optique d'évangélisation parce que bon... il est temps que tout ça évolue non ? 😉

Je précise également que l'objectif de ce qui suit n'est pas d'expliquer en détails comment faire la Product Discovery, je laisse cela pour un prochain article.

La Product Discovery : qu'est-ce que c'est et pourquoi c'est essentiel ?

Depuis plus d'une trentaine d'années, le focus du Product Management a été mis sur la phase de delivery (des spécifications produit jusqu'à la livraison). Les méthodes agiles se sont développées, si bien que le Scrum et le Kanban sont aujourd'hui largement démocratisés dans les équipes de développement permettant aux entreprises de "livrer du code" avec une grande efficacité.

Pendant toutes ces années, nous avons donc perfectionné le "comment faire" les choses en laissant au second plan le "quoi faire". Autrement dit : pendant longtemps on s'est concentré sur le domaine du développement de la solution, en délaissant quelque peu le domaine du problème.

La difficulté que cela pose est parfaitement résumée par Peter Drucker (consultant en management, Pionnier du Management par les Objectifs) dans la phrase suivante :

There is nothing quite so useless as doing with great efficiency something that should not be done at all - Peter Drucker

Traduction : "Il n'y a rien de plus inutile que de faire avec une grande efficacité quelque chose qui ne devrait pas être fait du tout".

L'intérêt pour les méthodes et frameworks permettant de bien cadrer le "quoi" est pourtant bien présent depuis de nombreuses années (avec par exemple David Kelley qui a popularisé au début des années 90 le Design Thinking, le prototypage, les itérations rapides...), mais comparé aux méthodes agiles de développement, il y a un net retard dans leur adoption par les entreprises.

Pourtant le "quoi" et le "comment" sont indissociables, tout aussi importants, et le bon sens nous dit que l'un devrait venir avant l'autre. Après tout, pourquoi risquer de développer le mauvais produit ou les mauvaises fonctionnalités, si l'on peut valider en amont que l'on répond à un vrai besoin utilisateur avec la bonne solution ? C'est la raison d'être de la Product Discovery : s'assurer que l'on développe les bons produits en éliminant les risques de se tromper au plus tôt et pour le moins cher possible.

Pourquoi ce n'est pas plus répandu ?

Si le bénéfice de la Product Discovery semble évident, on peut se demander pourquoi les méthodes associées ne sont pas plus répandues dans les entreprises. Les principales explications de ce retard sont selon moi les suivantes :

Une pratique encore récente

Comme évoqué plus haut, les méthodes de Product Discovery sont arrivées après les méthodes agiles de développement et sont donc mécaniquement moins connues et moins répandues en entreprise. Le temps devrait donc contribuer à changer cela.

La culture d'entreprise

C'est le plus grand frein à l'adoption de la Product Discovery (et des méthodes de Product Management modernes) car cette pratique récente bouscule les organisations en place et les périmètres de responsabilités du management. Elle nécessite en effet de donner beaucoup d'autonomie aux équipes produit et de les laisser décider des meilleures solutions à développer. Les équipes produit sont alors managées avec des objectifs business à atteindre et non avec des roadmaps de features à développer.

Or, on rencontre encore trop souvent le cas de figure décrit au début de l'article où c'est le top management qui décide des fonctionnalités à développer et les équipes produit sont simplement là pour exécuter. En plus du manque de délégation, ce type de fonctionnement vient généralement avec une hiérarchie rigide et le classique "HiPPO" (Highest Paid Person's Opinion) où l'on retient généralement l'avis du manager "le plus gradé".

Source : businessillustrator.com

Si vous voulez en savoir plus sur les équipes produit autonomes et les organisations produit modernes, je vous invite à aller lire mon résumé du livre de Marty Cagan : "Inspired: How to create tech products customers love".

Notre cerveau n'aime pas les problèmes

C'est un de nos nombreux biais cognitifs : quand nous voyons un problème, notre cerveau a tendance à vouloir le résoudre rapidement, ce qui conduit souvent à aller trop vite, à suivre ses intuitions et à faire développer une des premières solutions qui vient à l'esprit et qui semble résoudre le problème. Cette façon de faire est une des erreurs les plus répandues en product management.

Pourtant la pratique de la Product Discovery montre qu'il faut du temps pour comprendre les usages et les problèmes des utilisateurs et pour trouver les bonnes solutions. Les meilleurs produits sont faits par les équipes qui prennent le temps de parfaitement comprendre les problèmes des utilisateurs, pas par celles qui se précipitent sur les solutions.

Fall in love with the problem, not the solution - Waze cofounder Uri Levine

Traduction : "Tombez amoureux du problème, pas de la solution".

Le manque de temps

Le quotidien du Product Manager est souvent chargé de tâches aussi complexes que chronophages. Même dans les organisations produit modernes, les Product Managers ont vite fait de se laisser absorber par les réunions et les tâches quotidiennes liées au domaine du développement de la solution laissant peu de temps pour la Product Discovery.

Un savoir-faire à acquérir

Même dans les organisations produit modernes où l'on a conscience de l'importance d'une compréhension profonde des utilisateurs, la Product Discovery ne s'improvise pas. Comment mener des entretiens avec les utilisateurs ? Comment identifier les vrais problèmes à résoudre ? Comment interpréter les data d'usage ? Comment gérer les feedbacks utilisateurs et les reformuler ? Quel type de prototype choisir pour quelle situation ? Comment tester et valider une solution ?... Autant de questions qui nécessitent une formation ad hoc des Product Managers et de la pratique.

Pourquoi est-il important d'intégrer cette pratique dans son organisation produit ?

Avoir une compréhension profonde de ses utilisateurs est une nécessité, cela permet de créer des produits que les clients veulent et dont ils ont besoin. Grâce à la Product Discovery, on évite non seulement de gaspiller ses ressources sur des produits qui ne marcheront pas, mais c'est aussi ce qui va faire la différence entre des fonctionnalités "nice to have" et des produits qui vont réellement simplifier la vie des utilisateurs en résolvant leurs problèmes.

Ce processus permet également de s'assurer que les équipes produit travaillent sur les bons sujets.

Sans cette compréhension profonde des utilisateurs, on s'expose à un certain nombre de problèmes :

• On s'appuie trop souvent sur des intuitions pour identifier les problèmes utilisateurs et construire les solutions : que ça soit l'intuition du CEO ou celle du product manager, cela conduit rarement aux bons produits. La raison est simple : aucune intuition ne remplace un travail de recherche utilisateur approfondi et une confrontation des solutions potentielles auprès de ces utilisateurs. Les décisions produit doivent être prises en s'appuyant sur des preuves et non sur des intuitions.
• Même si l'on a parfaitement compris le besoin des utilisateurs, la première solution proposée est rarement la bonne, il faut plusieurs itérations pour l'améliorer et apporter la valeur attendue (par exemple, un produit peut répondre à un besoin mais avec une mauvaise ergonomie).
• Lorsque l'on travaille dans un mode très "top down", on laisse généralement peu d'autonomie aux équipes produit. La conséquence directe est un manque de motivation et d'implication ("on fait ce qu'on nous demande de faire, le succès ou non du produit n'est pas de notre ressort"), et évidemment un turn-over plus élevé, en particulier chez les bons profils.
• Enfin avec ce fonctionnement "top down", la validation de la valeur arrive bien trop tard : c'est uniquement au moment de la mise en marché que l'on saura si le produit apporte la valeur attendue par les utilisateurs.

Rich Mironov (auteur de "The Art of Product Management") décrit les conséquences de "sauter" la phase de Product Discovery :

“A lot of organizations skip user research, testing, and validation and get right into solutions and what they want to build. The result is a struggle to find a meaningful market that will use and pay for the product.” - Rich Mironov

Traduction : "Beaucoup d'organisations sautent les phases de recherche utilisateur, de tests et de validation et vont directement aux solutions qu'elles veulent construire. Le résultat est qu'elles ont du mal à trouver un marché significatif qui voudra utiliser et payer pour leur produit."

Conclusion

La capacité à faire la Product Discovery correctement est une des compétences clés des meilleures organisations produit et c'est ce qui a fait le succès des grands noms de la tech. Cette pratique demande cependant un effort de mise en place important de la part des entreprises, car elle nécessite de laisser une autonomie suffisante aux équipes produit pour chercher et décider elles-mêmes ce qu'elles vont développer. Cela requiert souvent une réorganisation et une délégation des responsabilités du management vers les équipes produit, ce qui représente un vrai changement culturel. Pourtant ce changement en vaut la peine, et il peut être fait progressivement. Par exemple, on peut commencer par constituer une équipe produit qui va travailler sur un sujet business donné avec cette méthode de travail. Une fois les effets bénéfiques de ce changement observés, on peut ensuite l'étendre au reste de l'organisation. Et comme on dit : "l'essayer, c'est l'adopter" ! 😉