“Le Time To Market est trop long”, “Nous n’avons aucune idée du bénéfice apporté par ce projet”, “On commence plein de choses et on ne termine rien”...
Voilà des phrases que nous entendons tous les jours et qui font dire à toutes les entreprises impliquées dans la révolution digitale qu’il faut remettre en cause le paradigme projet.
L’enjeu de ces entreprises n’est plus le respect du fameux triangle périmètre-coût-délai mais bien d’optimiser l’impact business à long terme.
Que devient la traditionnelle date de fin de projet lorsque l’équipe commence à mettre en service rapidement de premières versions du produit qui seront complétées par les retours fréquents des utilisateurs ?
Nous devons alors changer de lunettes, passer du paradigme projet au paradigme produit pour s’assurer d’avoir le maximum d’impact sur le long terme, promouvoir une innovation efficace tout en “dé-silotant” l’entreprise.
Ce changement de paradigme couvre 4 grands domaines :
Du point de vue d’un gestionnaire de projet, cela revient à :
Cela commence toujours par la mise en place d’une équipe Agile de 5 à 8 personnes, pluri-disciplinaire, durable et dédiée à un produit.
L’équipe met rapidement en place des moyens pour obtenir du feedback des utilisateurs : data, analytics, tests utilisateurs, immersions, observations…
Afin de gérer efficacement le build et le run, l’équipe va rapidement développer une stratégie sur la qualité logicielle afin de limiter l’impact des bugs : pyramide des tests en place, création de dette technique sous contrôle, tests automatisés et bugs priorisés.
La budgétisation d’une telle équipe devient glissante (en général sur 3 mois) afin de fréquemment se poser la question du “arrêter / continuer” en fonction du retour sur investissement espéré.
De fait, la roadmap devient dynamique tout comme la stratégie produit qui se base avant tout sur des hypothèses plutôt que des opinions.
La clé de voûte du mode produit est le Product Owner de l’équipe qui doit être capable de décisions rapides sur le produit mais aussi d’une bonne capacité à communiquer et challenger (avec l’aide de spécialistes de l’expérience utilisateurs) les besoins des clients et des parties prenantes de l’entreprise.
Une session de tests utilisateurs (source : usability.de)
Avoir des contacts directs avec les utilisateurs est souvent difficile à obtenir par des équipes IT, bloquées par le marketing, les commerciaux ou les partenaires. Dans ce cas, vous pouvez utiliser un cheval de troie : partir d’une demande client urgente où il sera légitime de rencontrer le client directement, puis en profiter pour étendre la discussion sur d’autres sujets qui vous intéressent et demander au client de nouveaux contacts d’utilisateurs.
Le meilleur contre-exemple est Google Music, une application qui aurait pu être un simple copier / coller de Deezer ou Spotify et qui a réussi progressivement à devenir un référent dans la recommandation musicale tout en négligeant certaines fonctionnalités de ses concurrents. Donc oui, l’approche produit est une perte de temps si vous souhaitez simplement vous mettre à niveau de la concurrence - mais cette situation est généralement le signe d’un retard difficile à rattraper, ce que l’approche produit pourrait transformer en opportunité !
Être piloté par les retours utilisateurs ne veut pas dire être piloté par les utilisateurs !
Exemple : Pour une solution de partage de fichiers en cours de refonte, des clients importants demandaient à converser à tout prix une gestion de profil iso-fonctionnelle de la version précédente. Après des entretiens sur les besoins, le Product Owner a proposé une refonte de la gestion de profil plus simple pour les utilisateurs ... et les développeurs.
Les remarques des clients ne sont que inputs. Il faut remonter aux besoins profonds du client au-delà de la solution qu’il pousse spontanément,, par exemple avec la méthode des “5 pourquois”. Il reste ensuite évaluer leur pertinence par rapport à votre vision produit. Vous pourrez alors vous focaliser sur l’important sans être esclave de l’urgent.
un exemple d’analyse de 5 pourquoi :
C’est effectivement un grand changement d’état d’esprit et dont l’impact est beaucoup plus interne à l’entreprise qu’externe. La plupart des clients d’aujourd’hui sont habitués à des produits incomplets et c’est une tendance qui va se renforcer de plus en plus. Le problème vient souvent des objectifs donnés aux salariés, plus fréquemment associés à de la réalisation de solutions abouties qu’à de la valeur créée pour les utilisateurs.
En cas de refonte d’une solution existante, la facilité est effectivement de reproduire le périmètre fonctionnel à l’identique sans se poser de questions mais ce serait passer à côté de l’opportunité de faire moins, plus vite et de meilleur qualité en supprimant tout le périmètre qui n’apporte pas de valeur (règle des 80/20).
Non : le mode projet peut rester pertinent, notamment quand l’environnement est prédictible : il n’y a pas de débat sur le problème, le bénéfice et la solution.
Le mode projet peut être réalisé :
Comme vu dans le point précédent, il continuera à y avoir des projets, donc des besoins de chefs de projet. Cependant, il y en aura sûrement moins. Un repositionnement d’une grande partie des chefs de projets est nécessaire, souvent dans l’un de ces 3 rôles selon le profil de la personne :
Passer en mode produit n’est pas qu’une simple réorganisation de l’IT ou R&D, c’est un changement de culture qui implique toute l’entreprise (direction, RH, marketing, commerce, finances, métier…).
Même si nous recommandons de commencer progressivement par des expérimentations pilotes, il s’agit à terme d’une transformation d'entreprise qui exige dès le départ un sponsorship fort au niveau de la Direction Générale.
“Je passe beaucoup de temps avec le Product Owner pour lui expliquer l’importance de la communication avec les parties prenantes car souvent les entreprises ont peur de ce nouveau rôle qu’ils imaginent être un chef produit omnipotent. Mon truc, c’est de faire venir ces parties prenantes dans l’équipe pour qu’ils constatent de visu que celui qui décide dans une équipe produit, c’est l’utilisateur avant tout !” (Basile)
“J’aime demander aux dirigeants de raconter des gros échecs projets ; il y en a toujours et ils ont traumatisé l’entreprise ! Je m’appuie sur ces “blessures” et leur cri du coeur “plus jamais ça !” pour les inciter à expérimenter une autre façon de faire.” (Dominique)
“Une équipe produit doit être capable de mettre en production par elle-même, sans contraintes externes, rapidement et fréquemment. Pour cela, je consacre toujours les premiers jours (ou semaines) de l’équipe produit à valider cette capacité en faisant l’exercice de déploiement complet d’une pseudo-fonctionnalité (par exemple une page “Hello World”). Rien de pire qu’une équipe produit incapable de déployer son code, elle perd tout son sens” (Basile)
Voilà une question à la fois simple et compliquée. D’un côté on aimerait dire que c’est la même chose et qu’il n’y a pas de différence et de l’autre on constate que le premier est tourné vers l’équipe et le delivery et que l’autre est tourné vers les utilisateurs et la stratégie… mais quelle est la bonne réponse ? On ne sait pas encore !
Il s’agit du principal frein culturel que nous ayons rencontré dans la diffusion du mode produit. Alors que la méthode présuppose la possibilité d’invalider les idées par des petites expérimentations, la culture hiérarchique empêche les Product Owners / Product Managers de challenger une fausse bonne idée d’un dirigeant parfois intimidant.
Voici nos pistes de solutions :
Dans la perception des utilisateurs, l’expérience produit dépasse largement le cadre de la simple application informatique. Elle inclut l’expérience utilisateur avec le marketing, le commerce, la livraison, le support, ...Nous nous demandons encore comment inclure ces compétences. Comment les impliquer vraiment dans le développement alors qu’ils sont monopolisés sur de multiples sujets ? Voire, peut-on les inclure comme membres dédiés dans les équipes pluridisciplinaires? Ceci implique de décomposer l’entreprise en mini-PME autour d’offres d’expérience client...
“Donner des objectifs dans le cadre d’entretiens annuels à quelqu’un qui travaille dans une équipe produit n’a pas de sens, il faut le voir plus fréquemment et lui donner des objectifs non plus en lien avec le périmètre à réaliser mais avec la valeur à produire, c’est un nouveau challenge !” (Manager DSI Commerce)
“Je comprends que je ne dois plus demander des solutions à l’équipe sans contexte, mais exprimer mes besoins sous forme de questions et d’hypothèses afin de les laisser me proposer la meilleure solution.” (Responsable Marketing)
“Pour la première fois depuis que je travaille ici, je comprends ce que je fais pour le client” (Développeur équipe produit)
“Je trouve que la communication est meilleure, et que les gens se sentent plus impliqués.” (Développeur - équipe produit pilote)
“Je me rends compte que les livraisons fréquentes ont grandement amélioré la confiance des clients en l’équipe et ce malgré l’absence d’engagement sur un périmètre précis.” (Responsable métier)
Le framework Cynefin (Complexité) Le petit-déjeuner OCTO passer du mode Projet au mode Produit Développer la culture produit Mon processus de design en tant que Product Owner sans UX designer La feature team au-delà du buzzword