📚 Ce que je retiens de ... Continous Discovery Habits de Teresa Torres
[Hors-série | The Tech Away]
Quand je ne fais pas de veille sur les internets, je fais ma veille dans des livres : je lis des livres qui m’aident à progresser dans mon métier de concepteur de systèmes.
Il y a quelques temps, j’ai lu Continous Discovery Habits de Teresa Torres qui possède une newsletter sur Substack que je recommande (#ProductTalkDaily). J’ai appris plein de choses utiles que j’avais envie de partager quelque part, alors pourquoi ne pas le faire ici. Ce format sera différent de ce que vous lisez ici d’habitude (d’où la mention de hors-série). Toutes les illustrations de cet article proviennent du site producttalk.org et sont la propriété de Teresa Torres.
ℹ️ Je me permettrai tout au long de ce billet de créer des connexions avec d’autres éléments de littérature auxquels ce livre m’a fait penser.
📘 Mon rapport à ce livre
☕️ J’ai découvert ce livre cet été, sur une recommandation d’un collègue chez OCTO, Bruno Boucard, alors que nous discutions autour d’un café des liens qui peuvent exister entre Domain-Driven Design et (Product) Discovery.
Je me suis intéressé plus en détails à ce livre pour monter en compétence sur ce dernier sujet, pour les besoins d’un projet où j’allais endosser pour la première fois officiellement la casquette de “(Technical) Product Owner” dans une équipe plateforme.
🔎 C’est quoi le discovery ?
Teresa Torres décrit le discovery comme
L’ensemble des activités qu’une organisation peut réaliser afin de décider de ce qu’il faut développer.
C’est une activité différente du delivery, qui m’est plus familier, et qui regroupe les activités qui suivent cette prise de décision : le développement de l’application, son build, son déploiement, … 🚀
∞ Pour mériter de préfixer cette activité de discovery du très convoité “continuous”, il faut pratiquer des activités de discovery au contact d’utilisateurs plusieurs fois par semaine au moins, au point au cela devient une routine, une habitude comme le suggère le titre.
🙋 Qui fait du discovery ?
It’s important that the product trio be a part of the team responsible for building the product. It’s not separate from the delivery team. — Source
Je partage une conviction avec l’autrice : le discovery ne devrait pas être la chasse gardée d’un unique membre de l’équipe mais une responsabilité partagée par un groupe divers, pluridisciplinaire. Dans le livre, un tel groupe est appelé un product trio et est composé :
d’un product manager,
d’un designer,
d’un ingénieur.
💡 En tant que développeur, le fait de s’intéresser à la pratique du discovery m’évoque le concept de Product-Minded Engineer, qui je pense a été posé par Gergely Orosz dans cet article de blog : The Product-Minded Software Engineer.
Je recommande au passage sa newsletter et ses podcasts si vous ne les connaissez pas.
C’est vraiment très très bien.
📝 Comment ces acteurs collaborent ?
Ce livre présente de nombreux outils de modélisation et de collaboration, comme l’experience map que je connaissais déjà, mais voici 2 outils que j’ai découvert et que j’ai pu essayer sur le terrain, avec un board Miro (malheureusement seul, n’ayant pas de product trio sous la main à cette époque) :
L’interview snapshot : un document d’une page dont la structure permet de capturer l’essentiel d’une interview utilisateur. On y saisi le nom de l’interviewé, son rôle, un (ou des) verbatim mémorable entendu pendant l’interview, les opportunités décelées lors de l’échange, et bien d’autres choses encore.
L’opportunity-solution tree : un outil qui permet de modéliser
l’objectif que l’organisation souhaite réaliser,
les opportunités découvertes lors d’activités de discovery,
les solutions imaginées pour saisir ces opportunités
mais aussi des expérimentations qui peuvent être réalisées pour réduire les risques liés à ces solutions et décider, ou non, de réaliser plus tard leur delivery.
💡 Ce dernier outil est un moyen de cartographier notre exploration de l’espace des opportunités (que les pratiquants de DDD pourraient appeler l’espace du problème, même si l’autrice marque des différences claires, un désir utilisateur n’étant pas nécessaire un “problème”) et l’exploration de l’espace des solutions.
🧪 A quoi ça sert d’expérimenter une solution ? On peut pas juste rajouter cette “solution” au backlog des dév ?
Amener une solution en production est une manière d’obtenir un feedback certain sur celle-ci. Mais le delivery est un outil coûteux pour tester des hypothèses, et nous n’avons pas tous le luxe de nous permettre de développer une solution pendant des semaines (ou plus, pour ceux qui n’ont pas la chance d’être classé top performer selon la classification du DORA) pour finalement nous rendre compte que ce n’était pas ce que nos utilisateurs attendaient et se contenter des apprentissages de cet échec.
Teresa Torres présente 5 catégories d’hypothèses intéressantes à (in)valider avant d’envisager le delivery d’une solution candidate. Elles sont inspirées des 4 big risks énoncés par Marty Cagan dans INSPIRED.
Hypothèses de désirabilité : penser que des utilisateurs voudront de la solution (juste parce qu’on y a pensé)
Hypothèses de viabilité : penser que la solution créera de la valeur
(ça m’évoque la notion de classification stratégique “revenue generator” du Bounded-Context Canvas, dans le DDD)
Hypothèses de faisabilité : penser que nous sommes capable de construire la solution
Hypothèses d’utilisabilité : penser que les utilisateurs comprendront ce que nous attendons d’eux, quand ils seront face à la solution
Hypothèses d’ordre éthique : penser que la solution ne causera de mal à aucun utilisateur
Le livre présente des techniques d’expérimentation/simulation pour tester plusieurs hypothèses de façon time-boxée, plusieurs fois par semaines.
Ca m’évoque des outils que j’utilise fréquemment dans mes projets de delivery comme les spikes ou l’experiment canvas, qui peut se décliner en fiches de spikes versionables dans le code, au format Markdown.
Conclusion
Le livre couvre encore de nombreux sujets, outils, retours d’expérience et conseils, mais je préfère m’arrêter ici.
J’espère que ça vous donnera envie de vous intéresser au discovery pour faire des produits qui marchent™️ ou de lire le livre de Teresa Torres, que j’ai trouvé très accessible pour le technicien que je suis.
J’ai besoin de votre feedback : si ça vous a plu, n’hésitez pas à me le dire, pour que je sache si mes lectures et ce format vous intéresse ou non :)