Pendant longtemps les méthodes agile ont plutôt mis l’emphase sur le Delivery des produits (c’est-à-dire des spécifications jusqu’à la livraison). Aujourd’hui nous devons nous assurer que les produits développés répondent efficacement à de vrais problèmes et qu’ils permettent de dégager de la valeur utilisateur et Business. C’est là que le Product Discovery entre en jeu !
Comment évaluer le potentiel de réussite d’une idée ?
3 critères permettent d’évaluer le potentiel de réussite d’une idée de nouveau produit ou de nouvelle fonctionnalité dès leur conception :
📌 DÉSIRABILITÉ, VIABILITÉ & FAISABILITÉ
Ne pas prendre en compte l’un de ces critères est une source d’échec. Les utilisateurs ne seront pas intéressés, le ROI ne sera pas au rendez-vous, ou la complexité de mise en œuvre sera trop importante.
Pourquoi faire du Product Discovery ?
Le Product Discovery permet de lever les risques le plus tôt possible et de répondre au mieux aux besoins clients et aux enjeux de l’entreprise. Ainsi, les activités de Product Discovery consistent à :
– Comprendre les besoins et points de douleurs des clients
– Étudier des opportunités de solutions
– S’assurer que toute solution intégrée au backlog vaut la peine d’être développée tant pour les utilisateurs que pour l’entreprise
Les étapes du Product Discovery
Le cycle du Product Discovery comporte 5 étapes. Il est en général itératif : il faudra reprendre plusieurs fois les étapes en fonction des résultats obtenus.
Voici ces 5 étapes :
Première étape
La première étape consiste évidemment à repartir des clients et de la compréhension de leurs besoins. Pour cela vous devrez probablement mêler recherche qualitative & quantitative pour appréhender au mieux les besoins et points de douleur de vos clients.
Outils phares : Personae & Parcours utilisateurs
Deuxième étape
Une fois que les besoins utilisateurs seront précisés et validés, il s’agit d’identifier des solutions pouvant répondre à ces besoins. Vous pourrez alors poser les hypothèses structurantes à tester.
Il est important de pouvoir échanger dès cette étape avec les équipes techniques. C’est ce qui vous permettra de partir sur une solution réaliste et réalisable dans les temps souhaités !
Outil phare : la structuration d’une hypothèse
Troisième étape
Une fois que les besoins utilisateurs seront précisés et validés, il s’agit d’identifier des solutions pouvant répondre à ces besoins. Vous pourrez alors poser les hypothèses structurantes à tester.
Il est important de pouvoir échanger dès cette étape avec les équipes techniques. C’est ce qui vous permettra de partir sur une solution réaliste et réalisable dans les temps souhaités !
Outil phare : la structuration d’une hypothèse
Quatrième étape
Ensuite, pensez à travailler la dimension économique (première enveloppe budgétaire et ROI potentiel). Elle est tout aussi importante à ce stade du Discovery, notamment pour convaincre les sponsors.
Les questions à se poser
Dernière étape
Enfin, il vous reste à tester vos hypothèses auprès des utilisateurs cibles à travers un prototype. En fonction des tests utilisateurs, vous pourrez voir ce qui est validé, ce qui est à changer absolument et ce qu’il faudrait ajouter pour que le produit corresponde à leurs besoins.
Outil phare : Stop, Do, Start
Pour piloter cette étape de Product Discovery, nous nous appuyons sur le Lean Canvas. Il donne une vue synthétique des éléments clés de décision. Il est complété et amendé progressivement tout au long du processus de découverte.
💡 Gardez en tête …
Le Product Discovery sert avant tout à limiter les risques et s’assurer que l’on développe une idée qui apporte de la valeur.
Il convient donc d’adapter le temps et le budget consacrés à cette étape en fonction du niveau de risque de l’idée étudiée.
Plus l’idée étudiée est nouvelle, plus vous investirez du temps et de l’énergie pour dérisquer le projet. A l’inverse, le Discovery sera plus rapide si vous êtes sur une idée d’amélioration avec peu de doutes à lever
Vous pourriez aussi être intéressé par l’article suivant | Discovery Product Management : la refonte du blog de Qonto