L’origine de la découverte de produits

Je voulais écrire cet article depuis de nombreuses années, mais comme il est principalement de nature historique, il y a toujours eu des sujets plus urgents. Mais de temps en temps, quelqu’un me contactera parce qu’il essaie de retrouver l’origine du terme, et pendant cette pandémie, pour une raison quelconque, je reçois cette question plus fréquemment.

Tout d’abord, permettez-moi d’être clair que le concept de la découverte de produits existe depuis aussi longtemps que les logiciels, et certainement beaucoup plus longtemps que moi.

Nous avons toujours eu, et aurons probablement toujours, deux problèmes essentiels dans les logiciels: nous devons bon produit, puis nous devons construire le produit droit.

J’ai toujours été intéressé par les deux problèmes, mais je pense que le premier est plus difficile et c’est là que la plupart des innovations se produisent.

À partir de 2005, j’ai commencé à essayer le terme «découverte» pour désigner ce qu’il fallait construire, et en 2007, j’ai décidé d’y aller tout sur le terme, et depuis lors, j’ai appelé le premier problème Découverte, et le second comme livraison.

En 2007, je travaillais sur la première édition d’INSPIRED, et j’avais une date limite de publication approchant, et j’ai dû décider quel terme utiliser, le cas échéant.

À l’époque, presque tous les chefs de produit parlaient de «rassembler et définir les exigences», mais je considérais cela comme l’une des raisons fondamentales pour lesquelles il y avait tant de produits défaillants. Pour moi, parler de la définition des exigences était non seulement erroné, mais arrogant.

J’ai aussi pu constater que dans les bonnes équipes, les produits étaient conçus par de véritables collaborations entre ingénieurs, designers et chefs de produits. Pas par un chef de produit déclarant “ce sont les exigences, maintenant allez concevoir et construire ceci.”

Je voulais donc un terme qui évoque une image très différente dans l’esprit des chefs de produits et des équipes de produits. Je voulais qu’ils aient un esprit ouvert, pour savoir ce qu’ils ne peuvent pas savoir et admettre ce qu’ils ne savent pas.

Je voulais souligner que les excellents produits sont le résultat d’une collaboration entre les produits, la conception et l’ingénierie.

Je voulais qu’ils réfléchissent en termes de “trouver une solution à un problème qu’on nous a demandé de résoudre” plutôt que de “dicter les exigences d’une fonctionnalité que l’on nous a demandé de créer”.

J’ai trouvé le terme «découverte» de l’industrie pharmaceutique pour le processus utilisé pour trouver un médicament viable. Contrairement à l’industrie du logiciel, l’industrie pharmaceutique a reconnu le risque dès le départ. Ils s’attendaient à ce que nombre de leurs médicaments, sinon la plupart, ne soient pas suffisamment sûrs et efficaces pour être fabriqués, distribués et vendus.

J’ai aussi aimé le terme «découverte» car il était indépendant de la technique. Il existe un certain nombre de techniques utilisées pour aider à la découverte, et de nouvelles apparaissent tout le temps. Un MVP est une technique de découverte, tout comme le design thinking, tout comme le développement client, tout comme «Jobs to Be Done».

C’était très important pour moi parce que j’ai vu tellement de techniques et de méthodes aller et venir, donc je ne voulais pas m’associer explicitement à aucune d’entre elles.

J’ai également apprécié que le terme «découverte» incite les équipes produit à réfléchir aux risques de valeur, d’utilisabilité, de faisabilité et de viabilité.

En général, je suis réticent à essayer d’introduire une nouvelle nomenclature. C’est une chose difficile à faire, et même si les gens réagissent bien, il faut du temps pour se répandre, et vous devez vraiment choisir vos batailles sur des choses comme ça.

Mais aujourd’hui, je suis heureux de voir que tant d’équipes de produits comprennent le concept et ont au moins une compréhension raisonnable de la manière et des raisons pour lesquelles nous faisons la découverte de produits.

Désormais, je me concentre davantage sur le fait de m’assurer que les équipes produit travaillent dans un environnement où elles sont habilitées à faire de la découverte de produits, plutôt que de se contenter de définir des feuilles de route.