AstroPO, AstroDev, ou tout simplement AstroPassionnés par l’agilité se sont donné rendez-vous sur les bancs de l'école ce mercredi 13 janvier pour assister à la School of PO !
Cette conférence, c'est the place to be pour découvrir, échanger et mettre en pratique de nouvelles techniques pour mieux s’organiser, cadrer, définir les tenants et aboutissants d’un produit ou faire face à des situations d’échecs.
L’ouverture de la School of PO s’est faite sur un premier talk : Maximum Impact, minimum effort par Gojko Adzic, un peu le papa de l’Impact Mapping.
Il ouvre sa conférence sur un constat assez triste : un milliard de dollars sont perdus dans des échecs de projets IT tous les ans.
Quelles ont été les erreurs commises dans la gestion de ces projets ? Qui ont peut-être même fait couler de nombreuses sociétés ? Quelles solutions existent pour éviter de les reproduire ?
Il est important de prendre conscience que certaines idées préconçues dans la gestion de projet agile sont fausses. Et peuvent mettre en péril un projet ou un produit. L’agilité est une méthodologie qui s’applique de manière réfléchie, adaptative et plurilatérale.
Un fonctionnement entre 2 équipes agiles ne sera pas le même, que ce soit dans le déroulé des différentes cérémonies agiles ou dans l’objectif donné à chaque itération jusqu’à la livraison finale.
Gojko Adzic a fait ici état de trois “grandes” illusions, qui peuvent être communes à tout projet si les parties prenantes au bon développement du produit ne sont pas attentives.
Il faut donc garder en vue que chaque itération doit apporter une valeur métier, une valeur à l’utilisateur final. Et non par exemple une valeur technique, si derrière elle ne peut être traduite en valeur métier.
C’est le meilleur moyen de perdre de vue l’intérêt et l’utilité d’un produit pour son utilisateur.
Je pense que chaque personne, PO, PM ou chef de projet s’est déjà retrouvé dans ce contexte où un membre de la direction impose son choix comme étant la clé stratégique à une problématique, ou l’idée du siècle dont voudra forcément l’utilisateur final de son produit.
Or, il s’agit dans la majeure partie des cas seulement de suppositions, sans aucun indicateur permettant de justifier ce choix.
Gojko fait d’ailleurs un petit clin d’oeil à Microsoft, où seulement la moitié de ce qui est produit améliorerait réellement l’expérience de leurs utilisateurs.
Certaines variables sont imprédictibles, et ne permettent pas de viser toujours juste lorsque l’on décide du développement d’une feature ou même d’un produit dans sa globalité.
D'abord, la variable localisation, qui va parfois limiter l’intérêt à certains groupes d'utilisateurs.
Ensuite, la variable du temps qui peut rendre obsolète le produit (un autre service qui a vu le jour, ou le fait que ce ne soit plus dans les tendances du marché).
Ou encore la variable humaine, qui rend la perception très subjective et qui va faire connaître son avis à son entourage.
Avoir plusieurs idées de features est devenu essentiel et ces variations permettent de s’adapter en cours de route.
C’est de ce principe que nait l’équation : “Variation + Survavibility + Selection”, déterminante pour décider de ce qui doit être gardé et de ce qui doit être abandonné dans son projet.
Ce qui est beau en théorie. Mais en pratique, la question se pose assez rapidement : à quel moment doit on arriver à identifier si une user story est bonne ou sans valeur ?
Grand sujet de son prochain livre sur l’Impact Mapping, Gojko Adzic essaye de lister des conseils applicables en fonction de différents contextes projets. En voici quatre :
1/ Dans le cas d’un contexte projet centré autour de la production de livraisons
engager les différents acteurs du projet à écrire chacun à leur niveau leur objectif des prochaines livraisons
créer un tableau avec ces différents objectifs
2/ Dans le cas d’un contexte projet centré autour du recadrage d’un problème
se concentrer sur les impacts des problèmes rencontrés, non sur les acteurs
laisser les acteurs émergés d’eux mêmes pour répondre aux problèmes
3/ Dans le cas d’un contexte projet où la vision est biaisée par des solutions déjà définies
4/ Dans le cas d’un contexte projet basé sur un changement de business
Si vous souhaitez apporter votre pierre à l’édifice, Gojko Adzic est toujours en demande de nouveaux cas d’école afin de pouvoir répondre de la manière la plus exhaustive possible aux différents contextes, et donc de nouveaux conseils à proposer dans son nouveau livre.
Le deuxième talk, présenté par Amélia Matar, founder de @COLORIeducation , nous parle de la pédagogie Montessori dédiée à l’enfant, et de ses parallèles avec le métier de product manager et de product owner.
Après une présentation de la vie de Maria Montessori, meilleure PO du monde pour notre intervenante, et de tout ce qu’elle a pu apporter à l’éducation dès la petite enfance, 4 grands principes ressortent :
La répétition a une importance cruciale dans l’apprentissage
Laisser son libre arbitre à une personne permet de le responsabiliser
Il n’est pas nécessaire d’instaurer un système de punitions et de récompenses pour donner de la motivation quand on propose une activité intéressante et enrichissante
Un enfant, comme tout être humain, peut se concentrer pendant plusieurs heures sur une problématique si elle est stimulante
Amélia nous a ensuite proposé une liste de sept qualités chez Maria Montessori qu’elle rattache à nos métiers de PM ou de PO sur des projets informatiques :
Olaf Lewitz, troisième intervenant de cette matinée uniquement dédiée aux talks, nous présente son sujet de la journée : être bien intentionné ne permet pas de bien faire, pourtant vouloir s’améliorer et se démarquer se fait avec intention.
Son idée à travers l’agile et l’impact mapping est de pouvoir s’améliorer à se démarquer avec les bonnes intentions.
Ces bonnes intentions se traduisent notamment par le fait d’avoir une vision stratégique sur l’engagement, la motivation, et la perte de temps, et de ne jamais faire quoi que ce soit sans en avoir mesuré l'impact.
Olaf nous a proposé un planning avec 3 plages d’horizon différentes : semaine prochaine, dans 3 mois et dans 6 mois.
Pour chaque production à entreprendre dans un projet, posons-nous la question des résultats attendus à 1 semaine après la mise en production / diffusion / [ajouter ici l’action souhaitée contextuellement à votre projet], 3 mois et 6 mois après.
Par exemple, la production à réaliser pourrait être l’écriture d’un REX sur la School of PO. Le résultat attendu pourrait être une semaine après d’avoir l’avis de trois personnes ayant lu mon article.
Après 3 mois, le résultat attendu pourrait être d’avoir 100 000 retweets sur Twitter de mon article (ce rêve bleu).
Après 6 mois, le résultat attendu pourrait être d’être invitée à animer une conférence grâce au succès de l’article.
Un autre exemple, au contraire, pourrait être de partager une anecdote avec 3 personnes, dans 3 mois d’estimer à seulement 25 personnes le partage de cette anecdote, et donc le résultat prévisionnel attendu à 6 mois pourrait être d’avoir abandonné le projet à la vue de la perte provoquée.
La limite de la proposition qu’il faut, je pense, ne pas oublier, est que chaque mesure est basée sur des hypothèses. Et cela peut laisser un grand flou.
Cependant, là où je trouve cette technique intéressante est de pouvoir l’introduire en début de réunion, et de l’appliquer sur les différentes propositions de chaque membre de l’équipe, avec des résultats attendus à court, moyen et plus long terme.
Quelles différences les échanges et décisions vont avoir ? Cela ne poussera-t-il pas tout le monde à garder à l’esprit un objectif chiffrable, et donc mesurable, à chaque développement d’une nouvelle feature, la mise en place d’un nouveau process d’équipe, ou encore d’une action à mener ?
Cela permettra certainement de pouvoir identifier avec plus de précision les idées ayant une valeur métier, et très probablement celles prsentant un intérêt à plus long terme, tout en mettant de côté les “propositions subjectives de la direction”.
Oussama Ammar, un des fondateurs de l’incubateur TheFamily a clôturé cette matinée par un vrai one man show.
Sans aucun support pour appuyer son discours, et en captant par son discours et sa présence sur scène toute l’audience, il a introduit la notion de “Vanity Metrics” comme le meilleur moyen de représenter son business de façon arbitraire.
Est-ce pour autant une mauvaise chose ? Pas vraiment ! Explications.
L’avantage de ces Vanity Metrics est justement qu’elles permettent de mettre en avant ce que l’on souhaite, même s’il ne s’agit pas de metrics réellement engageantes vis-à-vis de son service ou d’un produit. Ce qui en fait toute son utilité en terme de business. En France et en Allemagne, il est plus important pour le commun des personnes d’avoir raison que de gagner.
Nous avons tendance à croire que tout le monde dit la vérité et s’intéresse à ce qu’on leur raconte, et c’est faux. Comme Dr. House aimait si bien nous le démontrer dans sa série éponyme : “Everybody lies”.
Par exemple, en France, nous sommes connus pour être le peuple qui soit disant aime le plus le cinéma d’art et d’essai. Hors dans les faits, nous sommes bien le peuple qui en regardons le moins.
Ce qui n’est pas du tout le cas aux Etats-Unis, où le vice de la Vanity Metrics permet a bien des entrepreneurs de réussir à se lancer en mettant en avant ce que les incubateurs ou utilisateurs veulent entendre.
Étudier ces “Vanity Metrics” permet parfois de comprendre ce que nos utilisateurs ne nous disent pas. Pour cela aussi, elles peuvent intéressantes.
Netflix, par exemple, avait intégré à l’époque à son portail un système de notation. Ces notes ne venaient pas alimenter un scoring pour une série, un épisode ou encore un film, mais un scoring de recommandation permettant au service de vous proposer des contenus en fonction.
Cependant, Netflix s’est rendu compte après un certain temps d’utilisation de cette fonctionnalité et en comparant les notes données aux autres contenus visualisés par leurs utilisateurs que ce n’était pas lié. Car au final, par exemple, un adulte appréciant beaucoup les mangas ou les films d’animation par pudeur ne l’indiquera pas forcément. Alors qu’il indiquera toujours aimer les contenus à fort succès dont tout le monde parle. Ce biais fausse totalement les contenus essentiels à recommander pour garder son utilisateur actif.
Il faut donc avoir conscience de ses metrics réels, qui sont la plus value de son service, produit. Et garder conscience de ses Vanity Metrics qui peuvent aussi bien être un atout business que comportemental.
Christopher Parola, Lead Product Manager chez MeilleursAgents (un site de mise en relation de vendeurs et d’agents immobiliers, 2 partis qui se détestent littéralement) pose les bases de la problématique à laquelle il a été confrontée comme beaucoup d’entre nous : 90% des product owner ont du mal à expérimenter.
Toutes les décisions que nous prenons aujourd’hui se font sans savoir si elles sont justes ou fausses. Ce sont donc plus ou moins déjà des hypothèses.
Deux types d’hypothèses sont à dissocier :
Celles liées au produit, que le Lean Canvas permet de mettre en évidence et de tester
Celles liées aux fonctionnalités, qui nous intéressent aujourd’hui, mais qui ne sont pas vraiment formalisées
Nous nous sommes prêtés à l’exercice par groupes d’environ 6 personnes.
1. Question
Nous sommes partis de cette question “Pourquoi seulement 20% des users ont un compte Spotify Family ?”
2. Idées
Nous avons ensuite émis plusieurs idées qui nous venaient à l’esprit :
3. Hypothèses formalisées
Nous avons choisi parmi le panel des idées jetées sur le papier 3 d’entre elles afin de formuler des hypothèses :
*Si < je permets aux users de diviser le paiement >
Alors < les users seront moins freinés >
Car < sur les apps uber & airbnb ça fonctionne bien >*
*Si < je change le wording “famille” / rename la formule >
Alors < il y aura un augmentation du nb de compte famille >
Car < la population utilisant spotify est jeune et à x% célibataire >*
*Si < j’intègre la création de compte famille dans l’app >
Alors < j’aurai plus de users inscrits en compte famille >
Car < la majeure partie des users sont sur l’app >*
4. Valider les hypothèses
Nous avons ensuite imaginé une expérimentation nous permettant de valider l’hypothèse numéro 4, par manque de temps :
Ajouter un bouton dans l’app qui redirige l’utilisateur vers la page de souscription et la tracker, afin d’avoir une évaluation chiffrée du potentiel intérêt de la formule.
Cette pratique est devenue un vrai mécanisme chez meilleursagents, afin de toujours avoir une hypothèse pour chaque US créée. Et même si elle n’est pas toujours formalisée par le processus précédent, car cela peut-être lourd pour un product owner ou manager de produire dans le détail toutes les hypothèses de chaque idée. Une hypothèse accompagne toujours une user story, et la valeur ajoutée de chaque user story pourra être validée, ou non.
Jonathan Litty, fan de fromage, nous propose une raclette de Design Sprint pour finir cette journée sur les bancs de l’école. Back to the basis.
Le design sprint est issu du design thinking, et permet factuellement d’accélérer et de simplifier le processus de design d’un produit.
Le process tel qu’il est aujourd’hui vient de Google Ventures, et a été retranscrit par un de ses designers, Jake Knapp dans son livre Sprint.
L’idée est la suivante :
Bloquer une équipe dans une salle pendant 5 jours
Faire de l’idéation
Réaliser quelque chose de concret avec un prototype
Avoir des retours utilisateurs qualitatifs à la fin de ces 5 jours
Pouvoir prendre une décision à la fin GO / NO GO / PIVOT
Le Design sprint permet par là même de savoir en 5 jours si une idée est bonne ou vouée à l’échec, et donc doit être abandonnée par l’équipe.
Chaque jour du design sprint est lui-même dédié à un objectif :
Jour 1 : Comprendre.
C’est le moment de présenter le research deck (tous les éléments liés au produit, au marché, à la culture, aux équipes) réalisé par le Sprint Master, de lister les challenges à relever et de définir une macro-map du parcours.
Jour 2 : Générer des idées.
Chacun revient le jour 2 avec des inspirations de ce qui a été vu sur le marché (dans des articles, sur les réseaux sociaux...) et alimente un mur en 3 temps avec ces inspirations de dessin individuel. Ce d’abord via un draft grossier, puis en réalisant un crazy 8s et enfin avec la mise en perspective de la “big picture” du prototype à réaliser.
Jour 3 : Décider.
Une galerie d’art sans explications des dessins individuels réalisés la veille est à disposer. Chacun a le droit à un nombre de votes limités, et les attribue soit au dessin dans sa globalité ou à une fonctionnalité sur le dessin apprécié.
Chaque personne présente et explique ensuite ses dessins, et un second vote est réalisé, afin de faire ressortir les meilleures idées fonctionnelles.
À la fin de la journée, un story board est constitué des dessins ou partie de dessins avec le plus de votes.
Jour 4. Prototyper.
En fonction de ce qui a été regroupé la veille en fin de journée, un vrai prototype est réalisé. Joli ou non, l’important est que chaque fonctionnalité de chaque écran puisse être identifiable et compréhensible.
Jour 5. Tester.
Le jour 5 est dédié à la phase de tests. Le mieux est de pouvoir présenter le prototype à des utilisateurs finaux, mais cela peut aussi être des personnes qui vont travailler sur le projet après. Aucune explication n’est donnée sur les écrans présentés aux utilisateurs, afin de pouvoir récolter leurs remarques à chaud.
Un board de tous ces retours est constitué, et va permettre d’orienter le futur backlog.
Les 5 jours se terminent sur un debrief avec une prise de décision sur les prochaines étapes du projet et le début de la production.
→ Si bloquer 5 jours une équipe peut poser problème à beaucoup d’entreprises, notamment quand il ne s’agit pas du lancement d’un produit ou d’un projet et que l'équipe est déjà dans l’opérationnel, il est possible d’adapter cette méthodologie sur un sprint de 2 semaines par exemple.
Avant de se lancer dans un design sprint, il faut déjà se poser les bonnes questions et être sûr d’avoir des réponses à chacune :
Constituer la bonne team
Trouver un lieu propice où passer 5 jours, et assez grand pour permettre de se déplacer
Du Matériel est évidemment à prévoir pour pouvoir dessiner et afficher sur les murs de la pièces les créations
Et après ces 5 jours à se voir tous les jours, comment on gère le retour au quotidien ? L’équipe se perd facilement de vue.
D’où l’importance de :
À nos crayons ! On se lance à travers les 6 étapes suivantes pour réaliser en 1h un semblant de design sprint de 5 jours. Challenge accepted pour l’équipe !
1/6 : identifier les challenges potentiels
On nous présente le sujet et son research deck : comment gérer les challenges de Sheila dans Santa Clarita Diet, mère de famille qui devient zombie et se retrouve à devoir tuer des “bad guys” pour survivre, sans que sa fille ni ses voisins ne le découvrent.
Naturellement, une ribambelle de challenges sont soulevés : comment savoir qui tuer ? Qui est bon ou mauvais ? Comment le cacher à ses voisins ? Comment gérer son stock de nourriture pour ne jamais être en manque ? Comment diversifier ses repas ?
2/6 : méthode du CPO
Afin de choisir un angle sur lequel reposer notre mini “design sprint”, la méthode du CPO se prête très bien à l’exercice : “Comment pourrait-on ?”
Choix de notre équipe : CPO aider Sheila à anticiper et à gérer son stock de nourriture ?
3/6 : mapper le parcours cible
L’idée était d’établir 2 - 3 étapes pour se limiter dans les parcours possibles à prototyper ensuite, voici les nôtres :
Dans l’idéal, le mapping d’un parcours cible doit répondre aux questions suivantes : Quoi ? Objectifs & Besoins ? Pense quoi ? Pain Point ? Dit quoi (verbatim) ?
4/6 : idéation individuelle
Nous avons ensuite, chacun de notre côté, réalisé des maquettes de ce que l’on imaginait être le service répondant le mieux au parcours cible, à travers un ou plusieurs écrans, sur desktop, mobile ou autre (un frigo connecté ?).
5/6 : converger, voter
Nous avons réuni nos dessins au centre de la table à la vue de tous, sans explications (à éviter même sur les dessins), pour que chacun puisse visualiser les idées des autres membres de l’équipe et voter.
Nous avons ensuite regroupé les features et écrans avec le plus de votes ensemble pour avoir un rendu cohérent et présentable à un utilisateur.
6/6 : tester
Une personne de chaque table s’est rendue ensuite à une autre table pour découvrir les autres prototypes. Sans donner d’explications sur ce que chaque personne percevait du prototype, nous avons cependant posé des questions, et noté tous les points positifs, négatifs, les questions ou quelques verbatims pertinents.
Séchés de la journée, les cerveaux en ébullition, les carnets remplis de notes, on a quand même des étoiles dans les yeux après cette journée folle en rencontres et riches en idées à mettre en pratique.
La School of PO touche à sa fin, non sans un petit moment détente pour nous autres astronautes, autour de planches de charcuteries, fromages et d’une petite coupette. Et ça, ça change des en-cas lyophilisés habituels de notre fusée !
Auteur(s)
Vous souhaitez en savoir plus sur le sujet ?
Organisons un échange !
Notre équipe d'experts répond à toutes vos questions.
Nous contacterDécouvrez nos autres contenus dans le même thème
La qualité est un enjeu très important dans le développement logiciel, cet article vous permettra de (re)découvrir les impacts de la non-qualité, les bienfaits de la qualité et les bonnes pratiques qualité.
Aujourd’hui on parle de product management pour qualifier tout et n’importe quoi, ce qui entraîne la mise en place d’organisations produits sur des bases bancales. Quelles sont les principales erreurs commises ? Comment les éviter ? La liste n’est pas exhaustive mais vous permettra assurément de mieux appréhender votre méthodologie produit.
Cet article présente mes méthodes préférées pour bien appréhender un nouvel environnement de travail, incluant des outils pratiques comme le rapport d'étonnement, le Value Stream Mapping, le mandat de mission, la matrice des attendus et les Moving Motivators, afin de faciliter l'intégration, améliorer les processus et renforcer la collaboration au sein de l'équipe