Deux Product Owners, Même Backlog
Imaginez deux Product Owners qui gèrent le même produit.
PO #1 arrive à la sprint review avec une liste : "On a livré le système de notifications, le bouton d'export, et le wizard d'onboarding."
PO #2 arrive avec une question : "L'activation des utilisateurs est passée de 23% à 41%. Parlons de ce qu'on a appris et de ce qu'on fait ensuite."
Même équipe. Mêmes fonctionnalités. Leadership complètement différent.
Le Piège des Fonctionnalités
Les fonctionnalités donnent l'impression de progresser. Elles sont tangibles. On peut les démontrer. Les parties prenantes applaudissent.
Mais les fonctionnalités ne sont pas des résultats. Une fonctionnalité livrée que personne n'utilise est un passif, pas un actif. Elle ajoute de la complexité, des bugs et des coûts de maintenance sans apporter aucune valeur utilisateur.
Le piège : les organisations récompensent la livraison parce que livrer est visible. Les résultats sont invisibles jusqu'à ce qu'il soit trop tard.
La vérité brutale : Dans la plupart des produits, la majorité des fonctionnalités sont rarement ou jamais utilisées — une étude du Standish Group(lien externe, nouvel onglet) a montré que 64% des fonctionnalités logicielles sont rarement ou jamais utilisées. Nous excellons à construire les mauvaises choses, exactement le piège « vélocité plutôt que valeur » qui fait dérailler les équipes Agile.
Le Changement Vers l'Orientation Résultat
Le changement est simple à décrire, difficile à exécuter. L'équipe de Marty Cagan au Silicon Valley Product Group(lien externe, nouvel onglet) le formule comme la différence entre les feature teams et les équipes produit autonomes — l'une livre de l'output, l'autre est responsable des résultats :
Au lieu de : "Il faut construire un moteur de recommandations."
Demandez : "Quel changement de comportement cherche-t-on à créer ? Comment saurons-nous que ça a fonctionné ? Quel est le minimum à livrer pour tester l'hypothèse ?"
Ce changement de cadrage fait trois choses :
- Il sépare le problème de la solution
- Il force à définir une métrique de succès avant d'écrire une ligne de code
- Il ouvre la porte à des alternatives moins coûteuses et plus rapides
Parfois, le moteur de recommandations devient un email hebdomadaire composé manuellement. Même résultat, 10% du coût.
Outils Pratiques pour Penser en Résultats
La Formulation de l'Opportunité
Cela s'inspire de la discovery continue — l'Opportunity Solution Tree(lien externe, nouvel onglet) de Teresa Torres en est la version la plus rigoureuse. Avant tout epic ou initiative, rédigez :
"Nous croyons que [groupe d'utilisateurs] a un problème avec [situation]. Si nous le résolvons, [résultat mesurable] changera. On saura qu'on a réussi quand [métrique spécifique]."
Affichez-la dans votre salle de sprint. Chaque story doit pouvoir y être rattachée.
La Métrique d'Abandon
Pour chaque fonctionnalité, définissez à l'avance : "Si cette métrique ne bouge pas dans 30 jours, on retire cette fonctionnalité."
La plupart des équipes ne le font jamais. Elles livrent, oublient et passent à autre chose. La métrique d'abandon force la responsabilisation et maintient le produit léger.
La Revue Hebdomadaire "Et Alors ?"
Chaque semaine, regardez vos métriques clés et demandez : "Qu'est-ce qui a changé ? Pourquoi ? Qu'est-ce que ça nous dit ?"
Pas un exercice de reporting. Un exercice d'apprentissage — et de plus en plus un domaine où l'IA peut compresser le travail ingrat d'analyse pour vous laisser le temps du jugement.
La Partie Difficile : Dire Non
Penser en résultats exige de dire non à des choses qui semblent importantes.
L'équipe commerciale veut un rapport personnalisé. Le PDG a vu une fonctionnalité chez un concurrent. Le designer UX a une brillante nouvelle idée.
Toutes ces idées sont peut-être bonnes. Aucune n'est automatiquement le bon investissement.
Le rôle du Product Owner est de comparer chaque demande à : "Est-ce la chose à plus fort impact qu'on peut faire maintenant pour nos utilisateurs ?"
Ça demande du courage — un muscle particulièrement difficile à développer pour celles et ceux qui viennent de passer de l'ingénierie au rôle de Product Owner. La plupart des parties prenantes sont habituées à des POs qui disent oui et priorisent plus tard. Les grands POs disent : "Aidez-moi à comprendre quel résultat vous cherchez à atteindre — il y a peut-être une meilleure façon."
Commencez Par Une Métrique
N'essayez pas de transformer l'intégralité de votre produit d'un coup.
Choisissez une métrique qui compte. Rendez-la visible. Demandez à votre équipe chaque semaine : "Qu'avons-nous fait cette semaine pour faire bouger ce chiffre ?"
Cette seule pratique — répétée pendant 3 mois — change la façon dont une équipe pense à son travail.
Et vous devenez alors un Product Owner qui pilote des résultats, pas des fonctionnalités.
