OKRs pour PM IC : mesurer ton impact sans manager personne
Tes OKRs de PM ressemblent à ça : "Le NPS passe de 32 à 45. Le churn J30 passe de 18 à 10 %. Le taux d'activation passe de 40 à 60 %."
Le problème : ces métriques ne dépendent pas de toi.
Elles dépendent de l'équipe engineering qui code, des designers qui testent, du marketing qui attire les bons utilisateurs, des CSMs qui onboardent les comptes. Toi, tu priorises, tu arbitres, tu écris des specs. Mais tu ne livres pas le code, tu ne fais pas les campagnes, tu ne gères pas les renouvellements.
En tant que PM IC, tu n'as pas d'équipe directe à manager. Tu influences sans contrôler. Et les OKRs classiques "d'équipe" appliqués à ton nom capturent mal ce que tu fais vraiment.
Le piège des OKRs d'équipe sous ton nom
La pratique courante dans beaucoup d'organisations : copier les OKRs produit de l'équipe et les mettre sous ton nom. L'équipe vise 60 % d'activation, toi aussi. L'équipe vise -8 points de churn, toi aussi.
Conséquence directe : tu partages le crédit si ça marche, mais tu assumes la responsabilité si ça rate, sur des métriques que tu ne contrôles pas seul.
Si l'équipe engineering perd 30 % de sa capacité sur un incident de prod en mars, si le marketing pivote de positionnement en cours de trimestre, si trois engineers sont réaffectés sur un projet prioritaire de la direction, tes OKRs bougent avec eux. Pas parce que tes décisions étaient mauvaises. Parce que tu n'avais aucun levier direct sur ces chiffres.
Un OKR PM IC qui se déplace chaque fois que quelqu'un d'autre change de priorité n'est pas un OKR. C'est un thermomètre.
L'autre version du même piège : les KRs d'activité. "Conduire 12 interviews utilisateurs ce trimestre." "Livrer les specs de 4 features." "Présenter la roadmap au CODIR." Ce sont des tâches. Elles ne disent rien sur l'impact de ce que tu as produit.
Ce que tu contrôles vraiment
Avant d'écrire le premier Key Result, réponds à cette question : qu'est-ce que TU contrôles, indépendamment de ce que les autres font ?
Trois zones de contrôle direct pour un PM IC.
La qualité de tes décisions produit. Tu décides ce qui entre dans le backlog priorisé. Tu décides quels problèmes valent la peine d'être résolus ce trimestre. Tu décides à quel niveau de détail une spec doit arriver avant d'être implémentée. Ces décisions sont les tiennes.
La qualité de ton discovery. Tu génères les insights qui informent ces décisions : interviews, analyse de données, tests. La régularité et la rigueur de ton process de discovery dépendent de toi.
La clarté que tu génères autour du produit. L'équipe comprend-elle le pourquoi de ce qu'elle construit ? Les stakeholders sont-ils alignés sur ce qu'on cherche à atteindre ? Tu contrôles la qualité et la fréquence de ta communication.
Tes OKRs doivent mesurer ces trois zones. Pas les métriques business de l'équipe.
Le framework SOC pour structurer tes OKRs IC
SOC (Stratégie, Opérations, Communication) est une grille d'analyse qui aide à répartir les responsabilités d'un PM sur trois dimensions. Appliqué aux OKRs d'un PM IC, il donne une structure claire pour écrire des Key Results qui mesurent ce que tu contrôles vraiment.
Stratégie : est-ce que tes décisions de priorisation sont bonnes ? La question n'est pas "l'équipe a-t-elle livré ?", mais "ce qu'elle a livré est-il utilisé et utile ?"
Un Key Result type pour la dimension Stratégie : "70 % des features livrées ce trimestre atteignent un taux d'adoption supérieur à 20 % dans les 30 premiers jours." Ce KR mesure si tes choix de priorisation ont produit des choses que les utilisateurs adoptent vraiment. Tu contrôles la décision de mettre X en priorité plutôt que Y. Tu ne contrôles pas le chiffre final de façon absolue, mais c'est bien ta décision qui l'influence le plus directement.
Opérations : est-ce que tu exécutes bien ton rôle ? Pas la vitesse de livraison de l'équipe, mais la vitesse et la qualité de ta partie du cycle.
Un Key Result type pour la dimension Opérations : "Le cycle moyen entre un brief interne et une spec approuvée par l'équipe passe de 4 semaines à 2 semaines." Ce KR mesure ta vélocité décisionnelle. Si tu prends 6 semaines à écrire une spec, tu bloques l'exécution. Ce délai est sous ton contrôle direct.
Communication : est-ce que tu génères la clarté nécessaire autour du produit ?
Un Key Result type pour la dimension Communication : "Lors de la revue de mi-trimestre, 8 membres de l'équipe sur 10 peuvent reformuler le problème principal que le produit cherche à résoudre ce cycle sans aide externe." Ce KR mesure si ta communication de la stratégie passe vraiment. Il se vérifie avec un simple sondage en début de réunion, sans préparation.
Exemples pour trois contextes PM IC
Les zones de contrôle varient selon le contexte. Voici comment SOC s'applique en pratique.
PM IC dans une scale-up, sur une feature B2C. L'équipe a ses propres OKRs d'activation et de rétention. Les tiens :
- Stratégie : 70 % des features livrées ce trimestre atteignent un taux d'adoption supérieur à 20 % à J30, contre 45 % le trimestre précédent.
- Opérations : Le cycle brief interne à spec validée passe de 4,5 semaines à 2 semaines.
- Communication : À la revue de mi-trimestre, l'équipe peut lister les 3 hypothèses testées ce cycle sans que tu aies besoin de les lire.
PM IC solo dans une startup de 10 personnes. Pas de process formalisé, pas de framework établi. OKRs plus simples, mais toujours dans la logique SOC :
- Stratégie : 3 des 4 fonctionnalités priorisées ce trimestre ont un usage hebdomadaire mesurable avant la fin du cycle.
- Opérations : Chaque sprint débute avec un one-pager partagé 48 heures à l'avance, résumant le problème, la solution testée, et le critère de succès.
- Communication : Le CEO peut expliquer la priorité du trimestre en deux phrases sans avoir consulté de slide.
PM IC sur un produit B2B SaaS enterprise. L'enjeu est l'adoption interne dans des comptes complexes, pas le volume d'activation.
- Stratégie : Les 2 fonctionnalités construites ce trimestre sont mentionnées spontanément dans au moins 3 conversations de renewal, sans que le sales ne les ait suggérées en amont.
- Opérations : Le délai moyen entre un retour client documenté et un ticket backlog associé passe de 3 semaines à 5 jours ouvrés.
- Communication : L'équipe customer success peut décrire la roadmap du prochain trimestre sans avoir besoin d'un brief produit séparé.
Ce qu'il faut éviter
Deux pièges persistent même quand on connaît le cadre.
Premier piège : des KRs qui dépendent entièrement d'une autre équipe. "Le taux de churn J30 passe de 18 à 10 %." Si l'équipe engineering perd trois personnes en mars, ce chiffre ne bougera pas, quelles que soient tes décisions. Ce n'est pas un OKR pour un PM IC. C'est un OKR pour l'équipe dans son ensemble.
Le test simple : "Est-ce que je pourrais influencer ce KR même si l'équipe avait 50 % moins de capacité ?" Si la réponse est non, ce KR n'appartient pas à tes OKRs personnels. Il appartient aux OKRs collectifs.
Second piège : les KRs d'activité déguisés en résultats. "Conduire 8 interviews utilisateurs" n'est pas un Key Result. C'est une tâche. "Identifier 3 insights actionnables depuis les interviews qui entraînent un changement de priorisation" est un Key Result. La différence : la tâche peut être accomplie sans que ça n'ait le moindre impact sur le produit. Le Key Result force à aller jusqu'à l'usage de l'insight dans une décision.
Sur ce point, l'article sur les OKRs produit qui mesurent l'impact explique en détail comment distinguer Key Results orientés résultat de Key Results orientés livraison, avec des exemples du framework TARS.
Génère tes OKRs IC avec le Générateur OKR express
Une fois que tu as clarifié tes trois zones de contrôle, le Générateur OKR express te guide dans la construction de Key Results calibrés sur ce que tu contrôles vraiment, sans glisser vers des métriques d'équipe ou des to-do lists déguisées.