Rémi Guyot, co-auteur de Discovery Discipline avec Tristan Charvillat, s’interroge dans cette tribune sur les conséquences d’une discovery à outrance et sans limites par certains Product Managers et Product Designers. Au point d’oublier le rouage essentiel qu’est la phase de delivery.
J’ai récemment observé un phénomène qui m’a d’abord surpris, puis m’a amusé… Pour finir par m’inquiéter ! Ce phénomène, c’est l’émergence de Product Managers et Product Designers portant la discovery aux nues, au détriment du delivery.
En sondant des pairs pour savoir si d’autres que moi partageaient cette impression, je n’ai pas été déçu. Pour Raphaël Bonstein, Chief Product & Technology Officer chez Studapart, “la mode créée autour de la discovery détourne beaucoup de Product Managers du delivery. Plus personne ne veut faire du delivery, comme si c'était “sale”. Ça m'a même bloqué dans des recrutements. Dire à des candidats qu’ils vont faire des specs, c’est devenu un gros mot.” Croire que le delivery serait mineur ou secondaire, c’est ignorer la spécificité même de notre domaine d’activité. Peut-être que, à force de vivre dans une bulle, nous avons oublié en quoi notre matière de travail, le digital, était le fondement même de notre manière de travailler.
Vous êtes-vous demandé pourquoi le domaine du digital était systématiquement associé aux notions d’itérations et de vitesse ? Pourquoi la notion d’agilité a-t-elle émergé si fortement avec les métiers du développement informatique, et non dans le domaine de l’architecture de bâtiments, par exemple ? Pour une raison simple : le digital permet d’avoir une boucle extrêmement courte entre la conception d’un produit, sa distribution auprès de la cible visée et la mesure de son adoption. Cette boucle, ultra-rapide, permet de corriger d’éventuels écueils tellement vite qu’il est préférable de lancer quelque chose d’imparfait - et le corriger ensuite si besoin - plutôt que d’essayer d’anticiper ce qu’il va se passer. Cette spécificité, la vitesse d’itération, est le cœur de notre industrie. Essayez de trouver un autre domaine qui autorise autant d’approximations mises en production. Les industries de l’automobile ou du cinéma par exemple, seraient complètement différentes si elles avaient la possibilité de corriger leurs produits toutes les deux semaines, basées sur des données réelles d’utilisation – malheureusement, leurs matériaux respectifs ne leur permettent pas.
Dans ce contexte, il faut donc s’interroger : pourquoi a-t-on besoin d’une phase de discovery, dans le monde de la tech ? La réponse devient évidente lorsqu’on étudie des cas extrêmes.
- Prenons un premier exemple : imaginez que vous n’ayez droit à AUCUNE itération. Vous pouvez sortir une nouvelle fonctionnalité, mais vous n’aurez pas la possibilité de la faire évoluer ensuite. Que feriez-vous dans ce cas ? Vous auriez tendance à opter pour une longue phase de discovery, afin de réduire au maximum le risque de commettre une erreur. Cette approche, que l’on appelle “waterfall” dans le jargon tech, fonctionne, mais elle est terriblement lente.
- Maintenant étudions ensemble l’exemple inverse : imaginez que vous ayez droit à TOUTES les itérations du monde, à une vitesse infinie. Dans ce cas, vous pourriez ignorer toute phase de discovery, et simplement tester chacune des variations possibles pour identifier la meilleure.
Or, la réalité de votre environnement quotidien est probablement quelque part entre les deux… Vous avez besoin de faire un peu de discovery. Combien ? Suffisamment pour écarter les risques les plus évidents. Ni trop ni trop peu — un peu comme la nitro(glycérine).
Vouloir faire de la discovery sans s’occuper du delivery, c’est un peu comme vouloir concevoir de nouvelles recettes sans vouloir mettre les pieds dans la cuisine.
Car, en réalité, c’est bien ça le rôle d’une phase de discovery : dérisquer l’impact de la phase de delivery. En fin de discovery, on n’obtient pas une certitude ou une preuve, mais une conviction ! Et c’est lors de la phase de delivery que cette conviction est confrontée à la réalité. Les résultats tombent, certaines hypothèses explosent en vol quand d’autres sont confirmées. L’apprentissage s’enclenche, permettant une nouvelle phase de discovery afin de corriger le tir là où c’est nécessaire. Mais on peut être tenté de vouloir repousser ad vitam eternam cette sentence du delivery. Renaud Vaillant, Chief Product Officer chez Pyxo, appelle ça “la sur-discovery, c’est-à-dire la tendance à vouloir toujours creuser plus (le problème et/ou la solution) au risque de ne plus prendre de décision et de ne rien tester en prod.”
Les personnes exerçant le métier de Product Manager/Designer depuis peu, ont tendance à largement surestimer leur capacité (ou celle de leur équipe) à obtenir un impact fort sur une métrique donnée. Leur optimisme excessif vient d’un trop faible nombre de boucles discovery-delivery. Donc sans delivery, pas de boucle d’apprentissage. Vouloir faire de la discovery sans s’occuper du delivery, c’est un peu comme vouloir concevoir de nouvelles recettes sans vouloir mettre les pieds dans la cuisine.
Mais alors, quand faut-il arrêter la phase de discovery pour basculer en delivery ? La réponse tient en une équation : quand le temps passé à réduire le risque multiplié par votre tolérance au risque est supérieur au temps qu’il faudrait pour livrer l’itération.
En d’autres termes :
- Plus le risque est faible, moins vous devez faire de discovery
- Plus votre tolérance au risque est élevée, moins vous devez faire de discovery
- Plus votre vitesse de delivery est élevée, moins vous devez faire de discovery
Pourquoi voit-on de plus en plus de gens tomber dans l’excès de discovery ? On peut supposer plusieurs causes : une croyance dans une data toute-puissante, un esprit cartésien espérant une réponse parfaite, une habitude prise avec un protocole que l’on connaît, un inconfort avec le fait de devoir défendre une opinion, une hiérarchie acceptant mal l’échec, etc.
Face au coût de la lenteur provoquée par cet écueil de sur-discovery, quelques organisations ont trouvé des solutions simples pour pallier la tentation de vouloir tout valider. Une approche intéressante est celle adoptée chez Strapi, dont l’équipe Produit a adopté la méthode décrite dans Discovery Discipline avant que le livre ne soit publié. Selon leur Chief Product Officer, Aurélien Georget, pour éviter de passer plus de temps que nécessaire en discovery, il faut définir à l'avance le type d'initiative à laquelle on a affaire :
- “Une initiative L, ça veut dire qu’on est à l’aveugle, donc on fait une discovery très poussée, on sort les lampes torches et on explore.
- Une initiative M, on fait un peu de discovery (environ 50% de l’effort par rapport à une initiative de taille L).
- Une initiative S, on va vite, très peu de discovery, c’est un problème connu et reconnu, on gratte la surface, pas besoin de réinventer la roue."
Ils ont même créé une mini-matrice avec quelques questions pour choisir si c’est une initiative S, M ou L.
On voit bien que la notion de prise de risque est au cœur de l’équilibre à trouver. Car c’est bien comme cela qu’il faut appréhender la phase de discovery, et non comme une procession religieuse où l’on doit suivre un rituel immuable auquel on ne déroge jamais.
Au-delà de la perte de temps, l’excès de rigidité dans la phase de discovery - “j’ai absolument besoin de trois mois à temps plein pour interviewer six personnes dans chacun des segments que j’explore” - conduit à une perte de crédibilité auprès de nos interlocuteurs clés. Ils ne comprennent pas ce dogmatisme où les prétendues bonnes pratiques semblent prendre le pas sur le bon sens. A vouloir trop en faire, on finit par ruiner la réputation de cette phase. Trop de discovery tue la discovery.
Il existe des dizaines de risques que l’on pourrait vouloir limiter : ne pas avoir l’impact business escompté, ne pas répondre à un besoin utilisateur, mal répondre à ce besoin, voir la bonne solution ignorée ou incomprise, etc. Or, ces risques ne sont pas liés entre eux. Vous pouvez avoir raison sur un point et vous tromper complètement sur un autre. Déminer chacun de ces risques ne se fait pas en appliquant à chaque fois le même protocole. C’est pour cela que la méthode FOCUSED, décrite dans Discovery Discipline, permet de réduire le travail de discovery à ce qui est strictement nécessaire.
En plus de la notion de taille d’initiative utilisée chez Strapi, on peut aussi accélérer sa phase de discovery en ciblant les points précis qui méritent d’être creusés. Les livrables font office de diagnostic (où sont les plus grands risques ?), tandis que les activités recommandées permettent de réduire les risques identifiés. Quand le livrable est clair pour tous les membres de l’équipe, c’est que le risque d’erreur est faible et qu’il n’est pas nécessaire d’y passer davantage de temps.
Soyons clairs : les phases de discovery méritent d’avoir un processus précis et répétable. Si la méthode FOCUSED a rencontré un écho dans la communauté, j’en suis ravi. En revanche, il n’a jamais été question de hiérarchiser la discovery comme quelque chose de supérieur au delivery. J’espère que nous allons collectivement continuer à grandir sur ce sujet, pour développer nos pratiques sans tomber dans le fanatisme aveugle.
