Ressources > Articles
Pourquoi la discovery est la compétence la plus sous-estimée du Product Manager
Stratégie Produit
La discovery est souvent présentée comme une phase. Une étape qu’on fait en début de projet, avant de « passer à l’exécution ». Dans la réalité des équipes produit que j’ai pilotées, cette vision est fausse — et coûteuse.
La discovery n’est pas une phase. C’est un état permanent. Et quand elle s’arrête, les mauvaises décisions s’accumulent silencieusement, jusqu’au moment où une refonte coûteuse les rend visibles.
Voici comment j’aborde la discovery et l’analyse utilisateur sur mes missions de Head of Product freelance et de Product Manager.
Comprendre avant de construire, même sur un marché émergent
Le cas le plus difficile n’est pas celui où les utilisateurs ont des besoins clairs. C’est celui où le marché n’existe pas encore et où personne ne sait exactement ce qu’il faut construire, ni les clients, ni l’équipe produit.
Chez AXA Climate, on lançait une plateforme de surveillance des risques climatiques B2B sur un marché émergent. Pas de référentiel, pas de benchmarks, pas d’utilisateurs existants à interroger. On a mené plus de 50 interviews métiers — assureurs, gestionnaires de risques, responsables RSE — pour comprendre les cas d’usage réels, les données disponibles, et les contraintes opérationnelles. C’est cette discovery intensive qui a permis de cadrer les modules prioritaires et de livrer un MVP pertinent en 8 mois.
Ce que ça enseigne : plus le marché est incertain, plus la discovery est critique. On ne peut pas compenser l’incertitude avec de la vitesse d’exécution.
Qualitatif et quantitatif : deux outils distincts
La recherche qualitative dit le pourquoi. La recherche quantitative dit le quoi et le combien. Les deux sont nécessaires, mais ils ne répondent pas aux mêmes questions : les confondre mène à de mauvaises conclusions.
Chez DataDome, les données d’usage montraient un taux d’engagement qui stagnait sur certaines parties de la plateforme. La donnée quantitative posait le problème. Les sessions d’observation avec les utilisateurs, des équipes sécurité et des développeurs, ont expliqué pourquoi : l’interface ne reflétait pas la façon dont ils travaillaient réellement. C’est cette combinaison qui a guidé la refonte. Résultat : +19% d’engagement en six mois.
Chez Closd, on utilisait Productboard pour centraliser tous les signaux qualitatifs — remontées Support, retours CSM, feedbacks Sales — et les croiser avec les données d’usage sur Amplitude. Chaque initiative roadmap était évaluée sur les deux dimensions : est-ce que les utilisateurs le demandent, et est-ce que les données confirment l’ampleur du problème ?
Ce que ça enseigne : une donnée quantitative sans contexte qualitatif est une corrélation sans cause. Une remontée qualitative sans validation quantitative est une anecdote. Les deux ensemble, c’est une décision.
Structurer la discovery continue
La discovery continue ne signifie pas interviewer des utilisateurs en permanence. Ça signifie avoir des canaux de feedback actifs, des rituels réguliers, et une équipe qui sait quand déclencher une investigation approfondie.
Chez Closd, on a mis en place trois canaux :
Les interviews régulières. Chaque PM avait un quota d’interviews par sprint, pour maintenir le contact avec les usages réels, en dehors de toute hypothèse à valider. Tout développement important passait par au moins trois entretiens clients au préalable.
Le Club Utilisateur. Un cercle de clients engagés, consultés en amont des grandes décisions roadmap. Des échanges directs et informels, sans formalisme de comité, avec des utilisateurs qui avaient envie de contribuer au produit.
Productboard comme hub central. Toutes les remontées centralisées, taguées, reliées aux initiatives roadmap. Ça permet de prioriser avec des données agrégées plutôt qu’avec la voix du dernier client qui a appelé.
Ce que ça enseigne : la discovery continue fonctionne quand elle est intégrée aux rituels de l’équipe. Traitée comme un projet à part, elle s’éteint.
De l’insight à l’arbitrage
Collecter des insights ne suffit pas. Le travail du Product Manager ou du Head of Product est de transformer ces insights en décisions d’arbitrage — et d’assumer ces décisions face aux parties prenantes.
Chez Closd, la décision de lancer la Data Room n’est pas venue d’une demande explicite des utilisateurs. Elle est venue d’une combinaison de signaux : des entretiens qui révélaient des frustrations sur la gestion documentaire en M&A, des données d’usage qui montraient que les clients les plus engagés avaient des besoins au-delà de la signature, et une analyse du marché LegalTech qui confirmait le gap. J’ai arbitré en faveur de ce développement, défendu la décision en Comité Opérationnel, et piloté le lancement. +40% d’ARR en suivant.
Ce que ça enseigne : la discovery alimente l’arbitrage. La décision reste au PM. Un Product Leader qui attend que les données lui disent quoi faire attend trop longtemps. Les données éclairent. La décision, c’est le PM qui la prend.
Ce que j’en retiens
La discovery et l’analyse utilisateur vont au-delà des exercices méthodologiques. Elles sont le fondement de décisions qui tiennent face à la pression business, aux demandes contradictoires, et aux inconnues du marché.
Un Product Manager qui maîtrise la discovery prend des décisions plus vite, avec plus de confiance, et avec moins de refontes coûteuses derrière lui.