La majorité des équipes produit que j'accompagne tombent dans l'un des deux pièges : tout discovery, jamais de delivery (on apprend mais on ne livre rien), ou tout delivery, jamais de discovery (on livre vite, mais à côté du problème).
Définitions courtes
- Discovery : comprendre le problème, les utilisateurs, et valider qu'une solution vaut la peine d'être construite.
- Delivery : construire, livrer, mesurer.
Les deux ne sont pas séquentiels. Dans une équipe mature, ils tournent en parallèle, sur des cycles différents.
La règle des 15 %
Dans une équipe early-stage, je recommande de réserver 15 % du temps de chaque sprint à la discovery — interviews, prototypes, tests d'usabilité. Pas plus au début : ça doit rester un muscle léger, pas un département.
Cette règle évite les deux dérives :
- L'équipe ne peut pas se cacher derrière la "phase de discovery éternelle".
- L'équipe ne peut pas non plus dire "on n'a pas le temps, on livre".
Trois questions à se poser chaque semaine
- Quel problème utilisateur on a appris cette semaine ? (Discovery)
- Qu'est-ce qu'on a mis entre les mains des utilisateurs cette semaine ? (Delivery)
- Est-ce qu'on mesure l'impact de ce qu'on a livré ? (Boucle)
Si les trois réponses sont vides, l'équipe tourne à vide.
Comment démarrer demain
- Bloque 1 h dans le calendrier de l'équipe : "Discovery weekly".
- Choisis un seul problème utilisateur à explorer.
- Programme 3 interviews dans la semaine.
- À la fin du sprint, partage ce qui a été appris — même si c'est "on s'est trompés".
Le but n'est pas de tout savoir avant de livrer, c'est de livrer en sachant pourquoi.