Le piège de la delivery permanente

La plupart des équipes produit souffrent du même déséquilibre : trop de delivery, pas assez de discovery. Les sprints sont pleins, les développeurs ont toujours quelque chose à coder, les releases s'enchaînent. Et pourtant, 6 mois plus tard, les métriques stagnent. Pourquoi ? Parce qu'on a livré des fonctionnalités que personne ne demandait vraiment, ou qui ne résolvaient pas le problème qu'on pensait résoudre.

La discovery — comprendre les problèmes de vos utilisateurs avant de coder les solutions — est l'investissement le plus rentable en product management. Une semaine de discovery bien menée peut éviter 3 mois de développement dans la mauvaise direction.

Définir les deux modes

La Discovery

La discovery répond à la question "Que devons-nous construire et pourquoi ?". Elle inclut : les entretiens utilisateurs, l'analyse des feedbacks, les tests de prototypes, la recherche de marché, l'analyse concurrentielle. Son output : une compréhension claire des problèmes prioritaires et des hypothèses de solution validées.

La Delivery

La delivery répond à la question "Comment construisons-nous ce qu'on a décidé de construire ?". Elle inclut : les specs, le développement, les tests, le déploiement, la communication de release. Son output : des fonctionnalités dans les mains des utilisateurs.

Les modèles d'organisation

Le modèle "dual track"

Popularisé par Marty Cagan, le dual track fait coexister discovery et delivery en parallèle permanent. Pendant que l'équipe livre le sprint en cours, le PM prépare déjà le sprint d'après via la discovery. En pratique : le PM consacre 30 à 40 % de son temps à la discovery, le reste à la delivery.

Le modèle "discovery sprint"

Certaines équipes dédient 1 sprint sur 4 exclusivement à la discovery. Avantage : l'équipe entière peut participer. Inconvénient : la delivery s'arrête et ça crée une pression forte pour raccourcir la discovery.

Les signaux que votre équilibre est mauvais

Trop de delivery, pas assez de discovery : vous livrez mais les métriques ne bougent pas, les fonctionnalités sont peu utilisées, les développeurs commencent à questionner les priorités.

Trop de discovery, pas assez de delivery : vos utilisateurs se plaignent de ne rien voir sortir, vous accumulez des insights sans jamais tester de solution, l'équipe perd en motivation.

Les feedbacks comme liant entre discovery et delivery

Un bon système de feedbacks fait naturellement le lien entre les deux : les feedbacks alimentent la discovery (ils révèlent les problèmes), et la delivery génère de nouveaux feedbacks (les utilisateurs réagissent aux nouvelles fonctionnalités). C'est une boucle qui, bien gérée, s'auto-calibre.

Conclusion

Il n'y a pas de ratio universellement parfait entre discovery et delivery. Le bon ratio dépend de la maturité de votre produit (plus il est mature, plus vous pouvez vous permettre moins de discovery), de la taille de votre marché, et de la vélocité de vos concurrents. L'essentiel : ne jamais laisser la delivery étouffer la discovery complètement.