Le monde des nouvelles technologies est un monde fascinant qui évolue à une vitesse fulgurante. En 2010, en Master d’e-Business à l’Institut Supérieur du Commerce, on m’avait enseigné que la gestion d’un projet nécessitait l’application du Cycle en V, une méthodologie rendue obsolète par Scrum et le Product Management
Il s’agit d’un framework de gestion de projet suivant un processus rigoureux dont les étapes sont les suivantes :
Durant quatre années, j’ai appliqué ce modèle en agences digitales pour de grands comptes. Je travaillais sur des projets dont la moindre action devait être pensée et spécifiée pour être mise en place. Une demande non spécifiée aussi pertinente soit-elle ne pouvait être prise en compte à moins de rompre le triptyque “Coût – Qualité – Délai”.
C’est un modèle efficace dans des environnements de projets figés mais qui ne correspondait pas à la réalité opérationnelle à laquelle je faisais face. La réalité d’un projet demande de la flexibilité.
“No battle plan ever survived first contact with the enemy.”
Helmuth van Moltke
Face à ce constat, je me suis donc naturellement tourné vers le Product Management.
A l’inverse du Cycle en V, l’objectif de Scrum est de développer de petites itérations régulières pour tester et corriger le produit avec l’utilisateur.
J’y ai vu l’opportunité de co-construire avec toutes les parties prenantes, un produit centré sur les besoins réels de l’utilisateur tout en réduisant le time to market.
Les valeurs du manifeste agile listées ci-dessous vont dans ce sens en mettant en avant une collaboration des intervenants de la conception d’un produit :
- Les individus et leurs interactions plus que les processus et les outils
- Des logiciels opérationnels plus qu’une documentation exhaustive
- La collaboration avec les clients plus que la négociation contractuelle
- L’adaptation au changement plus que le suivi d’un plan
Ces valeurs sont centrales mais si elles ne sont pas respectées, la mission du Product Manager se trouve fortement affectée.
Les pièges du product management
Même si de nombreuses entreprises en cours de “transformation digitale” appliquent correctement la méthode, le respect des valeurs agiles quant à lui est plus délicat. En effet, il s’agit d’une transformation culturelle profonde allant bien souvent à l’encontre de leur ADN.
J’ai pu observer au cours de certaines missions des limites à l’application de l’agilité.
1. Appliquer la méthode sans respecter les valeurs fondatrices
Le premier écueil est d’appliquer une méthode centrée sur les besoins utilisateurs dans un cadre pyramidal. Deux visions entrent en collision.
Dans des organisations à l’héritage industriel Top-Down, la roadmap produit est imposée.
Quand bien même la vision produit ne dessert pas les besoins du client, la roadmap est rigoureusement appliquée.
“A customer can have a car painted any color he wants as long as it’s black.”
Henry Ford
Même si les rituels agiles sont appliqués, le Product Manager se retrouve à porter la casquette de Chef de Projet Maîtrise d’Ouvrage perdant le contrôle du produit.
Dans un tel contexte, la négociation contractuelle prend le dessus sur la collaboration, le respect du plan prévaut sur le changement et les processus sont imposés.
Ça vous rappelle quelque chose?
2. Implémenter des solutions à l’impact incertain
Le rôle du Product Management est de maximiser la valeur du produit avec une contrainte de ressources limitées. Sa responsabilité est d’identifier auprès des utilisateurs finaux les fonctionnalités les plus impactantes et d’écarter le “superflu”.
“Pick battles big enough to matter, small enough to win.”
Jonathan Kozol
Se lancer dans le développement de solutions qui ne répondent pas à un problème utilisateur, c’est créer la frustration d’engager ses forces dans des batailles inutiles. C’est malheureusement souvent le cas lorsque la roadmap est imposée.
Un Product Manager se doit de valider le besoin en testant les hypothèses de marché.
Il doit mesurer le coût et l’utilité des fonctionnalités. Ainsi il sera en mesure de prendre des décisions éclairées sur l’orientation du travail des équipes.
Un Product Manager n’est pas seulement un chef de projet focalisé sur l’exécution mais un véritable CEO qui oriente le Produit, il est autonome et obsédé par le ROI.
3. Le culte du lancement de produit parfait
“If you are not embarrassed by the first version of your product, you’ve launched too late.”
Reid Hoffman
Le dernier écueil est le plus pardonnable et paradoxalement le plus coûteux. Si vous êtes atteints du syndrome du bon élève, vous êtes également déjà tombés dans ce piège.
Quand bien même vous avez testé votre marché au préalable, vous ne répondrez pas parfaitement aux besoins des utilisateurs du premier coup. Il est même très probable que vos hypothèses soient infirmées.
Le Product Management nécessite une grande humilité. Il faut être en mesure d’accepter qu’il y aura toujours un écart entre les hypothèses formulées et la dure réalité du marché.
La première version du produit a pour but de valider les hypothèses de résolution d’un problème.
De cet enseignement on comprend les usages et on améliore le produit ou on prend la décision courageuse de pivoter.
Plus la confrontation au marché est rapide et plus vite on obtient la réponse à la question :
« Est-ce que je résous un problème? ».
Il faut accepter l’idée de soumettre un produit qu’on sait imparfait pour en tirer des enseignements vitaux. L’écueil classique est de s’enliser dans un piège abscons. Il est très tentant de parfaire une première version en sur-investissant dans un produit qui demeure théorique.
My 2 cents
Les écueils cités précédemment sont le fruit d’organisations verticales basées sur le contrôle et la prédiction. Est-ce qu’un tel contrôle se prête à la conception de produits en méthodes agiles?
La réponse est non, car créer un produit basé sur les besoins des utilisateurs nécessitent de nombreuses itérations et des hypothèses difficilement prédictibles.
Nous l’avons vu précédemment, si l’équipe Produit est dépossédée de son leadership et se place comme exécutants, il est fort probable qu’elle produise des fonctionnalités répondant à la vision biaisée de donneur d’ordres. Afin de permettre au Product Management d’exploiter son plein potentiel, les OKR (Objectives Key Results) constituent une réponse appropriée.
La méthodologie OKR permet de définir des objectifs et de mesurer leur accomplissement, le tout sur une période donnée. Ci-dessous une illustration fictive.
Objectif : Augmenter le Revenu Récurrent Annuel (ARR)
Résultats clés :
1. Augmenter le trafic provenant de Google de 15%.
2. Augmenter la conversion de 10%.
Cette méthodologie change radicalement l’approche. La conception de Produit a désormais comme point de départ un objectif et non plus une solution. Elle offre l’autonomie nécessaire à la conception du produit ainsi qu’un engagement et un alignement de toutes les équipes vers un objectif commun.
D’après vous agilité et OKR font-ils bon ménage?
Pour en savoir plus :
Méthode OKR : comment motiver ses équipes autour d’un objectif commun ?