Séparer Delivery et Discovery : quel impact sur la maturité produit ?

Quand la Discovery du Product Owner allège la tâche du Product Manager

Quand il s’agit de Delivery et de Discovery, il y a souvent autant de manières de les définir qu’il y a de Product Managers et de Product Owners. Arnaud Iprex-Garcia chez Oyster explique : « Nous avons une relation directe entre le PM et le développeur chez nous, au sein d’une organisation qui combine à la fois PM et PO, car ce sont des personnes qui ont une contribution différente. Mais même avec un PO dans l’équipe, le PM est mis en relation directe régulière avec l’ingénieur ». 

Pour Oyster, le PM est garant de l’impact, et du fait d’arriver à destination. C’est lui qui engrange des éléments importants pour éclaircir le chemin vers la Delivery. Pour une entreprise qui, comme elle, a grandi rapidement, la présence en parallèle du PO apporte plus de fluidité et évite que les PM, en plus d’aller en profondeur dans la cherche, n’aient pas à gérer trop de projets transverses : « Nous travaillons sur un format de « triforce » : dev, PM et designer, à différents niveaux de l’organisation. Cette façon de procéder joue directement sur la répartition des tâches. » 

Dans le même temps, Arnaud admet qu’il s’agit avant tout d’une auto-organisation des équipes, laquelle se professionnalise de plus en plus, en améliorant en continu l’efficacité de la méthode.

Vélocité ou vision opérationnelle, à vous de choisir 

Chez Studapart, le contexte est différent et particulièrement véloce. Comme le détaille Raphaël Bonstein : « Les développeurs peuvent sortir un projet conçu par un PM en moins de 3 semaines après la fin des specs. Ils ont une véritable maitrise. Chez les techs, les features apparaissent vite, le feedback est rapide. Si bien que toutes les notions habituelles de Discovery et Delivery sont remises en cause ». Pour y parvenir, Studapart travaille avec deux PM et une squad de 2/3 développeurs maximum. Un process sportif, mais adapté au rythme de Delivery de la tech.

Une vitesse qu’Oyster n’a pas choisie. Cela s’explique par son statut d’entreprise très opérationnelle, qui s’appuie sur un principe : comprendre que chaque feature aura un impact sur les process pour la plupart des métiers. « Notre question est : qu’est-ce qui crée de la valeur ? En sortant du développement et en se reposant sur l’opérationnel, on crée un process même s’il n’est pas encore actif sur la plateforme ». 

La Discovery, une rampe de lancement

Raphaël Bonstein voit la Discovery comme une étape indispensable, que ce soit sur 3 mois ou sur 5 jours : « On doit avoir une expertise produit et montrer que l’on a la maitrise. Je pourrais résumer cela de cette façon : je m’engage et cela va créer le résultat attendu ». D’autant plus que la Discovery permet de gagner du temps au lieu, comme on pourrait le croire, d’en faire perdre à tous. Même chose pour Oyster : le défi de la Discovery, c’est d’être l’expert objectif de ton problème. Ce qui demande de regrouper les connaissances des acteurs et que tout le monde sache que tu es celui qui peut répondre ».

Lorsque, dans une entreprise, 200 personnes affirment que le problème se trouve à tel endroit, le PO doit le savoir en amont pour éviter qu’un PM vérifie cela en deux semaines pour arriver à la même conclusion : « Notre rôle est de supprimer la remise en cause perpétuelle sur des évidences » rappelle Raphaël. L’intérêt est aussi d’apporter le meilleur au PM : « C’est l’horloger : il a besoin d’un produit de qualité et fini à présenter ».

L’autre avantage se situe dans la manière qu’a l’entreprise de se démarquer : « Quand une idée survient, 10 entreprises ont souvent la même au même moment. La différence est d’abord esthétique et la Discovery permet de trouver le bon axe au service de la Delivery ». 

S’imprégner des réalités métier

Arnaud Iprex-Garcia chez Oyster souligne avant tout que le PM ne doit pas être au centre, mais se connecter à tous les enjeux métiers, « aussi bien légaux, sales, customer success, car plus on les connaît, plus on a de l’empathie, et moins on court de risques à avancer ». Dans les faits : « On n’a pas trouvé de meilleure solution que lancer une version sur Excel pour mettre en production sous 2 semaines. L’effet est immédiat sur les métiers qui se réveillent et enrichissent alors la Discovery, sans que l’on ait besoin d’attendre des retours ». 

Il s’agit aussi de répondre à un problème d’une autre manière : « Pour un souci sur une règle métier, on peut créer l’outil dans le back office qui va toutes les gérer. C’est dans ce genre de parti-pris que les PM brillent vraiment. »

Raphaël Bonstein abonde en son sens avec un conseil : « Votre entreprise vous paie pour créer de la valeur, générer du chiffre d’affaires ou de la connaissance ! »