Les produits invisibles

Je suis en vacances cette semaine, donc pas de grande enquête.

À la place, une liste que j’avais envie de faire depuis un moment.

Les produits que personne ne montre.

Quand j’arrive dans une boîte, on commence généralement par me montrer le produit.

L’app. Le SaaS. Le parcours client. Les derniers écrans sortis.

Normal.

Mais assez vite, je demande à voir le reste.

Le back-office un peu moche que 40 personnes utilisent toute la journée.
Le moteur de règles que deux devs connaissent vraiment.
Les permissions.
Les notifications.
Les outils sur lesquels les Ops ont fini par construire leur propre façon de travailler.

Bref, tous les trucs précédés de :

« Ah ça ? C’est juste un outil interne. »

J’adore ces produits.

Parce qu’ils racontent souvent beaucoup plus de choses sur une boîte que son produit public.

Il commence rarement comme un produit.

Au début, il faut juste permettre au support de rembourser quelqu’un. Ou à une équipe Ops de modifier un statut sans demander à un développeur.

On ajoute deux boutons.

Puis un troisième.

Puis le cas spécial du gros client.

Puis le bouton qui corrige le cas spécial quand il s’est mal passé.

Quelques années plus tard, cinquante personnes passent leur journée dedans et une partie des opérations de la boîte dépend de cet outil qui n’a parfois toujours pas vraiment de propriétaire.

J’en ai beaucoup fait chez Heetch.

Et j’ai fini par arrêter de considérer le back-office comme « l’envers » du produit.

Pour les équipes qui l’utilisent huit heures par jour, c’est le produit.

Celles-ci sont encore plus marrantes.

Une règle, prise toute seule, est presque toujours parfaitement raisonnable.

Si X, alors Y.

Sauf pour ce client.

Sauf dans ce pays.

Sauf si le paiement a déjà été validé.

Sauf dans ce cas-là, où il faut l’envoyer au support.

Le problème arrive quand on essaie de répondre à une question apparemment très simple :

« Qu’est-ce qui se passe exactement si je fais ça ? »

Et que personne n’est capable de répondre sans aller vérifier trois endroits.

À ce moment-là, vous avez un produit.

Vous ne l’appelez juste pas comme ça.

Mon préféré pour déclencher un petit silence en réunion :

« Qui peut voir ça ? »

Question simple.

Réponse fréquente :

« Alors… ça dépend. »

Les systèmes de permissions vieillissent très bien en apparence.

Admin.
User.
Manager.

Puis arrivent les vrais clients.

Le manager qui doit voir deux équipes mais pas la troisième.
Le prestataire qui a besoin d’un accès pendant trois mois.
Le grand compte avec son organisation particulière.
L’ancien salarié dont on n’est pas tout à fait certain que tous les accès aient disparu.

On ne fait jamais de lancement pour un système de permissions.

Par contre, le jour où il se trompe, tout le monde découvre son existence.

Là aussi, le piège est amusant : chaque notification est raisonnable.

Un email de bienvenue ? Évidemment.

Une relance ? Oui.

Un push quand quelque chose se passe ? Bien sûr.

Une alerte commerciale ? Pourquoi pas.

Prises séparément, toutes les décisions sont bonnes.

C’est leur somme qui devient un produit.

Et un jour quelqu’un demande :

« Attendez, un utilisateur peut recevoir combien de messages de notre part dans une journée ? »

Silence.

Et puis il y a le niveau au-dessus.

Les produits construits pour permettre à d’autres équipes de construire leurs produits.

APIs, outils vendeurs, briques Care, systèmes de configuration, services partagés…

Ceux-là m’intéressent particulièrement parce que leur impact est bizarre à mesurer.

Quand ils fonctionnent bien, il ne se passe rien.

Une équipe sort sa feature plus vite.
Une migration se passe correctement.
Les Ops n’ont pas besoin d’inventer un contournement.
Un développeur n’a pas besoin de reconstruire une brique qui existe déjà.

Pas exactement le genre de résultat qui fait une belle slide de lancement.

Et pourtant, retirez la plateforme pendant une semaine et vous découvrez très vite sa valeur.

Je crois que c’est ce que j’aime dans ces produits.

Ils n’ont souvent pas de page marketing.
Personne ne demande à les voir pendant une démo.
Certains n’ont même pas vraiment de nom.

Mais ils contiennent énormément de l’histoire de l’entreprise.

Les clients compliqués.
Les marchés qu’on a ouverts.
Les incidents qu’on ne veut pas revivre.
Les décisions prises dans l’urgence.
Les façons de travailler des équipes.

Et souvent, une bonne partie de la vitesse future de la boîte dépend d’eux.

Petite question de vacances, donc :

c’est quoi le produit invisible de votre boîte ?

Celui dont personne ne parle jamais, mais que vous n’oseriez surtout pas éteindre vendredi soir.