“Tu n’as jamais participé à une démo de Vianney ? Tu devrais y aller, elles sont trop bien !”
Bonjour à tous! Je suis Vianney, PO depuis presque 8 ans et voila ce qu’on dit à propos de mes démos.
Les « démos » jouent un rôle essentiel dans ce processus, offrant une occasion unique de mettre en lumière les fonctionnalités, de recueillir des retours précieux et de susciter l’enthousiasme autour du produit. Cependant, réussir une démo ne se résume pas simplement à cliquer à travers les écrans. Cela nécessite une préparation minutieuse, une compréhension approfondie des besoins des utilisateurs, et une dose subtile de savoir-faire.
Dans cet article, je partage quelques astuces personnelles, qui ne sont dans aucun livre et que j’ai affinées au fil du temps. Ces conseils pratiques vont au-delà des aspects techniques, plongeant dans l’art de communiquer efficacement, de captiver l’audience et de transformer chaque démo en une expérience mémorable. Que vous soyez un product owner chevronné ou que vous débutiez dans ce rôle, ces astuces sont conçues pour vous aider à exceller lors de vos présentations et à maximiser l’impact de votre produit. Préparez-vous à élever vos démonstrations au niveau supérieur !
DISCLAIMER : cet article s’inscrit dans les limites de mon contexte transverse et international. Cette démo se fait sur l’exemple d’un tout nouveau projet. Sur ce, bonne lecture !
1. Restez serein: créez un modèle réutilisable
Ne réinventez pas la roue à chaque démo, créez un modèle!
Dupliquez-le à chaque nouvelle démo et partez de là pour la construire, cela permettra de :
- vous faciliter la vie lors de la préparation ;
- faciliter la vie de votre auditoire. Garder la même structure, la même identité visuelle permet à tout le monde de connaître son environnement et de se concentrer sur ce qu’il y a de plus important : ce que vous avez à présenter.
💡N’oubliez pas que votre modèle n’est pas figé et doit continuer à évoluer : ajoutez, retirez des sections au fil des feedbacks et tenez-le à jour avec la nouvelle charte graphique de votre entreprise !
Concrètement, voici la structure que j’utilise (fait sur Google Slide):
– La page d’attente
Cette page est utilisée au début de la démo pour attendre les retardataires. Elle présente le nom de mon produit, le nom de mon équipe, une mention « Live demo » pour bien dire que ce n’est pas enregistré, et la date du jour.
💡 N’hésitez pas à aussi y ajouter une musique d’attente à faible volume, c’est toujours plus sympa.
– Le sommaire
Cette slide indique tout ce que nous allons voir durant cette démo et change très rarement:
Cette slide indique tout ce que nous allons voir durant cette démo et change très rarement :
- infos sur l’équipe : voir « Créez une grande famille » ;
- résolution des bugs et améliorations : les bugs, il faut en parler. Listez ceux que vous avez résolus sans forcément les montrer mais avec au moins une capture d’écran pour le contexte ;
- nouvelles fonctionnalités : montrez les maquettes puis la fonctionnalité en direct. Préparez bien cette partie pour éviter l’effet démo (voir « Ce n’est pas grave si ça bug ») ;
- feuille de route : montrez à votre auditoire que vous avancez (voir « Fournissez un bon moyen de suivre votre avancement »). Pour éviter d’utiliser des dates, classez les choses à faire dans votre roadmap selon 4 critères :
- maintenant : ce que vous allez faire au prochain sprint ;
- suivant : ce que vous allez faire durant le sprint d’après ;
- plus tard : vos objectifs moyen terme ;
- après : vos objectifs long terme ;
- one more thing : le seul élément facultatif (voir « Restez surprenant ») ;
- AMA (ask me anything) : laissez un petit temps durant lequel votre auditoire peut vous poser des questions en direct (voir « Créez une grande famille »).
2. Restez surprenant: le « One more thing »
Ajoutez parfois un élément surprenant comme une section « One more thing » pour annoncer de grandes nouvelles ou partager des victoires ! Avec cette section facultative votre auditoire se demande s’il y aura une nouvelle surprise et cela les incitera à venir voir votre démo !
3. Créez une grande famille
Même si vous et votre équipe développez des logiciels, vous n’êtes pas des robots. Vos utilisateurs ont parfois du mal à le comprendre. Pour éviter cela vous pouvez:
– Session question/réponse
Lancer une session question/réponse
Cette section peut faire peur au départ, car elle vous met face à tout le monde sur n’importe quel sujet, mais elle vous rend aussi très accessible. Vous n’êtes plus PO d’une autre équipe, vous vous rendez disponible pour tous maintenant. Pour cet exercice, rassurez-vous :
- vous connaissez votre sujet sur le bout des doigts ;
- vous n’êtes pas seul, votre équipe est là pour vous aider ;
- vous n’avez pas de réponse ? Pas de panique, utilisez la fameuse phrase « Je n’ai pas la réponse à votre question mais je la note et je reviens vers vous par mail dans la journée » ;
- vous êtes accessible.
– Infos sur l’équipe
Avec l’accord de votre équipe, faites une section « Infos sur l’équipe » dans laquelle vous communiquez plein d’infos d’équipe : nouvelle arrivée, départ, congé paternité ou maternité, formation, vacances, etc. De cette manière, tout le monde suit les événements et se rend compte que la capacité à faire n’est pas toujours de 100 %, il y a des aléas ! Et en cas de retard, cela est plus facilement justifiable : 4 arrêts maladies imprévus, les engagements vont être difficiles à tenir, tout le monde s’en rendra compte.
4. Ne cachez pas la complexité…
Faire de l’informatique c’est parfois complexe et présenter la complexité à un auditoire qui ne comprend pas la technique est parfois compliqué.
Exemple avec le lancement d’un nouveau projet
Dernièrement, j’ai lancé un nouveau projet et j’ai annoncé 6 mois de travail pour 5 écrans. Pour que tout le monde se rende compte que pour que ça fonctionne il faut aussi pleins de module.Dans ce cas, voici ma méthode:
4.1. Pour chaque écran utilisateur (maquette à l’appui pour le contexte), décrivez chaque module nécessaire à son fonctionnement
4.2. Regroupez tous les modules dans une seule slide pour montrer la complexité…
4.3. … Mais restez simple
Une fois que vous avez montré la complexité, redescendez d’un cran (voire même plusieurs !), vous n’êtes pas là pour perdre tout le monde.
Pour ce faire, réexpliquez le rôle de chaque élément avec des notions compréhensibles par tous :
- ce module est pour les utilisateurs ;
- ce module pour la sécurité ;
- celui-ci pour la rapidité ;
- celui-là pour la communication, etc.
5. Fournissez un bon moyen de suivre votre avancée
Pour indiquer votre avancement, reprenez votre schéma directeur que vous connaissiez déjà et présentez-le à chaque démo. Ajoutez-y une légende simple pour différencier ce qui n’est pas fait, ce qui est en cours et ce qui est terminé et présenté en démo :
6. Soyez régulier 🗓️
Ne prenez pas le rituel de la démo pour une chose facultative. Soyez régulier. Envoyez une invitation récurrente toutes les x semaines selon votre sprint et faites-la. Peu de choses à présenter ?
Ce n’est pas grave !
Expliquez un de vos concepts techniques plus en détail avec des schémas, partagez vos interrogations avec votre auditoire, faites un petit atelier brainstorming, présentez de nouvelles maquettes d’interface. Il y a plein de choses à communiquer. Ne pas faire une démo ça arrive, mais souvenez-vous : votre régularité prouvera votre sérieux, votre engagement et augmentera la confiance (et la tolérance) de tous envers vous, votre équipe et votre projet.
7. L’effet démo 🪳
Il n’y a que ceux qui ne font rien qui ne se trompent pas.
Gardez bien ça en tête quand vous vouliez montrer quelque chose et que ça ne fonctionne pas. Très récemment ça m’est arrivé : 3 jours de préparation. Un gros teasing sur plein de fonctions. « Soyez là, ça va être fou » et tout le teasing. Le lundi, ça fonctionne. Le mardi soir, ça fonctionne. Le mercredi matin : 20 min avant la démo, je me rends compte que, à cause d’une autre équipe, ça ne fonctionne plus.
Après la frustration, finalement ce n’était pas si grave ! Le but est de montrer ce que vous avez fait et vous n’avez pas pu le faire à ce moment-là, mais souvenez-vous que vous pourrez aussi le faire à la prochaine démo ! Ce n’est pas annulé, c’est reporté. Les fails ça arrive, ça montre aussi à tous que vous et votre équipe êtes humains, on n’est pas parfaits, on fait de notre mieux.
Pourquoi ne pas enregistrer sa démo?
Le direct, c’est la vie ! Montrez le travail de votre équipe vous-même ou donnez-leur l’occasion de le faire. Tout ça augmente la confiance de votre équipe, la cohésion et permet à tout le monde de s’améliorer en cas de fail. J’ai déjà participé à des démos enregistrées et c’est d’une morosité incroyable.
Les démos en direct ont bien plus d’âme et de dynamisme alors n’hésitez pas ! Durant vos démos régulières vous avez le droit à l’erreur, faites-les en direct. Si vous avez des démos extraordinaires, n’hésitez pas à préparer une démo enregistrée si ça vous rassure ! Elle pourra vous être utile si quelque chose se passe mal durant la démo en direct le jour J. 😉
8. Récoltez des avis avant de partir au front 🍖
Avant les démos, prenez 30 minutes maximum pour montrer les points principaux à quelqu’un de votre équipe (ou d’une équipe externe) pour lui présenter rapidement les éléments clés, les notions complexes. Assurez-vous que vos schémas et images sont assez parlants et ajustez si besoin.
En savoir plus sur le contexte :
- 1 démo à la fin de tous les sprints (3 semaines) pour présenter les nouveautés et avancements ;
- présentation de 2 produits ;
- 45 min de démo en anglais ;
- j’assure maintenant 100 % de la démo. Celle-ci se faisant en anglais devant 50 personnes invitées, la démo était source de beaucoup de stress pour l’équipe. Plus à l’aise à l’oral et dans la langue de Shakespeare, j’ai pris la responsabilité de ce rituel.
9. Pas besoin de neuvième astuce
Bonne nouvelle! 8 astuces sont suffisantes alors relisez les et appliquez celle qui vous va le mieux!
Avec un peu de recul…
Pour conclure, cette démo s’inscrit dans un contexte transverse, impliquant plusieurs pays. L’enjeu principal reste la valeur apportée : chaque fonctionnalité doit démontrer son impact, adapté à des besoins en constante évolution. Dans le cas du search by GTIN, par exemple, une amélioration ciblée a multiplié sa valeur par 10. Toutefois, il manque une vraie phase de feedback en fin de démo pour mieux capitaliser sur les retours et continuer à progresser.
