SolutionScience #039 | Tell Show Tell est un outil, pas un dogme !

Petite précision avant de commencer : je sais, ce numéro sort un dimanche, et c'est évidemment exceptionnel. Me dis pas que tu regardes Titanic sur TF1 quand même ? Bref, j'ai été pas mal pris ces derniers jours (et tu vas bientôt savoir pourquoi).

Aujourd'hui, je vais te parler de la méthodologie Tell Show Tell (que je vais appeler TST pour m'économiser un peu pendant l'écriture).

D'ailleurs, ne lis pas la suite tant que tu n'as pas partagé ce numéro à deux ou trois collègues SEs (voire à toute ton équipe). Un mail, un petit message Slack, peu importe ! Le partage est de loin ma première source d'abonnement pour SolutionScience, et on est désormais plusieurs centaines grâce à des SEs qui font exactement ça. Merci !

J'ai eu envie d'écrire ce numéro après être tombé sur un post de Max Lüpertz, un super SE qui bosse en Allemagne, et probablement l'un des rares à parler de stratégie de démo avec autant de clarté (suis-le sur LinkedIn !). Sa conviction rejoint la mienne : la peur de « manquer une fonctionnalité » est souvent la raison principale des démos à rallonge, trop denses et sans message central.

Le TST vient de la galaxie 2Win, l'organisme derrière un truc que tu connais certainement déjà : Demo2Win. Sur le papier, c'est un outil parmi d'autres dans une méthodologie plus large, pensé pour relier une fonctionnalité à sa valeur. Le problème, c'est que dans beaucoup de formations, les gens ressortent avec un outil et l'envie irrépressible de s'en servir sur absolument tout.

Notre équipe presales venait justement de finir deux jours de formation avec une personne de chez Demo2Win : on a eu la totale, des jeux de rôle en groupe, des fiches méthodo, et bien sûr le sacro-saint Tell Show Tell répété à toutes les sauces pendant quarante-huit heures. Un collègue avait ce regard qu'on voit chez les gens qui reviennent d'une retraite de méditation de dix jours : illuminé, un peu fatigué, mais absolument certain d'avoir trouvé la réponse universelle à tous les problèmes de démo.

Quelques jours plus tard, j'ai suivi ce collègue SE en shadow sur une démo avec un prospect : l'idée étant de voir ce qu'il fallait optimiser... et d'en tirer des enseignements pour toute l'équipe.

— Je vais vous montrer comment on crée un segment.

— Voici comment on crée un segment.

— Vous venez de voir comment on crée un segment.

À la troisième boucle, j'ai senti que quelque chose clochait. Au bout de la sixième boucle, j'ai observé discrètement le DSI dans la salle. Il avait ce regard particulier de quelqu'un qui calcule combien de temps il reste avant la pause déjeuner. Le CMO, lui, avait sorti son téléphone depuis un moment déjà. Et mon collègue continuait, imperturbable, fonctionnalité après fonctionnalité, en appliquant à la lettre ce qu'on venait de lui enseigner.

Techniquement, il faisait les choses bien. Et pourtant, dans la salle, plus personne n'écoutait depuis plus de dix minutes...

C'est là que j'ai compris quelque chose d'important sur le TST.

Je crois que le TST vient du monde de la pédagogie. L'idée de base est on ne peut plus simple : tu annonces ce que tu vas montrer et pourquoi ça compte, tu le montres, puis tu reformules ce qui vient d'être vu en le reconnectant à l'idée de départ et à la valeur. C'est une structure qui aide à ancrer un message dans la mémoire du prospect : on l'entend trois fois sous trois formes différentes, et ça reste.

Appliqué à une démo, l'intention de départ est bonne. Trop de SEs débutants montrent une fonctionnalité brute, souvent sans contexte, sans expliquer pourquoi le prospect devrait s'en soucier (en gros, comment connecter un business outcome à une fonctionnalité). Le TST aide à suivre cette direction : il oblige à donner du sens avant et après « le show technique et fonctionnel ».

Et puis c'est terriblement facile à enseigner. Un manager presales peut prendre n'importe quel SE junior, lui donner la formule TST, et en vingt minutes ce SE a une structure pour ne plus jamais montrer quelque chose « à froid ». C'est plutôt rassurant, c'est facilement reproductible.

Sauf que c'est précisément cette facilité qui devient un problème.

J'ai la conviction que le TST a été pensé pour structurer un moment précis dans une démo, mais surtout pas pour structurer la démo entière ! Le problème commence quand un SE applique la boucle TST à chaque fonctionnalité, l'une après l'autre, sans lien entre elles.

Et c'est exactement ce qui s'est passé avec mon collègue ce jour-là.

— Je vais vous montrer X, voilà X, vous venez de voir X.

Puis on recommence avec Y, puis avec Z. Le prospect se retrouve avec une démo qui ressemble à un tutoriel découpé en chapitres, mais sans fil conducteur entre les chapitres. Un enfer.

Le pire, c'est que peu de personnes dans la salle peuvent vraiment dire ce qui ne va pas. Le SE a suivi la méthode et tout semble structuré. Pourtant, le prospect a vu quinze fonctionnalités présentées individuellement et il ne sait absolument pas comment elles s'articulent pour résoudre son problème. On lui a donné une liste de courses, juste un poil mieux structurée.

On a déjà parlé de ce problème dans le numéro sur la démo de 30 minutes : plus on montre, plus on dilue. Le TST mal utilisé est une des façons les plus sournoises de tomber dans ce piège, parce qu'il donne l'illusion d'être méthodique. On a l'impression de bien faire et c'est justement pour ça que c'est dangereux.

