OKRs produit : comment mesurer l'impact, pas le travail

Un bon OKR produit ne commence pas par "Livrer la feature X". Il commence par "Qu'est-ce qu'on cherche à changer dans le comportement des utilisateurs ?"

La distinction paraît évidente. Dans la pratique, la majorité des équipes produit confondent encore OKRs et liste de tâches trimestrielle. Et ça change tout.

Pourquoi tes OKRs ressemblent à une to-do list

Regarde les OKRs de ton dernier trimestre. Compte combien de Key Results commencent par un verbe de livraison : "développer", "lancer", "déployer", "finaliser", "migrer".

Si la réponse est "la plupart", tu n'as pas des OKRs. Tu as un plan de charge habillé en OKRs.

L'erreur classique ressemble à ça :

Objectif : "Améliorer l'onboarding utilisateur"

• KR1 : Livrer le nouveau flow d'onboarding en production
• KR2 : Intégrer les tutoriels vidéo dans le parcours
• KR3 : Documenter le parcours dans la base de connaissance

Ces trois Key Results peuvent être accomplis sans que l'onboarding ne s'améliore d'un iota. Tu as livré. L'utilisateur ne comprend toujours pas le produit. L'OKR est "atteint". Le problème reste entier.

Le même objectif avec une formulation centrée sur les résultats :

• KR1 : Le taux de complétion de l'onboarding passe de 38 % à 60 %
• KR2 : 70 % des comptes activés utilisent au moins 3 modules dans les 14 premiers jours
• KR3 : Le churn à J30 passe de 18 % à 10 %

Ici, tu peux ne jamais livrer les tutoriels vidéo et quand même atteindre ces chiffres. Si un meilleur email de bienvenue fait le job, parfait. Si une session onboarding live convertit mieux, utilise ça. L'OKR te donne le cap, pas le chemin.

La distinction entre KPI et OKR vaut aussi d'être clarifiée. Un KPI mesure l'état courant : "notre taux de churn est à 18 %". Un OKR fixe une cible ambitieuse pour changer cet état : "le churn passe à 10 % d'ici fin de trimestre". Les KPIs décrivent où tu es. Les OKRs disent où tu vas, et si tu y arrives.

Ce qu'un bon OKR force à faire : choisir

Le problème central des équipes produit n'est pas le manque d'idées. C'est d'en avoir trop, et de ne pas pouvoir choisir.

Une roadmap avec 40 items tous "prioritaires". Trois squads qui travaillent sur cinq axes en même temps. Des PMs qui passent leur temps à négocier du bandwidth plutôt qu'à construire. Des engineers qui switchent de contexte quatre fois par jour. Les résultats s'effritent, mais tout le monde est occupé.

Un OKR bien construit résout ça par la contrainte. Non pas parce qu'il éclaire sur ce qui est important, mais parce qu'il force à assumer ce qu'on laisse de côté.

La règle de base : trois OKRs par cycle, avec trois à quatre Key Results chacun. Pas sept OKRs. Pas douze Key Results. Trois et trois. Si tu en as plus, tu n'as pas des OKRs, tu as des KPIs empilés qui mesurent l'existant sans te tirer vers l'avant.

Le niveau de confiance attendu sur un bon OKR se situe autour de 50 %. Si tu es à 80 %, ton objectif n'est pas assez ambitieux. Si tu es à 20 %, il est irréaliste. Le sweet spot est l'inconfort mesuré : l'équipe pense que c'est atteignable, mais ce n'est pas garanti.

Choisir ses OKRs, c'est aussi choisir ce qu'on arrête. Ce projet que tout le monde "reporte" depuis deux trimestres sans jamais le fermer. Cette initiative qui a perdu son sponsor mais reste dans le backlog par inertie. Un OKR bien écrit assume ce renoncement. Il dit explicitement : "ce cycle, on fait ça. Le reste attend."

Si tu travailles sur la priorisation de ton backlog en parallèle de tes OKRs, les deux processus se renforcent. Les OKRs donnent le cap ; la priorisation aligne l'exécution.

Le framework TARS pour des Key Results qui mesurent l'impact

Face à une page blanche, comment écrire des Key Results qui mesurent vraiment l'impact ?

TARS donne une structure. Le framework définit quatre dimensions d'impact qu'une équipe produit peut mesurer :

Targeted : les bons utilisateurs arrivent. C'est la dimension acquisition et activation. Les utilisateurs qu'on veut attirer arrivent-ils ? Les premiers gestes clés dans le produit se font-ils correctement ?

Adopted : ils utilisent le produit. L'adoption d'une feature ou d'un workflow cible. Les utilisateurs activés intègrent-ils ce qu'on a construit dans leur usage quotidien ?

Retained : ils reviennent. La rétention et l'engagement dans le temps. Les utilisateurs qui sont venus une fois reviennent-ils ? Leur fréquence d'usage augmente-t-elle ?

Satisfied : ils en sont satisfaits. Le signal qualitatif et la perception. NPS, CSAT, volume de tickets support. L'expérience produit est-elle perçue comme bonne ?

Un OKR n'a pas besoin de couvrir les quatre dimensions simultanément. Mais TARS comme checklist te force à aller au-delà des métriques de livraison et des vanity metrics.

Exemple concret. Une squad travaille sur l'onboarding d'une plateforme SaaS B2B ciblant les PME. Le problème : les comptes s'activent mais ne comprennent pas le produit assez vite. Un tiers abandonne avant le premier mois.

Objectif : "Rendre l'onboarding suffisamment clair pour que les PME voient la valeur avant J30."

Avec TARS, les Key Results se construisent ainsi :

• (Targeted) Le taux de complétion du flow d'onboarding passe de 34 % à 55 % en 90 jours
• (Adopted) 70 % des comptes ayant terminé l'onboarding utilisent au moins 3 modules clés dans les 14 premiers jours
• (Retained) Le churn à J30 des nouveaux comptes passe de 22 % à 12 %
• (Satisfied) Le score CSAT mesuré à la fin de l'onboarding passe de 3,2 à 4,0 sur 5

Quatre Key Results. Quatre dimensions. Aucun livrable. L'équipe peut choisir n'importe quel chemin pour y arriver : refonte du flow, accompagnement email, personnalisation en fonction du profil, sessions live. Ce qui compte, c'est le chiffre de sortie.

Un avantage pratique de TARS : tu repères rapidement les angles morts. Si tous tes Key Results tombent dans la dimension "Adopted" et qu'aucun ne mesure la rétention, c'est un signal. Soit la rétention n'est pas un enjeu ce trimestre et c'est un choix assumé, soit tu l'as simplement oubliée.

La data 0 : le travail que personne ne fait

Avant d'écrire un Key Result, tu dois connaître ta baseline. Où en es-tu aujourd'hui ?

C'est l'étape que les équipes sautent. Parce qu'elle est fastidieuse. Parce que les dashboards ne sont pas toujours en place. Parce qu'il faut aller chercher les données dans Mixpanel, Amplitude, ou directement en base.

Sans baseline, un Key Result "le taux d'activation passe à 60 %" ne veut rien dire. 60 %, c'est mieux que 10 % mais moins bien que 85 %. Est-ce ambitieux ou confortable ? Impossible à savoir.

La question à poser pour chaque Key Result : "est-ce que je sais exactement où j'en suis aujourd'hui ?" Si la réponse est non, c'est ton premier travail avant d'écrire l'OKR.