School of PO 2019 : devoir maison et retour d'expérience

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.

SOMMAIRE

• Maximum impact, minimum effort
• Maria Montessori : Meilleure PO du monde
• Own your product as if it mattered
• Vanity Metrics
• L'arbre des hypothèses
• Raclette de "design sprint"

Maximum Impact, Minimum Effort

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.

Moins j’en fais mieux je me porte

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 ?

Les 3 grandes illusions de la gestion de projet

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.

• 1ère illusion : un effet collatéral des itérations imposées par l’agilité est de perdre de vue ce qui apporte de la valeur à un produit. Ou plus spécifiquement l’illusion est de penser que parce qu’à chaque fin d’itération une nouvelle mise en production est effectuée, elle apporte de la valeur.

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.

• 2ème illusion : si quelqu’un d’important hiérarchiquement dans la société demande une feature, c’est qu’elle a de la valeur ajoutée.

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.

• 3ème illusion : nous sommes bons dans l’évaluation de la valeur ajoutée d’une fonctionnalité.

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.

Besoin d’adaptabilité

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 ?

L'importance du contexte

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

• mettre en avant un exemple simplifié d’un impact mapping

4/ Dans le cas d’un contexte projet basé sur un changement de business

• ajouter une branche dédiée à la culture d’entreprise et à l’environnement sur l’impact mapping

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.

Maria Montessori Meilleure PO du Monde

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

Les 7 qualités du PO

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 :

1. Formuler des hypothèses et mesurer ses résultats
2. L’Observation : que ce soit d’un groupe, d’une personne, ou encore d’une personne au milieu d’un groupe
3. Connaître son utilisateur
4. Ne pas réinventer la roue
5. Tester et itérer, tester et itérer, tester et itérer
6. Une UX adaptée et poussée
7. Partager et expliquer

Own Your Product as if it Mattered

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.

Comment le matérialiser ?

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.

Daily basis ?

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”.

Vanity Metrics

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.

Ca fait du biz

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.

Comprendre sans se voiler la face

É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.

Atelier 1 Arbre des Hypotheses

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.

Tout est hypothèse

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

Marche à suivre

1. Commencer par une question
2. Laisser libre cours à ses idées pour les formuler
3. Convertir les idées en hypothèses formalisées et les formuler : si <réalisation>, alors <résultat> car <raison d’y croire>
4. Formuler une expérimentation pour valider cette hypothèse

Expérimentation

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 :

• trop cher
• pas envie de payer pour tout le monde
• les utilisateurs n’ont pas de famille
• impossible de gérer son compte famille depuis l’app spotify
• manque de visibilité
• manque de connaissance des CGU
• peur pour leur vie privée

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 :

• Pas envie de payer pour tout le monde :

*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 >*

• Les utilisateurs n’ont pas de famille

*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 >*

• Impossible de gérer son compte famille depuis l’app spotify

*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.

Conclusion

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.

Atelier 2 Design moi un Sprint

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.

1/ D’abord, c’est quoi un design sprint ?

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.

2/ Et sinon, on fait quoi pendant un design sprint ?

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.

3/ Et comment ça se prépare un design sprint ?

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 :

• Quel est l’objectif ou le challenge à relever ?
• Est-ce qu’il y a de la data ?
• Quels seront les moteurs de succès ?

Constituer la bonne team

• Décideur
• Sprint master
• Porteur Projet (PO)
• Métier Produit (business)
• Technique
• Designer
• UX Writer

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

4/ Et après ?

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 :

• Tout documenter sur les études préalables et les 5 jours passés
• Caler un debrief pour avoir un REX
• Avoir des décideurs impliqués pour que les actions suivent tout de suite après
• Créer le backlog rapidement

5/ Si on essayait ? Time to experiment !

À 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 :

1. Quand est ce que Sheila va manquer de viande
2. Notification / Alerte quand Sheila doit aller chasser
3. Sheila peut chasser en amont, sans être dans l’urgence

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.

Conclusion

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 !