Toutes les entreprises instrumentent la promesse et espèrent la delivery. Pourquoi l'avant-vente et les professional services sont le seul instrument capable de mesurer si un nouveau produit reste connecté aux attentes réelles des clients, et pourquoi la plupart des organisations l'apprennent avec dix-huit mois de retard.

Quatre-vingts pour cent. C'est la part des fonctionnalités d'un logiciel moyen qui ne sont que rarement ou jamais utilisées, selon l'analyse par Pendo de l'usage réel sur 615 abonnements, étude qui estimait par ailleurs à environ 29,5 milliards de dollars les sommes dépensées en un an par les éditeurs cloud cotés pour les construire. Le Standish Group, avec une méthode différente et une décennie plus tôt, aboutissait au même verdict : environ deux tiers des fonctionnalités d'un produit type sont rarement ou jamais utilisées.

Posez maintenant un second chiffre à côté. Dans l'enquête annuelle de Gartner auprès des product managers, seules 11 % des organisations déclaraient que l'ensemble de leurs produits avait atteint 100 % des objectifs de lancement définis en interne, et 45 % des lancements accusaient au moins un mois de retard.

Deux mesures différentes, une seule conclusion. Le problème n'est pas que nous ne savons pas construire. L'industrie n'a jamais aussi bien construit. Le problème, c'est qu'entre le moment où un produit est conçu et le moment où un client l'utilise vraiment, quelque chose rompt la connexion, et presque aucune entreprise n'a d'instrument pointé sur la rupture.

Cet instrument existe. Il s'appelle avant-vente et professional services, et dans la plupart des organisations il est traité comme le dernier kilomètre du lancement plutôt que comme son système de mesure.

Nous instrumentons la promesse et nous espérons la delivery

Regardez ce que suit réellement un dashboard de lancement : readiness GA, complétude des fonctionnalités, sessions d'enablement délivrées, pipeline généré, logos signés, bookings contre plan. Chacune de ces métriques se situe du côté pré-signature du business. Chacune mesure la qualité avec laquelle nous avons raconté l'histoire.

Et le meilleur prédicteur de la survie du produit en année deux, l'écart entre ce qui a été vendu et ce qui a été livré sur les dix premiers comptes, n'est mesuré par personne.

Ce n'est pas un oubli. C'est structurel. Les personnes capables de voir cet écart, l'ingénieur avant-vente qui a observé le visage de l'acheteur quand un cas d'usage ne collait pas, le responsable delivery en semaine trois du premier déploiement, se situent au bout de la chaîne organisationnelle, et leur ligne de reporting remonte vers une revue de delivery, pas vers le produit et le marketing.

Le problème racine, c'est la latence de vérité

Je donnerais un nom à cette défaillance : la latence de vérité. Le délai entre le moment où un client vit votre produit et le moment où votre entreprise sait ce qu'il a vécu.

Dans la plupart des grandes entreprises, ce délai se compte en trimestres. Et il compose, parce que le coût d'une correction augmente à chaque trimestre de latence. Au premier mois, le correctif tient dans une slide et une conversation. Au douzième, le pitch est dans le champ, la roadmap est engagée, trente comptes ont acheté la même promesse, et la correction exige désormais un repositionnement, une release et une série d'appels clients inconfortables.

Il y a quelques années, on m'a demandé de regarder un compte en rouge. Module phare, plus gros logo du lancement, dix-huit mois d'ancienneté, renouvellement à risque. Gestion de crise ordinaire. J'ai demandé à la responsable delivery de m'envoyer toute la documentation existante.

Elle m'a envoyé un dossier. Il contenait une note de cinq pages, rédigée en semaine trois du tout premier déploiement, des mois avant que le compte ne vire au rouge, avant même qu'il ne prenne du retard. Elle listait quatre choses qui allaient casser. Les quatre ont cassé, dans l'ordre où elle les avait écrites.

Elle l'avait envoyée à son manager, qui l'avait remontée en revue de delivery, où elle avait été enregistrée comme un risque projet. C'est exactement à cela qu'elle ressemblait. Ce n'était pas un risque projet. C'était du feedback produit, du feedback pricing et du feedback pitch, et cela est resté un étage plus bas que les deux équipes qui en avaient besoin, pendant neuf mois, correctement classé, dans un système qui fonctionnait exactement comme prévu.

Personne n'a été négligent. L'organisation n'avait simplement aucun canal par lequel la vérité pouvait remonter.

D'où l'asymétrie suivante. Nous payons des cabinets d'analystes six chiffres pour une photographie d'un marché dans lequel nous nous tenons déjà. Pendant ce temps, la preuve brute, un vrai client avec de vraies données qui essaie d'utiliser ce que nous venons de construire, est produite chaque semaine à coût marginal nul par l'avant-vente et la delivery, puis versée dans un registre de risques où elle meurt en silence.

La plupart des écarts produit sont des écarts de promesse

L'un des quatre points de cette note n'était même pas un défaut. La démo promettait une connexion aux systèmes existants en une journée. C'était vrai, pour un système, avec un schéma propre. Le client en avait neuf.

Corriger le produit aurait pris trois trimestres. Corriger la phrase a pris une après-midi : nous en avons fait une question de qualification, posée dès le deuxième rendez-vous commercial. Combien de systèmes, quels schémas, qui en est propriétaire.

Le win rate du module a légèrement baissé. La cause de churn a totalement disparu.

