Product Discovery : la méthode pour valider vos idées produit avant de développer

Le Product Discovery précède le développement : il consiste à vérifier qu'un problème mérite d'être résolu, et que la solution envisagée le résout vraiment, avant d'y consacrer du temps d'ingénierie. Marty Cagan, ancien vice-président produit chez eBay et Netscape, a largement contribué à populariser cette approche depuis les années 2010, via son livre Inspired et les travaux de son cabinet Silicon Valley Product Group.

Les quatre risques que le Discovery cherche à réduire

Risque	Question à laquelle il répond
Risque de valeur	Les utilisateurs vont-ils réellement vouloir cette solution ?
Risque d'utilisabilité	Les utilisateurs vont-ils comprendre comment l'utiliser ?
Risque de faisabilité	L'équipe technique peut-elle la construire dans les contraintes données ?
Risque de viabilité	Cette solution sert-elle les objectifs de l'entreprise ?

La méthode, étape par étape

Formuler clairement le problème supposé, sans partir directement d'une solution.
Interroger un échantillon d'utilisateurs réels ou potentiels pour vérifier que le problème existe et qu'il est prioritaire pour eux.
Esquisser plusieurs pistes de solution, sans s'engager sur la première idée venue.
Tester ces pistes à faible coût (prototype, maquette, expérimentation limitée) avant tout développement.
Décider, sur la base de ces retours, de développer, d'ajuster ou d'abandonner l'idée.

Un modèle simple pour démarrer

Problème observé : quel comportement ou quelle frustration a été constaté, et chez qui ?
Hypothèse : en quoi pensons-nous que ce problème est important à résoudre ?
Preuve recherchée : quel signal confirmerait ou infirmerait cette hypothèse ?
Méthode de test : entretien, prototype, sondage, expérimentation limitée.
Décision : développer, ajuster l'hypothèse, ou abandonner l'idée.

Erreurs fréquentes

Confondre Discovery et simple recueil des demandes des clients.
Passer directement au développement dès qu'une idée semble bonne sur le papier.
Ne solliciter que des utilisateurs déjà convaincus, qui biaisent les retours.

Le Discovery a néanmoins ses propres limites. Il fonctionne bien pour améliorer un produit existant à partir de retours observables, beaucoup moins pour des ruptures véritables, où les utilisateurs peinent à exprimer un besoin qu'ils n'ont encore jamais pu satisfaire faute de solution existante. Une organisation qui en fait un passage obligé pour chaque décision, sans discernement, risque de retarder des paris qui méritaient d'être tentés plus tôt, sur la base du jugement de l'équipe plutôt que d'une validation exhaustive.

Diagnostic Produit·Voir un aperçu du diagnostic