L'Origine du Product Discovery
Auteur : Marty Cagan
Source : The Origin of Product Discovery
Date : 01/06/2020
Traducteur : Fabrice Aimetti
Date : 21/01/2024
Traduction :
Cela fait des années que j'ai l'intention d'écrire cet article, mais comme il est avant tout de nature historique, il y a toujours eu des sujets plus urgents. Mais de temps en temps, quelqu'un me contacte parce qu'il essaie de retrouver l'origine du terme, et pendant cette pandémie, pour une raison ou une autre, j'ai reçu cette question plus fréquemment.
Tout d'abord, je tiens à préciser que le concept de product discovery (découverte produit) existe depuis aussi longtemps que les logiciels, et certainement depuis bien plus longtemps que moi.
Nous avons toujours eu, et nous aurons probablement toujours, deux problèmes essentiels dans le domaine des logiciels : nous devons trouver le bon produit, et nous devons ensuite construire le bon produit.
J'ai toujours été intéressé par ces deux problèmes, mais je pense que le premier est plus difficile à résoudre et que c'est là que se produit la plus grande partie de l'innovation, c'est donc là que je concentre le plus mon attention.
Vers 2005, j'ai commencé à essayer le terme "discovery" pour désigner la manière dont nous déterminons ce qu'il faut construire, et en 2007, j'ai décidé d'adopter ce terme à part entière, et depuis lors, je désigne le premier problème par le terme "discovery" et le second par le terme "delivery".
En 2007, je travaillais sur la première édition d'INSPIRED, la date limite de publication approchait et je devais décider quel terme utiliser, si tant est qu'il y en ait un.
À l'époque, pratiquement tous les product managers parlaient de "collecte et définition des besoins", mais je considérais que c'était l'une des raisons fondamentales pour lesquelles il y avait tant de produits qui n'aboutissaient pas. Pour moi, parler de définition des exigences n'était pas seulement malavisé, mais aussi arrogant.
J'ai également pu constater que dans les bonnes équipes, les produits étaient conçus dans le cadre d'une véritable collaboration entre les ingénieurs, les concepteurs et les product managers. Et ce n'est pas un product manager qui déclare "voici les exigences, maintenant allez concevoir et construire cela".
Je voulais donc un terme qui évoque une image très différente dans l'esprit des product managers et des équipes produits. Je voulais qu'ils aient l'esprit ouvert, qu'ils sachent ce qu'ils ne peuvent pas savoir et qu'ils admettent ce qu'ils ne savent pas.
Je voulais insister sur le fait que les bons produits sont le résultat d'une collaboration entre le produit, la conception et l'ingénierie pour atteindre un résultat, plutôt que de simplement pousser les exigences le long de la chaîne et de livrer le produit.
Je voulais qu'ils pensent à "trouver une solution à un problème que l'on nous a demandé de résoudre" plutôt qu'à "dicter les exigences d'une fonctionnalité que l'on nous a demandé de construire".
J'ai trouvé le terme "discovery" dans l'industrie pharmaceutique pour désigner le processus utilisé pour mettre au point un médicament viable. Contrairement à l'industrie du logiciel, l'industrie pharmaceutique reconnaissait d'emblée le risque. Elle anticipait le fait qu'un grand nombre de ses médicaments, sinon la plupart, ne seraient pas suffisamment sûrs et efficaces pour être fabriqués, distribués et vendus.
J'ai également aimé le terme "discovery" parce qu'il ne tient pas compte de la technique. Il existe un grand nombre de techniques utilisées pour faciliter la découverte, et de nouvelles apparaissent en permanence. Le MVP est une technique de découverte, tout comme le design thinking, le customer development et le "Jobs To Be Done".
