Le réflexe
La démo s’ouvre sur la migration. Nouveau service, nouvelle base, le schéma avec les boîtes et les flèches.
En face, le client attend poliment la partie qui le concerne.
Le réflexe builder
“Voici ce qui change pour vous, et ce qui nous permet de le dire.”
Pourquoi
Le client ne paie pas pour ton architecture. Il paie pour ce qu’elle change pour lui : du temps récupéré, un risque en moins, un service qui tient. Commence par ça. Les détails techniques viennent ensuite, pour ceux qui en ont besoin pour décider : sécurité, intégration, maintenance.
Le travail technique invisible compte autant que le reste. C’est lui qui fait tenir tout le reste. Mais une équipe qui ne sait pas dire à quoi il sert perd au moment du budget. Relie chaque effort à son effet.
Certains projets ne livrent aucune fonctionnalité. La rotation des clés. Une piste d’audit. La logique de relance derrière les paiements. La phrase existe quand même, elle décrit ce qui cesse de se produire : “Un paiement qui avait échoué disparaissait en silence, et le vendeur l’apprenait par le client.” Ça se défend en réunion budgétaire.
Le même geste vaut hors logiciel : une nouvelle procédure, un nouvel outil comptable, une réorganisation. Dis ce qui change pour la personne en face.
À essayer
Choisis un chantier et écris l’avant et l’après pour son destinataire.
Avant : le vendeur attendait la fermeture pour savoir s’il avait été payé.
Après : il le voit arriver.
Fais reformuler le bénéfice par une personne concernée. Si elle n’y arrive pas, ta phrase n’est pas encore bonne. Après la livraison, vérifie l’effet annoncé avec elle.
À discuter
Sur quel chantier actuel ne savons-nous pas dire ce qui change pour son destinataire ?