- Lorsque l’utilisateur se sert du produit sans être la personne habilitée à payer, l’essentiel est d’identifier qui détient réellement l’autorité et l’influence
- Le décideur qui possède l’autorité réelle n’est pas forcément l’acheteur ni le premier utilisateur
- Dans les petites organisations, le gain de temps est crucial, donc il est probable qu’un développeur adopte directement l’outil puis obtienne son achat en convainquant sa hiérarchie
- Dans les grandes organisations, les contraintes de sécurité et de procédure sont fortes, donc le pouvoir de décision d’achat appartient au CTO ou à la direction, avec un cycle de vente long
- La personne habilitée à acheter ne coïncide pas forcément avec le détenteur du budget, et la cible clé est celle qui perçoit le plus fortement la valeur du produit et peut faire avancer son adoption
- La stratégie la plus efficace consiste à fournir à l’utilisateur des données concrètes et des supports de persuasion afin qu’il puisse convaincre la direction, et à l’accompagner dans ce processus
- Le succès final repose sur la conception d’un processus qui soutient l’utilisateur dans son rôle de vendeur en interne
Introduction – point de départ de la question
- Comment s’y prendre lorsque l’utilisateur réel du produit et le client qui prend la décision d’achat ne sont pas la même personne ?
- Le contexte est celui, classique, de la vente de logiciels B2B, où un développeur teste d’abord le produit, puis le CTO ou le Director of Engineering prend la décision finale
La question fondamentale de l’autorité
- La question la plus essentielle est : « Qui détient le vrai pouvoir ? »
- Plus que la simple capacité à payer par carte ou la priorité donnée à l’essai du produit, ce sont l’influence réelle et la motivation qui déterminent le processus d’achat
Scénarios selon la structure de l’organisation
Dans les petites organisations : structure plate et décisions rapides
- Il arrive souvent qu’un développeur découvre le produit et pilote lui-même son adoption
- Comme la principale motivation du CTO est d’accélérer la mise sur le marché et l’itération, la proposition d’outil d’un développeur peut avoir une influence majeure sur la décision
- On observe souvent une diffusion de type Trojan-horse, où le développeur teste rapidement l’outil gratuitement avant qu’il ne soit ensuite converti en offre payante
Dans les grandes organisations : la sécurité et la conformité comme contraintes majeures
- Il existe des contraintes autres que le temps, notamment la sécurité, et les décisions de la direction jouent un rôle central à toutes les étapes
- L’installation ou l’achat autonome par l’utilisateur (le développeur) n’est pas autorisé, et le cycle de vente est long et complexe
- Les critères de perception de la valeur et du risque se concentrent moins sur l’UI/UX ou la DX que sur la sécurité et le résultat final
Le véritable angle de l’influence et de la valeur
- Le détenteur du budget n’est pas toujours celui qui exerce l’autorité réelle
- L’important est de savoir qui a le levier et dont les incitations pèsent le plus dans l’avancement du processus
- Il faut identifier de manière réaliste quel acteur est effectivement capable d’échanger de la valeur à hauteur du prix demandé
Exemple concret de parcours d’adoption du produit
- L’utilisateur / le développeur crée un compte sur le produit
- Il utilise l’essai gratuit dans son environnement local
- Il expérimente directement la valeur fonctionnelle réelle (par ex. comparaison avant/après Pull Request, mise en évidence des problèmes)
- Il perçoit la valeur → attente de gains d’efficacité et d’automatisation
- L’utilisateur convainc la direction de la nécessité du produit
- La direction approuve ou refuse après test interne et examen budgétaire
- La direction donne l’approbation finale pour l’achat
- L’achat du produit est finalisé, puis son usage s’étend davantage dans l’organisation
La question des incitations des deux côtés
- Identifier la motivation fondamentale du développeur à recommander l’outil (confort de travail, mise en valeur de ses compétences, atteinte des objectifs de l’entreprise, etc.)
- Identifier la motivation d’achat de la direction (amélioration de la productivité de développement, atteinte plus rapide des objectifs de l’entreprise, etc.)
- Si ces motivations clés existent, on peut proposer les stratégies suivantes
Stratégies de réponse concrètes
- Fournir à l’utilisateur des outils de persuasion, comme des rapports précis de comparaison avant/après, afin qu’il puisse convaincre la direction
- Dans ce processus, ce ne sont pas des conseils abstraits qui comptent, mais des résultats fondés sur des données quantitatives
- Des mesures concrètes, comme « combien de temps a été économisé par rapport à la méthode précédente », sont la clé de la persuasion
- Comprendre comment se déroule réellement la conversation d’achat grâce à des entretiens clients (développeurs), afin de résoudre à l’avance les obstacles du processus de persuasion
- Autrement dit, plutôt que de convaincre directement la personne habilitée à acheter, il faut fournir tout l’environnement de soutien et les documents concrets nécessaires pour que l’utilisateur joue avec succès un rôle de vente en interne
- Dans ce processus, le succès de l’utilisateur se traduit directement par le succès du fournisseur (une structure gagnante pour l’utilisateur, le fournisseur, la direction et l’entreprise)
Conclusion et résumé
- La meilleure stratégie consiste à aider l’utilisateur à réussir son rôle de vente interne autour du produit
- Il faut se concentrer sur la fourniture de preuves quantitatives et d’éléments concrets de valeur nécessaires pour convaincre la direction
- Il est indispensable, en amont, d’analyser finement la structure décisionnelle selon la taille de l’organisation et ses contraintes
- En définitive, si l’utilisateur réussit, le fournisseur et l’entreprise réussissent eux aussi simultanément
Aucun commentaire pour le moment.