J'ai récemment regardé une conférence sur le scale de Doctolib et une phrase m’est restée en tête : “You build it, you run it.” (Merci #TPC)

Le principe : tu construis quelque chose, tu en restes responsable une fois en production.

Si je vais plus loin, la team doit le suivre ,regarder comment il se comporte, et l'améliorer.

Ça a fait forcément écho aux réflexions que j’ai en ce moment sur la façon dont on fait vivre un produit dans un gros écosystème.

Il y a déjà un changement qui n’est pas si anodin : arrêter d’attendre d’avoir tout construit pour mettre quelque chose dans les mains des utilisateurs.

Sortir une première version. Sur un périmètre restreint parfois. Regarder ce qui se passe. Suivre les usages, l’adoption, les parcours, les comportements… puis avancer progressivement.

Dit comme ça, ça paraît assez évident.

Dans la réalité de grosses organisations, ça peut déjà représenter un sacré changement de culture.

#PetitMomentVictoire

Mais je me rends compte qu’il y a une étape qu’on oublie facilement en chemin : l’intention derrière la métrique.

Parce qu’avoir des métriques ne veut pas forcément dire qu’on apprend.

Prenons un exemple volontairement simplifié.

On travaille plusieurs mois sur un nouveau service. Plutôt que d’attendre d’avoir construit tout ce qu’on imagine pour lui, on choisit de sortir une première version sur un périmètre volontairement restreint.

Déjà, c’est intéressant.

On confronte plus tôt notre solution au réel et les premières données commencent à arriver : nombre d’utilisateurs, taux d’activation, fréquence d’usage, utilisation de certaines fonctionnalités…

On mesure.

Et puisqu’on l’a justement pensée comme une première étape, assez naturellement, on commence déjà à réfléchir à la suite.

Est-ce qu’il faut davantage exposer le service ? Élargir son périmètre ? Enrichir certaines fonctionnalités ? Revoir une partie du parcours ?

Et c’est là qu’il manque un maillon, un maillon important.

Qu’est-ce qu’on cherchait à comprendre avec cette première version ?

Parce qu’on peut savoir précisément combien de personnes utilisent un service sans savoir si ce chiffre valide quoi que ce soit.

1 000 utilisateurs, c’est une donnée.

Mais si notre hypothèse était que ce nouveau service allait permettre à davantage d’utilisateurs d’adopter régulièrement un comportement donné, alors le nombre d’utilisateurs ne nous dit finalement qu’une partie de l’histoire.

Et surtout, il aurait fallu poser cette question avant :

Qu’est-ce qui nous permettra de considérer que notre hypothèse est suffisamment validée pour investir davantage ?

C’est là que la différence entre mesurer et apprendre devient importante pour moi.

Mesurer, c’est observer ce qui se passe.

Apprendre, c’est avoir suffisamment clarifié ce qu’on cherchait à provoquer pour que ce qu’on observe nous aide à prendre la décision suivante.

Et finalement, le “You build it, you run it” entendu pendant cette conférence s’est transformé dans ma tête en quelque chose d’un peu différent :

“You build it, you learn from it.”

Pas pour dire que la mesure est acquise partout, loin de là.

Je trouve déjà très intéressant de voir des organisations historiquement habituées à de gros projets commencer à découper davantage, sortir progressivement et mettre en place des métriques là où, quelques années plus tôt, la réussite aurait parfois simplement été : “c’est en production”.

Mais peut-être que pour que ça fonctionne, il ne faut pas oublier de donner une intention à ces métriques.

Ne plus seulement demander :

Combien de personnes l’utilisent ?

Mais aussi :

Qu’est-ce qu’on cherchait à changer ? Qu’est-ce qu’on voulait vérifier ? Qu’est-ce que ce chiffre nous apprend sur notre hypothèse ? Et qu’est-ce qu’on décide maintenant ?

Et c’est là que ma réflexion sur les métriques rejoint un autre sujet sur lequel je travaille beaucoup en ce moment : la responsabilisation des équipes.

Parce que si on veut que les équipes ne soient plus seulement responsables de livrer une solution, mais qu’elles restent responsables de comprendre son impact et de proposer la suite, quelques PM ne peuvent pas être derrière chaque initiative, chaque hypothèse, chaque métrique et chaque décision tactique.

Il faut réussir à distribuer cette responsabilité.

Et on tombe alors assez vite sur un paradoxe : on peut difficilement dire à une équipe “soyez autonomes, cherchez l’impact, testez, apprenez et proposez-nous la suite” si elle ne sait pas précisément à quelle ambition globale elle est censée contribuer.

En théorie, on a déjà un outil pour ça : les OKR.

Donner une direction commune, expliciter les résultats que l’on cherche à obtenir et permettre ensuite aux équipes de trouver les meilleurs moyens d’y contribuer. Sur le papier, ça répond presque parfaitement au problème.

Mais entre poser des OKR et réussir à en faire un véritable système de décision pour les équipes, il y a encore un espace assez immense.

Et c’est cet espace qui m’intéresse aujourd’hui.

Comment utiliser cette logique dans une organisation qui ne fonctionne pas encore complètement comme ça ?

Comment donner progressivement aux équipes la responsabilité d’un impact quand l’organisation reste encore largement structurée autour de projets, de roadmaps, de budgets et de livrables ?

Parce qu’attendre d’être devenu une organisation parfaitement Agile et Produit pour commencer à fonctionner par objectifs et résultats, c’est finalement attendre d’avoir changé pour commencer à changer.

Peut-être que les OKR ne sont pas seulement un outil pour les organisations Produit matures.

Peut-être qu’ils peuvent aussi devenir un moyen de les aider à le devenir.

À condition de ne pas les regarder uniquement comme un outil de transformation, mais bien comme un moyen de reconnecter très concrètement stratégie, impact et décisions du quotidien.