C'est la partie qu'on saute dans les revues de lancement, et elle explique une bonne part de ces 80 % de fonctionnalités inutilisées. Quand la delivery remonte un écart, le réflexe est de l'envoyer au produit, parce qu'un écart ressemble à quelque chose qui manque. Mais un élément de roadmap coûte deux trimestres et un arbitrage, alors qu'une promesse peut être réécrite mardi. Envoyez l'écart au sales d'abord et au produit ensuite, faites-le pendant six mois, et la plupart des organisations découvrent qu'une part significative de leur roadmap compensait leur propre marketing.

Le corollaire compte pour quiconque dirige une organisation de professional services. Les questions de qualification que vos équipes delivery auraient aimé voir posées par le sales ne sont pas du collatéral commercial. Ce sont des artefacts produit : la description la plus courte disponible des conditions dans lesquelles le produit délivre réellement de la valeur. Elles devraient être livrées avec le produit.

Un produit n'existe pas le jour où il est shippé

Il existe le jour où une équipe delivery qui ne l'a pas construit le déploie pour un client qui ne l'a pas co-conçu. Tout ce qui précède est une hypothèse assortie d'une soirée de lancement.

Les design partners ne comptent pas. Les deux comptes amis qu'un VP Produit a personnellement accompagnés non plus, parce que ces clients ont été vendus par l'auteur de l'idée, servis par les gens qui ont écrit le code, et indulgents sur des choses qu'un client payant ne pardonnera pas. Votre vrai marché sera vendu par un commercial avec un quota et une slide, puis servi par un consultant arrivé le trimestre dernier.

L'écart entre ces deux populations est l'endroit exact où meurent les lancements, et l'avant-vente et les services sont les seules fonctions présentes des deux côtés.

Cinq décisions pour le comité exécutif

Si je devais structurer le sujet pour un lancement ce trimestre, cinq décisions.

• Donner à l'avant-vente et au PSO un droit de veto sur la gate GA. Pas un siège à la table, un veto. Un produit n'est pas disponible en GA parce que l'engineering a vidé son backlog. Il l'est quand une équipe delivery qui ne l'a pas construit sait le déployer, sur des données client, avec un playbook écrit, dans le délai annoncé par le pitch. Si cela ne s'est pas produit trois fois, c'est un pilote avec un communiqué de presse.

• Traiter les dix premiers clients comme une expérimentation, pas comme des comptes. Un responsable delivery senior nommé sur les dix, une hypothèse écrite par compte sur ce à quoi ressemble la valeur et à quelle échéance, et une restitution toutes les deux semaines devant les directions produit et sales réunies dans la même salle. Pas un QBR, un carnet de laboratoire. Dix comptes ne constituent pas un échantillon statistique, et ce n'est pas nécessaire. C'est la population entière des humains qui ont utilisé la chose.

• Router chaque écart entre le pitch et la delivery vers le sales avant le produit. Deux tiers de ce qui est escaladé comme un écart produit est un écart de promesse. Corrigez la phrase d'abord, puis décidez si la fonctionnalité vaut encore le coût. Publiez les phrases corrigées aux équipes terrain chaque semaine pendant les deux premiers trimestres.

• Mettre une métrique de delivery sur le dashboard de lancement. Time to first value sur les dix premiers comptes, écart entre l'effort de déploiement chiffré et l'effort réel, et nombre de corrections de pitch émises. Trois lignes, toutes disponibles dès aujourd'hui, toutes mesurant le versant post-signature que rien d'autre sur ce dashboard ne voit.

• Instrumenter la boucle de feedback avec l'IA, pas seulement le produit. Les modèles qui lisent déjà vos tickets de support peuvent lire les notes de déploiement, les transcripts d'ateliers d'implémentation et les documents de cadrage, et faire remonter la distance récurrente entre ce qui a été promis et ce qui a été livré. La latence de vérité est un problème de routage de données, et c'est désormais un problème soluble.

L'ère de l'IA aiguise les deux faces du sujet. Les cycles de lancement se compriment, ce qui rend la latence plus coûteuse par trimestre, et les concurrents itèrent sur votre positionnement plus vite que vous ne le corrigez. En même temps, la preuve produite par la delivery n'a jamais été aussi facile à capter, structurer et router. Les organisations qui gagneront la prochaine décennie de lancements ne seront pas celles qui auront le meilleur récit de lancement. Ce seront celles qui auront raccourci la distance entre le mardi de leur client et leur propre roadmap.

Le lancement, redéfini

Cessez de penser un lancement comme le moment où votre produit rencontre le marché. C'est le moment où votre entreprise rencontre ses propres hypothèses, et l'avant-vente et les services sont les seules fonctions présentes là où les deux se percutent.

Ce ne sont pas le dernier kilomètre du lancement. Ce sont l'instrument. Traitez-les comme un centre de coûts qui exécute un plan, et vous saurez ce que pensent vos clients dans dix-huit mois, par un rapport de churn. Traitez-les comme votre capteur principal, et vous le saurez en trois semaines, par une note de cinq pages, pendant que tout est encore peu coûteux à corriger.

Le produit que vous avez lancé est une hypothèse. Les dix premières livraisons sont l'expérience. Quelqu'un dans votre immeuble a déjà écrit les résultats. Allez les lire.

Cet article est adapté de l'édition #16 de ma newsletter LinkedIn, Professional Services & Tech. Abonnez-vous sur LinkedIn pour recevoir les prochaines éditions.

Sources :

Pendo, « The 2019 Feature Adoption Report », usage analysé sur 615 abonnements ;
The Standish Group, recherches CHAOS sur l'usage des fonctionnalités ;
Gartner, « Survey Data: Gartner's Annual Product Manager Survey », sur les délais de lancement et l'atteinte des objectifs internes.

---

Mathilde HENRY
Executive Leader in Enterprise Software & AI Transformation. 20 ans à l'intersection du logiciel, du conseil et de la transformation des entreprises.