Voici ce que je pense vraiment : le TST n'est pas une méthodologie de démo. Comme Max.

Voilà, c'est dit.

En fait, ce n'est qu'un outil au service d'une méthodologie. Et cette méthodologie, c'est la narration.

Ma conviction est très simple : une bonne démo, c'est un peu comme un dîner où on choisit pour son invité un plat qu'il va vraiment apprécier, plutôt qu'un buffet à volonté qui va finir en indigestion.

Dans ma pratique, je construis mes démos autour de deux ou trois scénarios narratifs maximum. Chaque scénario raconte une histoire qui doit être connectée au réel, centrée sur un stakeholder précis et son problème. Et c'est à l'intérieur de ce scénario, pas à chaque fonctionnalité, que j'utilise le TST.

Prenons un exemple concret. Imaginons Sarah, responsable marketing chez un de mes prospects. En discovery, j'ai compris sa douleur : son équipe attend trois jours chaque fois qu'elle a besoin d'un nouveau segment d'audience, parce que ça passe par l'équipe data qui a sa propre file d'attente.

Sarah n'a jamais demandé « une fonctionnalité de segmentation avec API et exports CSV automatisés ». Ce qu'elle a demandé, en substance, c'est de ne plus passer pour la collègue qui annonce systématiquement en réunion que la campagne ne sera pas prête à temps.

Mon scénario, c'est l'histoire de Sarah qui veut lancer une campagne ciblée vendredi, et qui d'habitude devrait s'y prendre depuis mardi pour être dans les clous.

Le Tell initial pose cet enjeu. Le Show ensuite ne montre pas la fonctionnalité de segmentation isolément : il montre un ensemble fonctionnel cohérent, peut-être deux ou trois fonctionnalités qui, ensemble, permettent à Sarah de construire et lancer son segment elle-même, en quelques minutes. Le Tell final reconnecte tout ça au problème de Sarah : elle n'attend plus trois jours et elle n'attend plus personne. Pour elle, c'est une grosse valeur et une « pain » en moins.

Le TST devient un outil de liaison entre la narration et la preuve. Il structure un moment fort, à l'intérieur d'une histoire qui a déjà du sens avant même qu'on montre quoi que ce soit.

Le choix de ces deux ou trois scénarios n'est pas un détail : c'est probablement la décision la plus importante de toute la préparation de la démo et c'est celle que la plupart des SEs zappent complètement, occupés qu'ils sont à préparer leur environnement technique.

Je m'appuie généralement sur trois critères. D'abord, ce qui a émergé en discovery : les vrais problèmes, ceux qu'on a creusés, ceux qui sont douloureux (pas la liste de fonctionnalités demandées). Ensuite, les enjeux business prioritaires de l'organisation : ce qui compte vraiment pour eux cette année et qui justifie le budget et l'urgence du moment. Et enfin, l'importance « politique » des stakeholders présents dans la salle. Les scénarios doivent les cibler directement pour qu'ils se disent « Wow, trop cool, cela résout mon problème ton truc »

Quand le DSI voit un scénario qui ressemble exactement à son problème d'intégration avec le CRM legacy, et que le CMO voit un scénario qui ressemble exactement à son problème de réactivité sur les campagnes, tu n'as pas fait une démo générique : tu as fait deux démos en une, et chacune parle directement à la bonne personne.

C'est plus exigeant que d'enchaîner des boucles TST sur chaque écran de ton produit. Et je crois que c'est précisément pour ça que ça fonctionne.

Ce que tu peux faire dès maintenant.

1. Avant de construire ta démo, identifie deux ou trois scénarios concrets pour ton audience (pas une liste de fonctionnalités). Si tu commences ta préparation en listant les fonctionnalités à montrer, tu pars clairement du mauvais bout. Commence par les histoires : l'émotion vient avec. Les fonctionnalités viendront se ranger naturellement dans ces histoires.
2. Utilise le TST pour relier un ensemble fonctionnel à un business outcome (encore une fois jamais fonctionnalité par fonctionnalité). Si tu te retrouves à faire un TST toutes les deux minutes sur chaque petit écran, c'est le signal que tu es en train de lister plutôt que de raconter. Un scénario peut très bien englober quatre ou cinq fonctionnalités dans un seul mouvement narratif.
3. Assure-toi que chaque stakeholder clé ait au moins un scénario où il se reconnaît. Reviens à ta power map. Qui est dans la salle, et qu'est-ce qui compte vraiment pour cette personne ? Si tu ne peux pas y répondre, tu n'es pas prêt à construire tes scénarios.
4. Teste ta démo avec une seule question : est-ce que je raconte une histoire ? Si en répétant ta démo à voix haute tu entends un truc comme « et ensuite, je vais vous montrer... » plus de trois fois, il y a un problème de narration.

Bref, tu l'as compris : le TST est un outil... et la narration est la (vraie) méthode.

Si tu confonds les deux, tu vas construire des démos qui semblent structurées mais qui ne racontent rien du tout.

Et toi… combien de fois as-tu fait une démo où chaque fonctionnalité avait droit à son petit laïus, sans que personne ne se souvienne de rien à la fin ?

SolutionScience arrive un vendredi sur deux désormais, et toujours avec la même conviction : de la nuance plutôt que du synthétique. Si ce numéro te fait revoir ta prochaine démo, c'est top, partage-le à un collègue SE qui carbure encore aux boucles TST sans s'en rendre compte. Il te remerciera !

Si tu n'es pas encore abonné, c'est juste en dessous.

À dans deux vendredis.

N'oublie pas de partager, hein !

Philippe