Organisation Projet vs Logique Produit : face aux idéologies, rester pragmatique et orienté résultats

Étienne Fénétrier est consultant senior au sein de la practice Product. Depuis un an chez Converteo, il a pu mener des missions de conception, de design et de développement de produits SaaS et Data pour des utilisateurs professionnels.

À retenir

• Plutôt que d’opposer en permanence ces deux logiques dans des approches théoriques, apprenons à concilier les deux avec pragmatisme
• On ne travaille jamais « By the book » et le vrai sujet du Product Management réside en l’adaptation de méthodes à des environnements spécifiques
• Poser les bonnes questions, briser les silos et intégrer toutes les parties prenantes dès le départ est un prérequis indispensable quelle que soit la méthode de développement

J’ai réalisé une mission géniale auprès d’un grand retailer qui a réussi pendant des années à se positionner comme leader sur son secteur. Son approche a été brillante et le virage du e-commerce plutôt bien négocié, tout comme l’avènement des marketplaces. Mais quand j’arrive sur place, je suis frappé par l’absence de culture Produit au sein des équipes que je vais côtoyer. Nous devons développer un SaaS BtoB de zéro, je suis censé en piloter la conception et le développement, et l’héritage des projets silotés et suivis sous le prisme « Budget / Planning / Qualité » est profondément ancré.

Ni le premier, et certainement pas le dernier à faire face à cette situation, je vous propose un retour d’expérience pour tenter d’associer le meilleur des deux mondes et atteindre vos objectifs.

Anticiper le gap entre Projet et Product au sein de l’organisation

Plutôt que d’imposer ses méthodes, frameworks et bonnes pratiques (et les Product people ont une tendance à être prolixes sur le sujet), il s’agit d’abord d’identifier son environnement. On ne change pas toutes les méthodos d’un coup ! Il faut s’appuyer sur les logiques projets qui fonctionnent et prioriser les modifications de process qui nous semblent essentielles pour mener à bien notre mission.

Voici quelques indices qui peuvent mettre la puce à l’oreille :

•       Le rôle de Proxy-PO qui correspond souvent au scope d’un Chef de projet digital
•       Des parties prenantes qui sont Chef de projet technique et Chef de projet métier
•       Un planning très précis partagé dès le kick-off avec de multiples jalons
•       Une phase de recette finale de 2 mois avant la mise en prod prévue de la V1
•       Un budget précis et détaillé sur deux ans
•       Un Excel avec une liste de plus de 50 fonctionnalités attendues…

Pas de doute, on se lance en mode Projet pour un produit qui va avoir vocation à évoluer dans le temps ! Prenons donc le meilleur de l’univers Projet, mais réajustons la méthode de conception pour limiter le risque de se planter en développant quelque chose qui ne sera pas adopté.

Prendre un pas de recul en posant les bonnes questions

Quand on arrive en tant que PO dans ce contexte, on est toujours gêné par une liste à la Prévert de fonctionnalités prédigérées. Plutôt que de se lancer tête baissée dans le développement, j’ai demandé à avoir une phase de cadrage un peu plus longue que prévu pour me faire une discovery en mode guérilla en un temps record. Trois objectifs ici :

•       Construire un template de vision Produit
•       Définir les KPIs de succès de ce produit
•       Aligner les parties prenantes autour de ces deux éléments clés

Pour cela, j’ai pu réaliser plusieurs interviews et ateliers. La logique projet m’a permis de très rapidement identifier les stakeholders (merci pour la matrice RACI). En enregistrant chaque échange et en réalisant des comptes-rendus détaillés, on a pu commencer à se focaliser sur de l’outcome et non sur de l’output. Pourquoi veut-on ce produit ? Qui sont les utilisateurs ? Quels objectifs ils cherchent à atteindre en l’utilisant ? Et surtout, comment mesurer le succès du produit en lui-même ?

Le planning, le budget et les fonctionnalités de base restaient centraux et suivis au regard du contexte de la mission. Mais on commençait à regarder un peu plus loin que la première mise en prod.

Casser les silos entre l’IT et le Métier (et ajouter du Design)

Ce n’est pas toujours simple mais ce pont est essentiel pour ne pas se retrouver à simplement récupérer des besoins et faire passe-plat… Les équipes doivent se parler même sans vous.

Surprise pour les équipes IT : nous allons incorporer des représentants métier dans les instances de grooming et de chiffrage pour qu’ils comprennent les enjeux techniques que vous allez résoudre.

Surprise pour les équipes métier : nous allons partager des informations issues du marché et des utilisateurs pour que les développeurs comprennent le « pourquoi » de ce qu’ils développent.

Surprise pour tous : j’ai besoin d’un UX designer pour mener des design sprints efficaces avec des représentants du métier et de la technique afin d’avancer rapidement et intelligemment sur la conception du produit (d’autant que les délais sont serrés).

La confiance du client était clé et je l’en remercie, nous avons pu incorporer dans l’équipe un designer particulièrement doué sur les sujets SaaS qui a su initier d’excellentes discussions techniques pour anticiper les pièges et gagner du temps par la suite.

Expliquer que l’agilité ne se résume pas à utiliser Jira

En mode projet, on a besoin de maîtriser les risques et anticiper un maximum. J’ai donc dû rédiger un backlog complet du produit avec plusieurs mois de développements anticipés et macro-chiffrés. J’entends déjà tous les Product managers râler… Mais, l’avantage, c’est que cela nous a permis d’anticiper un gros risque de retard et de discuter rapidement de recrutements supplémentaires au sein de l’équipe pour respecter le grand jalon de mise en prod fixé.

L’équilibre à trouver est de bien faire intégrer aux parties prenantes que certains éléments seront susceptibles d’évoluer. Nous nous sommes donc mis d’accord sur une priorisation type MoSCoW. On sécurise le Must, on définit le cadre du Should qui pourra évoluer au fur et à mesure, on envisage le Could en se laissant plus de liberté à l’avenir.

En parallèle, nous avons ajouté des recettes régulières de la part des équipes métier (pas de QA à disposition). La phase de design avait permis d’embarquer du monde sur le sujet, et cela nous permettait de garder le lien, réajuster certains éléments en cours de route et éviter l’effet tunnel.

Anticiper la vie du produit après sa première mise en production

Un des éléments qui m’a cruellement manqué tout au long de cette mission était l’absence de données fiables sur l’utilisation de l’ancien outil. Nous avons l’habitude d’être Data-driven dans toutes nos actions chez Converteo pour limiter les jugements sans fondement. J’ai pu compenser avec un peu de données issues de ma phase de discovery accélérée et de tests utilisateurs sur prototypes pour confirmer ou réajuster des choix de navigation.

Il était donc essentiel d’anticiper des outils de tracking pour notre première version. Malheureusement cela n’a pas été priorisé par crainte de devoir rentrer dans des discussions de compliance complexes pour un outil destiné aux internes et aux fournisseurs. Si je suis parti avant de voir la mise en production de ce beau bébé, j’espère profondément que les graines semées quant à cette nécessité de data fiables sur l’utilisation du produit porteront leurs fruits.

En posant les bonnes questions, en brisant les silos, et en intégrant toutes les parties prenantes dès les premières étapes, on peut transformer une logique Projet pour faire un peu de place à une vision Produit plus pérenne. J’espère que ces réflexions vous aideront à aborder vos futures missions, en tant que client ou consultant, avec un regard neuf et une approche pragmatique. Je suis curieux d’avoir d’autres retours d’expérience sur le sujet !